Microservices Architecture

20-Feb-2020 Internal | Copyright © 2020 Tata Consultancy Services Limited

Agenda
▪ Monolithic Architecture

– What is monolithic architecture?

– Advantages

– Problems
▪ Microservices Architecture

– What is MSA?

– Identify Microservices

– Communication between Microservices

– Microservices patterns

– Technologies Stack
– Known uses

▪ Links/References

▪ Questions

2 Internal
Monolithic Architecture

Source: https://microservices.io/patterns/monolithic.html 3 Internal

Monolithic Architecture

4 Internal
Monolithic Architecture: Problems

5 Internal
Monolithic Architecture: Problems

6 Internal
Monolithic Architecture: Problems

7 Internal
Monolithic Architecture: Problems

▪ Large code base

▪ Overloaded IDE
▪ Overloaded web container
▪ Obstacles in Continuous Deployment
▪ Obstacles in application scaling
▪ Obstacles in development scaling
▪ Long term commitment to a tech stack

8 Internal
From Monolithic towards Microservices Architecture

Source: https://microservices.io/patterns/monolithic.html 9 Internal

Microservices Architecture

“The 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, often an HTTP resource API. These
services are built around business capabilities and independently deployable by
fully automated deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different programming
languages and use different data storage technologies.”

-- James Lewis and Martin Fowler

Source: https://martinfowler.com/microservices/ 10 Internal

Microservices Architecture

▪ Microservices - also known as the microservice architecture - is an architectural style that structures an
application as a collection of services that are
– Highly maintainable and testable
– Loosely coupled
– Independently deployable
– Organized around business capabilities
– Owned by a small team
▪ The microservice architecture enables the rapid, frequent and reliable delivery of large, complex
applications. It also enables an organization to evolve its technology stack.

Source: https://microservices.io/ 11 Internal

Characteristics of a Microservices Architecture

▪ Componentization via Services

▪ Organized around Business Capabilities
▪ Products not Projects
▪ Smart endpoints and dumb pipes
▪ Decentralized Governance
▪ Decentralized Data Management
▪ Infrastructure Automation
▪ Design for failure
▪ Evolutionary Design

Source: https://martinfowler.com/articles/microservices.html 12 Internal

Componentization via Services

▪ Libraries as components that are linked into a program and called using in-memory function calls,
while services are out-of-process components who communicate with a mechanism such as a web
service request, or remote procedure call.
▪ Services are independently deployable. If you have an application that consists of a multiple libraries in a
single process, a change to any single component results in having to redeploy the entire application. But
if that application is decomposed into multiple services, you can expect many single service changes to
only require that service to be redeployed.
▪ Downsides? - Remote calls are more expensive than in-process calls

Source: https://martinfowler.com/articles/microservices.html 13 Internal

Organized around Business Capabilities

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of
the organization's communication structure.
-- Melvyn Conway, 1967

Source: https://martinfowler.com/articles/microservices.html 14 Internal

Organized around Business Capabilities

▪ Microservice approach to division is different, splitting up into services organized around business
capability. Such services take a broad-stack implementation of software for that business area, including
user-interface, persistent storage, and any external collaborations.
▪ Consequently the teams are cross-functional, including the full range of skills required for the
development: user-experience, database, and project management.

Source: https://martinfowler.com/articles/microservices.html 15 Internal

Products not Projects

▪ Project model -> where the aim is to deliver some piece of software which is then considered to be
completed. On completion the software is handed over to a maintenance organization and the project
team that built it is disbanded.
▪ Microservice -> a team should own a product over its full lifetime.
▪ Amazon's notion of "you build, you run it" - where a development team takes full responsibility for the
software in production.
▪ This brings developers into day-to-day contact with how their software behaves in production and
increases contact with their users, as they have to take on at least some of the support burden.
▪ The product mentality, ties in with the linkage to business capabilities. Rather than looking at the
software as a set of functionality to be completed, there is an on-going relationship where the question
is how can software assist its users to enhance the business capability.

