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
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
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
Major paradigm shifts
OOP – Data abstraction, encapsulation, inheritance, polymorphism
Spring framework for Dependency injection
Google – search functionality + web crawler + page rank and other processing
Facebook – New feed + authentication + recommendation engine + advertisement
Idempotent - clients can make that same call repeatedly while producing the same result
Point-to-point or Publish/Subscribe
Durability - messages may be kept in memory, written to disk, or even committed to a DBMS if the need for reliability indicates a more resource-intensive solution.
Message purging policies - queues or messages may have a "time to live"
Delivery policies - do we need to guarantee that a message is delivered at least once, or no more than once?
Queuing criteria - when should a message be considered "enqueued"? When one queue has it? Or when it has been forwarded to at least one remote queue? Or to all queues?
Receipt notification - A publisher may need to know when some or all subscribers have received a message.