This document provides an overview of microservices and service mesh architectures. It discusses key concepts like bounded contexts in domain-driven design, the benefits of a service mesh pattern for managing communication between loosely coupled microservices, and common capabilities provided by service proxies and control planes like service discovery, load balancing, circuit breakers, and traffic control. Fallacies of distributed computing and integrating service meshes with API management and container platforms like Kubernetes are also covered at a high level.

1. Microservices &
Service Mesh
Workshop
Claudio Acquaviva

2. "All problems in Computer Science can be solved by another
level of indirection, except for the problem of too many layers
of indirection”.
David J. Wheeler, Computer Scientist
Inventor of the "Closed Subroutine", 1927-2004.

3. All information are public.
3 main tasks
• Content qualification
• Content structuring
• Content application

4. • Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design,
Larry Constantine, Ed Yourdon, 1979
• “Low coupling is a sign of a well structured computer system.” (Baixo acoplamento é um sinal
de um sistema de computador bem estruturado).
• “High cohesion tend to be preferable because it is associated with several desirable traits of
software including robustness, reliability, reusability, and understandability.” (Alta coesão
tende a ser preferível porque está associada com vários traços de software desejáveis
incluindo robutez, confiabilidade, reusabilidade e compreensão)
• “...Clearly, cohesion and coupling are interrelated. The greater the cohesion of individual
modules in the system, the lower the coupling between modules will be...”. (Claramente,
coesão e acoplamente estão inter-relacionados. Quanto maior a coesão dos módulos
individuais em um sistema, menor será o acoplamente entre os módulos.
Coupling and Cohesion

5. In summary, Service Orientation is an excellent principle. An ESB implementation approach is not a
good solution though.
Back in 2005, Anne Thomas Manes, Gartner’s VP, wrote the famous article “SOA is Dead; Long Live
Services” (http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html).
MSA by Adrian Cockcroft, AWS’ VP: “Service-oriented architecture composed of loosely coupled
elements that have bounded contexts”.
Same principles, distinct implementations. Monoliths -> Microservices
Service Orientation – SOA and MSA
MicroservicesMonolithDB DB A DB B
ESB
OrdersCustomers
LB
Microservice A
Customers
LB
Microservice B
Orders
LB
Microservice C
Invoices
LB
Invoices
DB C

6. • There is no way to build a unified domain model for all systems.
• Complex system divided in “Bounded Contexts”.
• Each “Context” defines its own unified model and its relationships with other contexts.
• A contexto is implemented by a Microservice (or a set of Microservices).
DDD – “Domain-Driven Design”

7. MSA
Microservices Architecture
API Gateway
Legacy Systems
Microservices Reference Architecture
ERP MDM CRM Mainframe
Firewall
Firewall
DMZ
Microservice 1
...
Cloud APIs
SaaS PaaS
Message Channels
Service Component
Service Component ...
Outer Architecture
Inner Architecture
Microservice 2
Service Component
Service Component
Inner Architecture
Microservice 3
Service Component
Service Component
Inner Architecture
Microservice N
Service Component
Service Component
Inner Architecture
A Guidance Framework for Architecting Portable Cloud and Multicloud Applications, Gartner
Eric Knipp, Traverse Clayton, Richard Watson, Gartner, 16/12/16
Identity Provider
Mobile Apps End Users 3rd Party Apps

8. Infraestrutura de Serviços
ESB
Firewall
API Gateway
AuthN & AuthZ
Service Virtualization & Composition
Data Transformation
Throttling
API Manager
Versioning
Knowledge Base
Life Cycle Management
Billing
Firewall
API Developers Portal
AuthN & AuthZ
Financials
API ConsumersAPI Developers
Identity Management
AuthN & AuthZ
Provisioning
Analytics
API Publication
API Usage
Credentials
Billing Data TXs Data
Service Invocation
API Management Reference Architecture
MSA
API Monitoring
API Usage
Operational Analytics

9. Service Provider 1 (SP)
Domain B
i. e.: On Premises
Service Provider 2 (SP)
Domain C
i. e.: Cloud
Identity Provider
Principal
Identity Provider (IdP)
Domain A
Credentials
(User/Passwd
X.509
OTP tokens)
Id Token
(JWT)
• IdP and SPs define a “Circle of Trust”.
• OpenID Connect is the preferred
standard
AuthorizationAuthorizationUser Databases
LDAP DBMS

10. What you have + what you know + what you are
Security
Factors
+
+ PIN +
PIN
PIN+ PIN+
What you have + what you are
What you have + what you know
What you are
What you know
What you have
Authentication Factors
Digital Certificate Token
OTP Token
Personal Identification Number
1 Factor
Authentication
2 Factor
Authentication
3 Factor
Authentication

11. Communication Models – Synchronous and Asynchronous
• Synchronous Calls:
• Asynchronous calls can be implemented as 1-to-1 or 1-to-many:
API Gateway Service A Service CService B
API Gateway Service A Service B
HTTP
HTTP
HTTP
HTTP
Queue
API Gateway Service A Service B
HTTP
Event Bus
Service C

12. • Microservices are, by definition, a distributed and dynamic environment.
• That is, the number of instances of a given Microservice might change overtime. Several reasons:
Higher/lower throughput
Canary Release
A/B testing
• How to deal with the policies change problem?
Service Registration/Discovery
Load Balancing
Traffic Control
• What about other requirements?
Encrypted Communication
Service ACL
Service Logging
Service Tracing
Microservice 1
Microservice 2'
Microservice 2''
Microservice 2'''
Multiple Microservice instances

13. Microservice 1
(Business Logic)
More Logic
(non-functional logic)
- Service Discovery
- Load Balancing
- Tracing
- Traffic Control
- Circuit Breaker
- Health Check
- Secure Data Transfer
Microservice 2
Instances
(Business Logic)
- Service Discovery
- Load Balancing
- Tracing
- Traffic Control
- Circuit Breaker
- Health Check
- Secure Data Transfer
Microservice-to-microservice Communication
- Logging
- Metrics
- Access Control
- Logging
- Metrics
- Access Control
More Logic
(non-functional logic)

14. Microservice 1
Standard capabilities
- Service Discovery
- Load Balancing
- Traffic Control
- Tracing
- Circuit Breaker
- Health Check
- Secure Data Transfer
- Logging
- Metrics
- Access Control
Standard capabilities
- Service Discovery
- Load Balancing
- Traffic Control
- Tracing
- Circuit Breaker
- Health Check
- Secure Data Transfer
- Logging
- Metrics
- Access Control
Microservice 2
Externalizing Capabilities

15. ● Tightly-coupled Solution
● Difficult code distribution/upgrade
● It doesn't fit the Microservice polyglot principle
Microservice
Library
- Service Discovery
- Load Balancing
- Traffic Control
- Tracing
- Circuit Breaker
- Health Check
- Secure Data Transfer
- Logging
- Metrics
- Access Control
Solution 1 - Library

16. ● Loosely-coupled Solution
● Microservice code is not impacted by a proxy upgrade
● It doesn't need to follow the Microservice technology implementation decisions (i.e. programming
language)
● All the income and outcome traffics are controlled by the proxy
Microservice 1
Proxy
- Service Discovery
- Load Balancing
- Traffic Control
- Tracing
- Circuit Breaker
- Health Check
- Secure Data Transfer
- Logging
- Metrics
- Access Control
Microservice 2
Proxy
- Service Discovery
- Load Balancing
- Traffic Control
- Tracing
- Circuit Breaker
- Health Check
- Secure Data Transfer
- Logging
- Metrics
- Access Control
Solution 2 - Proxy

17. Microservice 1
Proxy
Microservice 2'Proxy
Microservice 2''Proxy
Microservice 2'''Proxy
Solution – Proxy – Multiple Microservice instances
One problem remains: Who is in charge of the proxies configuration?

18. Microservice 1
Data Plane - Sidecar Data Plane - Sidecar
Control Plane
Policies Configuration Metrics Data
Metrics Data
Microservice 2
Service Mesh Pattern

19. ● Proxies don't do "call-outs": it would be a very big network consuming architecture
● Instead, it's a "push-based" architecture.
● Control Plane
○ Responsible for configuring all the proxies based on policies changes and
Microservices instances incarnation/termination
● Data Plane
○ The "runtime" part of the Service Mesh
○ Transparent proxy
○ Stores all the policies defined and pushed by the Control Plane
○ Reports the Control Plane with metrics
Service Mesh

20. • Service Mesh is an “Architecture Pattern” to address the microservice-to-microservice communication
requirements.
• There are some Service Mesh implementations available today including Istio (http://www.istio.io), Kuma
(https://kuma.io/), Linkerd (http://linkerd.io), etc.
Sidecar (proxy)
Service Mesh Pattern
Microservice 1
Business
Logic
Load Balancing,
Service Discovery,
Circuit Breaker, Traffic
Control, etc
Sidecar (proxy)
Microservice 2
Business
Logic
Load Balancing,
Service Discovery,
Circuit Breaker, Traffci
Control, etc
Service Mesh Control Plane

21. ● The network is reliable.
● Latency is zero.
● Bandwidth is infinite.
● The network is secure.
● Topology doesn't change.
● There is one administrator.
● Transport cost is zero.
● The network is homogeneous.
• L. Peter Deutsch, one of the original Sun "Fellows", is credited with penning the first seven
fallacies in 1994
• Bill Joy and Tom Lyon had already identified the first four as "The Fallacies of Networked
Computing”
• James Gosling, another Sun Fellow and the inventor of Java, added the eighth fallacy in 1997
Fallacies of Distributed Computing

22. Service Mesh – Circuit Breaker

23. Service Mesh – Load Balancing & Service Discovery
Microservice 1
Sidecar 1
Registry
Service Registration
Microservice 2 instances
Microservice 2
Sidecar 2
Microservice 2
Sidecar 2
Microservice 2
Sidecar 2
Service Discovery
Load Balancing

24. SidecarMicroservice Sidecar Microservice
SidecarMicroservice Sidecar Microservice
Control Plane
API Gateway
● Coarse-grained policies
● (i.e. Global rate-limiting,
User & App
Authentication, IP
Blacklist, etc.)
Service Mesh
Identity
Provider
Users & Apps
Requests
● Fine-grained policies
● (i.e. Specific Microservice
Cluster rate-limiting)
API Management & Service Mesh - Security Revisited

25. Microservices Architecture
Docker EngineDocker Engine
API Gateway
Firewall
Firewall
DMZ
Docker Engine
Outer Architecture
Microservice 1
Service Component
Service Component
Inner Architecture
Microservice 1
Service Component
Service Component
Inner Architecture
Microservice 2
Service Component
Service Component
Inner Architecture
Kubernetes Cluster
Docker & Kubernetes
Identity Provider
Mobile Apps End Users 3rd Party Apps

26. Microservices Architecture
Kubernetes PodKubernetes Pod
API Gateway
Firewall
Firewall
Mobile Apps End Users 3rd Party Apps
DMZ
Kubernetes Pod
Outer Architecture
Microservice 1
Service Component
Service Component
Inner Architecture
Microservice 1
Service Component
Service Component
Inner Architecture
Microservice 2
Service Component
Service Component
Inner Architecture
Message Channels / Message Queues
Sidecar 1 Sidecar 1 Sidecar 2
Service
Discovery
Circuit
Breaker
Health
Checks
Traffic Control
Service
Discovery
Circuit
Breaker
Health
Checks
Traffic Control
Service
Discovery
Circuit
Breaker
Health
Checks
Traffic Control
Service Mesh Control Plane
The Big Big Picture
Kubernetes Cluster
Identity Provider

27. Microservices &
Service Mesh
Workshop
Claudio Acquaviva