MICROSERVICESSession - I

Sowri Varanasi17-11-2016

AGENDAPart - I• Prominent design/architecture philosophies • Microservices vs. Monolithic• Characteristics/Anatomy of Microservices• Design considerations • Case study: Kony Cloud Foundation

Part – II• Data modelling• CAP theorem, Scalability • Security• Monitoring• Deployment • Case study 2: Design of AWS

Design/Architecture PhilosophiesMajor philosophies

• OOP• Model - View – Controller• Dependency injection

Measure effectiveness of design/architecture

• Cohesion - measures the “strength of relationship” between components.

• Coupling - is how much one component knows about the inner workings or inner elements of another one

• High cohesion and low coupling are desirable and they need to be maximized by any effective design/architecture.

Non-functional requirements

• Scalability • Fault tolerance • Ease of integration &

deployment • Ease of testing and

certifying software • Maintainability • Reusability

Use case: Cloud Foundation

Kony Account Management

Customer application

management

Kony Product

Management

Kony Cloud Management

Authorization &

AuthenticationAnalytics

Use-cases

• Customer provided with “Kony Account”.

• Customer need one or more clouds.

• Every cloud should contain a set of Products/features

• Customer can design services and deploy

• Customers to be authorized/authenticated for actions

• Customer apps related analytics

MONOLITHICS vs. MICROSERVICES

Monolithic: Definition“Monolithic, means all in one piece. ”

“Monolithic software is designed to be self-contained; components of the program are interconnected and interdependent. Each component and its associated components must be present in order for code to be executed or compiled.”

“Reusability is via libraries.”

Microservices: Definition“Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms”

“Services are built around business capabilities; independently deployable by fully automated deployment machinery”

“minimal centralized management of these services, which may be written in different programming languages and use different data storage technologies”

-- James Lewis and Martin Fowler

Monolithic vs. Microservices Application split into “Layers” resulting in

hierarchy Single process boundary Small change – build and deploy entire app Horizontal scalability Homogeneous technology stack

Applications are suites of services Each service in its own boundary Deploy only the service Service level scalability Heterogeneous technology stack

Microservices – Why traction now?

Cloud technologies Auto scaling Infrastructure as code

Test driven development

Scalability Small 2-pizza teams Eventual consistency Rapid Application Development

Cloud Foundation: If designed as a Monolithic

Multi-tenant infrastructure

Administrative functions

Account management

Metrics

Cloud ProvisioningCustomer Billing

Zendesk interfacing

AWS interfacing

Multi-tenant interfacing

App/service develop & deploy

Auth

MICROSERVICES: ANATOMY & DESIGN CONSIDERATIONS

Microservices: Anatomy

Service 1

Service caller

Service 2

Service Contract/API

Communication channel

Response

Error handling Auth

Communication mode

Integration: How do Microservices collaborate?• Shared database – is it an

option? Only state is modified;

behaviour is compromised (sharing behaviour not data)

Services “tightly” coupled with data sharing

• Single source of Truth• No shared data modifications

Accounts Provision

Kony Accounts +

environments

Integration: Sync/Async communication

Sync - Blocking

• Can Service A proceed after calling Service B? NO

• Response expected in real-time?• Synchronous –

Request/response collaboration

Remote Procedure Call (RPC)

REST over HTTP

Async – Non-blocking

• Service A can proceed after call to Service B and doesn’t need wait? YES

• Async – event-driven collaboration• Decoupled, scalable systems

Message Queue REST over HTTP (virtual

blocking) Enterprise Message Bus

Integration: Sync – REST over HTTP• Identify type of call – Sync vs. Virtual

Async Input/output: XML/JSON/Agreed

data exchange format Result: HTTP codes

• Standardization of behaviour –

PUT/POST/GET calls, JSON headers, HTTP return codes

• Ambiguous 504 • Idempotent services • Polling for long transactions

Accounts Provision

Provision Cloud

Accepted/200

Keep checking status

Success/Failure

Integration: Async – Message Queues

• Identify the topics/persistence type Input/output: XML/JSON/Agreed data

exchange format Result: Success messages

• How is response processed? • What happens if caller is not available to process?• Messaging: One-to-one or one-to-many?

• Standardization of – queues, data exchange formats

• Idempotent services • No polling but not real time (response time not

guaranteed)• Mechanisms to make sure all messages are

processed

Accounts Provision

Success/Failure

Provision Queue

Provision Status Queue

Rabbit MQ or lightweight

messaging system* Desirable

Managing business process: Orchestration• Services have to drive other

services to achieve business process

• Common controller to lead remaining services

• Tight coupling of components• Controller can become “Single

Point” failure • Controller can track the success

and report

MBaaS Console

Accounts

Provision

Server

Sync

Service interaction during app/service publishing

Managing business process: Choreography• No common controller to lead

remaining services; interaction purely event driven

• Loose coupling of components• No controller to monitor business

process status across services

• Clear understanding of responsibilities will give clarity; otherwise interactions pretty brittle

• Admin UI to track chronology of events would be extremely helpful.

Analytics dataflow from AWS Cloud to Metrics

Server SyncMetrics

Metrics UI

SQS

Lambda

Redshift

S3

Versioning• Changes to Service interface impact all

consumers• Maintain old interface until all consumers

are migrated

• Consumers - Wrappers to limit the impact

• Graceful migration of consumers Backward compatible Multiple concurrent service versions

– “expand/contract design pattern”• Multiple versions - REST interfaces –

version in URI• Co-existence of versions increases

maintenance effort

S1 S2

S3

v1 v2

S1 S2

S3

v1 v2

S1 S2

S3

v2

Other best design practices• Correlation ID – to trace the request across process

boundaries • Common logging/issue reporting infrastructure • Monitoring health of all subcomponents to ensure end-to-end

functioning• Common subsystem to deal with Third-party SaaS offerings

Cloud Foundation: Microservice Architecture

Kony Product Management

MBaaS Console Auth Server/Sync Metrics

AccountsProvision

Orch

Multi-tenant

ZendeskAWS Cloud

** Simplified architecture; might slightly deviate from original

References• Martin Fowler: Microservices• Sam Newman: Building Microservices

Thank You