This document discusses microservices architecture and compares it to monolithic architecture. It begins by outlining the agenda and then defines prominent design philosophies like OOP, MVC, and concepts like cohesion and coupling. It then provides definitions and comparisons of monolithic vs microservices approaches. Key differences are that microservices have separate processes, independent deployability, and allow for different programming languages. The document discusses integration patterns for microservices like synchronous vs asynchronous communication using REST and message queues. Other topics covered include service versioning, orchestration vs choreography for business processes, and best practices for monitoring, logging and third party integration. Finally an example microservices architecture for a Cloud Foundation application is presented.

1. MICROSERVICES
Session - I
Sowri Varanasi
17-11-2016

2. AGENDA
Part - 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

3. Design/Architecture Philosophies
Major 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

4. Use case: Cloud Foundation
Kony Account
Management
Customer
application
management
Kony
Product
Management
Kony Cloud
Management
Authorization
&
Authentication
Analytics
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

5. MONOLITHICS vs.
MICROSERVICES

6. 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.”

7. 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

8. 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

9. Microservices – Why traction now?
Cloud technologies Auto scaling Infrastructure as
code
Test driven
development
Scalability Small 2-pizza teamsEventual consistency Rapid Application
Development

10. Cloud Foundation: If designed as a
Monolithic
Multi-tenant
infrastructure
Administrative
functions
Account management
Metrics
Cloud Provisioning
Customer Billing
Zendesk interfacing
AWS interfacing
Multi-tenant
interfacing
App/service develop
& deploy
Auth

11. MICROSERVICES:
ANATOMY &
DESIGN
CONSIDERATIONS

12. Microservices: Anatomy
Service 1
Service caller
Service 2
Service
Contract/API
Communication
channel
Response
Error handling Auth
Communication
mode

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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 Sync
Metrics
Metrics
UI
SQS
Lambda
Redshift
S3

19. 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

20. 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

21. Cloud Foundation: Microservice
Architecture
Kony
Product Management
MBaaS
Console
Auth Server/Sync Metrics
Accounts
Provision
Orch
Multi-tenant
Zendesk
AWS Cloud
** Simplified architecture; might slightly deviate from original

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

23. Thank You