1. How to apply microservices patterns & anti-patterns to design the right architecture 2. Why & how to build a core framework to ensure consistency & manage complexity 3. What are the challenges in adopting gRPC for inter-service communication 4. How to orchestrate & manage microservices at scale with Kubernetes 5. How to leverage Cloud Native ecosystem to move fast & avoid vendor lock-in

1. Move fast and make things with
Microservices
Lessons of running Microservices at scale with Docker & Kubernetes

2. Mithun Arunan
Architect, @Vernacular.ai
@MithunArunan

3. ➢ Must scale to millions of users
➢ Support multiple platforms
➢ Handle complex business rules
➢ Competitive in a fast moving market
➢ Flexibility to choose the cloud vendor or go on-premise
How do you support these requirements while moving fast and innovating?
Let’s say I wanted to build a large application

4. Microservices @Vernacular.ai

5. A pattern language is a method of describing good design practices or
patterns of useful organization within a field of expertise.
A pattern language defines these relationships between the patterns,
➢ Alternative pattern
➢ Predecessor pattern
➢ Successor pattern
Applying microservices pattern language

6. Application Architecture Pattern
Decision #1
Monolithic Architecture
or
Microservice Architecture

7. Monolithic architecture
Backend
Services
Load
Balancer
Backend
Replica 1
Backend
Replica 2
DB
Simple to Develop
Simple to Deploy
Simple to Maintain
Browser

8. Monolithic architecture
Backend
Services
Load
Balancer
Backend
Replica 1
Backend
Replica 2
DB
Browser
Hard to understand
Hard to scale
Long term commitment
Hard to debug
Obstacle to scaling dev

9. Courtesy: https://dzone.com/articles/scale-cube-simplified-scale-model
Scale Cube

10. Define an architecture that structures the application as a set of loosely
coupled, collaborating services. This approach corresponds to the Y-axis of
the Scale Cube.
Services communicate using either synchronous protocols such as
HTTP/REST or asynchronous protocols such as AMQP.
Services can be developed and deployed independently of one another.
All the drawbacks of Monolithic architecture becomes advantages of
microservices
Microservices Architecture

11. Microservices architecture
Easy to understand
Easy to scale
Easy to Re-write
Easy to debug
Courtesy: https://dzone.com/articles/building-microservice-using-spring-boot-and-secure

12. Decision #2
How to decompose application into
microservices?
Application Pattern

13. Conway’s law
Any organization that designs a system (defined broadly) will produce a
design whose structure is a copy of the organization's communication
structure.
➢ Decompose by business capability - Echoes Conway’s law
➢ Decompose by subdomain - Echoes the inverse of Conway’s law
Decompose applications into microservices

14. Decompose applications into microservices

15. Decision #3
How to maintain data consistency and
perform queries
Application Pattern

16. Data patterns

17. Saga Pattern
A saga is a sequence of
local transactions. Each
local transaction updates
the database and
publishes a message or
event to trigger the next
local transaction in the
saga.
➢ Choreography
➢ Orchestration

18. Decision #4
How to establish fast and reliable
inter-service communication?
Application & Infrastructure Pattern

19. Communication
Patterns
Courtesy: microservices.io

20. Discovery
➢ Client-Side Discovery
➢ Service-Side Discovery
Courtesy: microservices.io

21. Communication
Patterns
Courtesy: microservices.io

22. HTTP/1.1 vs HTTP/2.0
HTTP/1.x does not compress request and
response headers, causing unnecessary
network traffic
HTTP/1.x makes poor use of the underlying
TCP connection
HTTP/2 reduces latency by enabling,
➢ Request and response multiplexing
➢ Minimize protocol overhead
➢ Multiple concurrent exchanges on the
same connection
HTTP/3 is under experimentation

23. gRPC - Quickstart
REST -> HTTP/1.1 + JSON
gRPC - HTTP/2 + Protobuf
Define your service definition in a
proto file
Automatically generate idiomatic
client and server stubs for your
service in a variety of languages and
platforms
Use the runtime libraries for
programming languages of your
choice and write client and server.
gRPC Go - Example

24. Microservices @Vernacular.ai

25. ➢ Number of microservices ≠ Successful microservice architecture
➢ Individual teams adopting microservice architecture without any platform
support or coordination
➢ Retaining the same development process and organization structure that
were used when developing monolithic applications.
Microservices Anti-Patterns

26. Decision #5
How to deploy, monitor and scale?
Infrastructure Pattern

27. Sad state of DevOps

28. Sad state of DevOps

29. Sad state of DevOps

30. Deploy using Kubernetes and Docker
Load
Balancer
Compute Engine
10GB PD
1 4 20
Compute Engine
10GB PD
1 4 20
Compute Engine
10GB PD
1 4 20
DBs
SQL
Storage
NFS
Cache
Redis
Logging
Monitoring
Compute Engine
10GB PD
1 4 20
Compute Engine
10GB PD
1 4 20
Front 1
Front
Front 1
Back
Front 1
Front
Front 1
Front
Front 1
Back
Front 1
Back
Front 1
Back
4
4 Cores
16GB RAM
External DBs and Storage
Management tools
Total Light
Defragmentation
Portability
Multiple environments
Only 1 process
Compute cluster
Service discovery
Load balancing
Self healing & resiliency
Horizontal scaling
Automated rollouts and
rollbacks
Centralized logs
Easy CI/CD

31. Service Mesh (Linkerd) - Monitoring
App
App
App
App App
App
ExternalIn cluster
API 1
API 2
API 3
Load
Balancer
What’s the latency?
MONITORING?
How many 5xx ?
How many RPS ?
Observability
Tracing

32. Service Mesh (Linkerd) - Security
App
App
App
App App
App
ExternalIn cluster
API 1
API 2
API 3
Load
Balancer Is it secure?
Is it authenticated?
Who is talking to
me?
Is this allowed?
SECURITY?

33. Service Mesh (Linkerd) - Reliability
App
App
App
App
App
App
ExternalIn cluster
API 1
API 2
API 3
Load
Balancer
App
Version A
Version B
10%
90%
Failing
Where is the retry policy
implemented?
How is canary
deployment done?
ADVANCED RULES?
Canary
A/B
Fault injection
Retry policy
Configure timeouts?

34. ➢ Tight security with restricted access to public internet
➢ Delay in procuring hardware makes scaling up VMs without capacity
planning impossible
➢ Operational overhead of installing, upgrading and monitoring infrastructure
➢ Complexity of managing many deployment configurations
➢ Supported OS vary from client to client
On-Premise vs On-Cloud
Challenges on deploying solution on-premise

35. Leveraging Cloud Native technologies to go on-premise
➢ Harden application security
○ Compile-time languages to build binaries
○ Removing all sensitive information from code
➢ Dockerize all applications
○ Multi-stage docker builds to remove traces and ship the binaries
➢ Setup Kubernetes cluster on-premise on any Operating System of choice
➢ Helm charts for managing deployment complexities
➢ Leveraging cloud native stack for Monitoring, Logging using Prometheus &
EFK stack

36. Thank you