Source: https://martinfowler.com/articles/microservices.html 16 Internal

Smart endpoints and dumb pipes

▪ Enterprise Service Bus (ESB) - ESB products often include sophisticated facilities for message routing,
choreography, transformation, and applying business rules.
▪ Microservice -> Applications built from microservices aim to be as decoupled and as cohesive as possible
- they own their own domain logic and act more as filters in the classical Unix sense - receiving a request,
applying logic as appropriate and producing a response.
▪ These are choreographed using simple RESTish protocols (HTTP request-response)
▪ Lightweight message bus -> The infrastructure chosen is typically dumb (dumb as in acts as a message
router only) - simple implementations such as RabbitMQ or ZeroMQ don't do much more than provide a
reliable asynchronous fabric - the smarts still live in the end points that are producing and consuming
messages; in the services.

Source: https://martinfowler.com/articles/microservices.html 17 Internal

Decentralized Governance

▪ Use the right tool for the job

– want to use Node.js to standup a simple reports page? Go for it.
– C++ for a particularly near-real-time component? Fine.
– want to swap in a different flavor of database that better suits the read behavior of one component?
▪ Prefer producing useful tools that other developers can use to solve similar problems to the ones they
are facing rather than use a set of defined standards written down somewhere.
▪ Netflix is a good example of an organization that shares useful and, above all, battle-tested code as
libraries encourages other developers to solve similar problems
▪ Decentralized governance -> build it / run it ethos popularized by Amazon and Netflix. Teams are
responsible for all aspects of the software they build including operating the software 24/7.

Source: https://martinfowler.com/articles/microservices.html 18 Internal

Decentralized Data Management

▪ Monolithic applications -> prefer a single logical database for persistent data, enterprises often prefer a
single database across a range of applications - many of these decisions driven through vendor's
commercial models around licensing.
▪ Microservices -> prefer letting each service manage its own database, either different instances of the
same database technology, or entirely different database systems.
▪ Polyglot Persistence

Source: https://martinfowler.com/articles/microservices.html 19 Internal

Infrastructure Automation

▪ Continuous Integration – Continuous Delivery

▪ Automate tests and deployment

Source: https://martinfowler.com/articles/microservices.html 20 Internal

Design for failure

▪ Services can fail at any time, it's important to be able to detect the failures quickly and, if possible,
automatically restore service.
▪ Emphasis on real-time monitoring of the application, checking both architectural elements (how many
requests per second is the database getting) and business relevant metrics (such as how many orders per
minute are received).
▪ Semantic monitoring can provide an early warning system of something going wrong that triggers
development teams to follow up and investigate.
▪ Microservice teams would expect to see sophisticated monitoring and logging setups for each individual
service such as dashboards showing up/down status and a variety of operational and business relevant
metrics.
▪ Details on circuit breaker status, current throughput and latency are other examples often encounter.

Source: https://martinfowler.com/articles/microservices.html 21 Internal

Evolutionary Design

▪ Independent replacement and upgradeability

– rewriting a component without affecting its collaborators
– Scrap services
▪ With a monolith any changes require a full build and deployment of the entire application.
▪ With microservices, however, you only need to redeploy the service(s) you modified.
▪ This can simplify and speed up the release process.
▪ The downside is that you have to worry about changes to one service breaking its consumers.

Source: https://martinfowler.com/articles/microservices.html 22 Internal

Identifying Microservices

▪ Using Domain Driven Design & bounded contexts

▪ Single Responsibility
▪ Common Closure
▪ Gather together those things that change for the same reason. Separate those things that change for
different reasons
▪ Can it be independently evolved?
▪ Independently managed. Clear ownership for each service
▪ Typically need/adopt the “DevOps” model

23 Internal
Identifying Microservices – Bounded contexts

24 Internal
Domain Driven Design

