Move fast and make things with Microservices

Move fast and Make things with Microservices

Transcript

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 External In 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 External In 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 External In 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