Source: https://learning.oreilly.com/library/view/domain-
driven-design-tackling/0321125215/ 25 Internal
 Communication between Microservices

▪ Synchronous communication
– In this pattern, a service calls an API that another service exposes, using a protocol
such as HTTP or gRPC. This option is a synchronous messaging pattern because the
caller waits for a response from the receiver.
▪ Asynchronous messaging
– In this pattern, a service sends message without waiting for a response, and one or
more services process the message asynchronously.

Source: https://docs.microsoft.com/en-
us/azure/architecture/microservices/design/interservice-
communication 26 Internal
 Asynchronous messaging
Advantages Challenges
▪ Reduced coupling ▪ Coupling with the messaging
▪ Multiple subscribers infrastructure
▪ Failure isolation ▪ Latency
▪ Responsiveness ▪ Cost
▪ Load leveling ▪ Complexity
▪ Workflows ▪ Throughput

Source: https://docs.microsoft.com/en-
us/azure/architecture/microservices/design/interservice-
communication 27 Internal
 Example - e-commerce application

Source: https://microservices.io/patterns/microservices.html 28 Internal

Microservices Concerns

▪ Configuration Management
▪ Service Discovery & Load Balancing
▪ Resilience & Fault Tolerance
▪ API Management
▪ Service Security
▪ Centralized Logging
▪ Centralized Metrics
▪ Distributed Tracing
▪ Scheduling & Deployment
▪ Auto Scaling and Self Healing

Source: https://microservices.io/patterns/microservices.html 29 Internal

Microservice Patterns

30
Patterns

▪ Application architecture patterns ▪ Transactional messaging

– Monolithic architecture
– Microservice architecture
– Transactional outbox
▪ Decomposition – Transaction log tailing
– Decompose by business capability – Polling publisher
– Decompose by subdomain
▪ Testing
– Self-contained Service
– Service per team – Service Component Test
▪ Data management – Consumer-driven contract test
– Database per Service – Consumer-side contract test
– Shared database
– Saga
– API Composition
– CQRS
– Domain event
– Event sourcing

Source: https://microservices.io/patterns/microservices.html 31 Internal

Patterns – Contd…

▪ Deployment patterns ▪ External API

– Multiple service instances per host – API gateway
– Service instance per host – Backend for front-end
– Service instance per VM
▪ Service discovery
– Service instance per Container
– Client-side discovery
– Serverless deployment
– Service deployment platform – Server-side discovery
▪ Cross cutting concerns – Service registry
– Microservice chassis – Self registration
– Externalized configuration – 3rd party registration
▪ Communication style ▪ Reliability
– Remote Procedure Invocation – Circuit Breaker
– Messaging ▪ Security
– Domain-specific protocol – Access Token

32 Internal
Patterns - Contnd

▪ Observability
– Log aggregation
– Application metrics
– Audit logging
– Distributed tracing
– Exception tracking
– Health check API
– Log deployments and changes
▪ UI patterns
– Server-side page fragment composition
– Client-side UI composition

33 Internal
API Gateway

Client Interaction with Microservices

34 Internal
API Gateway - Routing

35 Internal
API Gateway – Load Balancer

36 Internal
Configuration management

▪ Scattered Configuration

37 Internal
Configuration management

▪ Centralized Configuration

38 Internal
Service Discovery

39 Internal
Service Discovery

40 Internal
Building resilient Microservices

▪ Fault tolerance and auto scaling

– Using containers
– Container management with Docker and Kubernetes
▪ Why should servers be stateless

41 Internal
Technology Stack for Microservices

42
Spring Cloud + Netflix OSS
Microservices Concern Tools
Configuration Management Spring Cloud Config Server, Consul
Service Discovery Netflix Eureka
API Gateway Netflix Zuul
Load Balancer Netflix Ribbon
Monitoring Netflix Hystrix dashboard, Turbine
Security Spring Cloud Security
Centralized Logging ELK Stack (Logstash)
Centralized Metrics Netflix Spectator and Atlas
Distributed Tracing Spring Cloud Sleuth and Zipkin
Resilience & Fault Tolerance Netflix Hystrix (Circuit Breaker), Turbine & Ribbon
Packaging & Deployment Spring Boot

Auto Scaling & Self Healing None

Source: https://spring.io/projects/spring-cloud-netflix 43 Internal
Kubernetes
Microservices Concern
Configuration Management
Service Discovery
API Gateway
Load Balancer
Security
Centralized Logging
Centralized Metrics
Distributed Tracing
Resilience & Fault Tolerance
Packaging & Deployment
Auto Scaling & Self Healing
Tools
Kubernetes ConfigMap & Secrets
Kubernetes Service & Ingress Resources
Kubernetes Service & Ingress Resources
Kubernetes Service
-
EFK Stack (Fluentd)
Heapster, Prometheus, Grafana
OpenTracing, Zipkin
Kubernetes Health Check & Resource isolation
Docker/Rkt, Kubernetes Scheduler & Deployment
Kubernetes Health Check, Self Healing, Autoscaling
44 Internal
Known uses

45
 Companies using Microservices
▪ Netflix
▪ Amazon
▪ Ebay
▪ Uber
▪ Comcast Cable
▪ Sound Cloud
▪ Karma
▪ Groupon
▪ Hailo
▪ Gilt
▪ Zalando
▪ Capital One Why Capital One is at Re:Invent and Keynote
▪ Lending Club
▪ AutoScout24

Source: https://microservices.io/articles/whoisusingmicroservices.html 46 Internal

Links

47
Reference links

▪ https://microservices.io/
▪ https://martinfowler.com/microservices/
▪ https://12factor.net/
▪ https://spring.io/projects/spring-cloud-netflix
▪ https://aws.amazon.com/microservices/
▪ https://docs.microsoft.com/en-us/azure/architecture/microservices/

48 Internal
Thank You

49
Backup Slides

50
The Twelve Factors

The twelve-factor app is a methodology for building software-as-a-service apps that:

▪ Use declarative formats for setup automation, to minimize time and cost for new developers joining the
project;
▪ Have a clean contract with the underlying operating system, offering maximum portability between
execution environments;
▪ Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems
administration;
▪ Minimize divergence between development and production, enabling continuous deployment for
maximum agility;
▪ And can scale up without significant changes to tooling, architecture, or development practices.

Source: https://12factor.net/ 51 Internal

The Twelve Factors

I. Codebase VII. Port binding

One codebase tracked in revision control, many Export services via port binding
deploys VIII. Concurrency
II. Dependencies Scale out via the process model
Explicitly declare and isolate dependencies IX. Disposability
III. Config Maximize robustness with fast startup and graceful
Store config in the environment shutdown
IV. Backing services X. Dev/prod parity
Treat backing services as attached resources Keep development, staging, and production as similar
V. Build, release, run as possible
Strictly separate build and run stages XI. Logs
VI. Processes Treat logs as event streams
Execute the app as one or more stateless processes XII. Admin processes
Run admin/management tasks as one-off processes

Source: https://12factor.net/ 52 Internal

AWS

▪ Compute: Containers - Amazon Elastic Container Service, Serverless - AWS Lambda

▪ Storage: ElastiCache, RDS, DynamoDB, Aurora, S3
▪ API Gateway: API Proxy - Amazon API Gateway
▪ Dynamic Routing and Load Balancer: Elastic Load Balancing (Application Load Balancer), Route S3
▪ Service Discovery: AWS Cloud Map
▪ Central configuration server:
▪ Monitoring: Service Mesh - AWS App Mesh, API Monitoring - AWS CloudTrail, Distributed Tracing - AWS
X-Ray, Application and Resource Monitoring - Amazon CloudWatch

Source: https://aws.amazon.com/microservices/ 53 Internal