Microservices deck
Download as PPTX, PDF•1 like•136 views
This document discusses building event-driven, fault-tolerant microservices. It begins by discussing lessons learned from SOA architecture and defining microservices. It emphasizes that microservices need to be reactive and message-driven to achieve loose coupling and fault tolerance. The document then outlines challenges in implementing microservices at scale before proposing a design using Spring Boot, Kafka, Docker, and Elastic Stack. It provides an in-depth look at these components and how they address scalability, isolation, fault tolerance and monitoring of microservices.
Microservices deck
- 1. Building event-driven, fault tolerant microservices Mahesh Veerabathiran
- 2. Agenda • Lessons learnt from SOA architecture • What is microservice? • Microservices has to be Reactive • Challenges in microservices implementation • Proposed design: Spring boot + Kafka + Docker + Elastic stack • Microservice components – Deep dive • Demo
- 3. Lessons learnt from Monolith & SOA architecture • SOA made a big leap from Monolithic architecture and laid the foundation for the future. • Four main principles of SOA • Boundaries are explicit • Services are autonomous • Services share schema and contract, not class • Service compatibility is based on policy • However SOA can comprise multiple small/micro services all are related to single large functionality and shares centralized data storage.
- 4. What is microservice • Microservices is an architectural pattern that decompose application in to logical set of microservices where each microservice is assigned single responsibility and loosely coupled that enables speed and efficiency to build and manage application • Microservices are language, platform and operating system-agnostic • Microservices design pattern is inherited from SOA, retained the good ideas and re-architected from the ground up with Reactive principles. • That’s the reason, it is also referred as SOA 2.0 or SOA with Devops
- 5. Microservices has to be reactive • The fundamental trait of microservice is isolation so that the microservice can be independently deployed. • As long as microservices are strongly coupled (communication between microservices), there is always a dependency on time and order the microservice deployment should take place. • Microservices should embrace asynchronous message driven communication to achieve isolation. • Message driven communication supports graceful error handling during the outage of microservice and avoid cascading failure.
- 6. Challenges in Microservices Implementation • How do we manage fleet of microservices? • How do we strike right balance in infrastructure usage? • How do we achieve isolation when microservices share computing hardware? • How do we load balance microservices request? Do we need one or more load balancers? • How do we monitor and replace unhealthy microservice? • How do we aggregate system and application log metrics across microservices? • How do we enable fault tolerance in microservices?
- 7. Thankfully… We have access to reliable open source technologies, frameworks, tools and public cloud resources than 10 – 15 years ago.
- 8. LS LS LS LS DOCKER DAEMON PUBLIC CLOUD
- 9. Components deep dive: Apache Kafka • Kafka is a distributed message system that’s offers reliable message communication at scale • Kafka enables loose coupling between producers and consumers via message communication. • Kafka provides out of box fault tolerant support. • If one Kafka broker is down, the other broker assumes responsibility and start processing messages where it left off. • Messages sent to Kafka are stored and delivered when the consumer is available
- 10. Components deep dive: Apache KAFka • Kafka has four main components • Broker • Also known as Kafka server where messages sent are stored. • Messages are categorized by topics. Similar to tables in Relational database. • Kafka supports parallelism. The content of topics can be partitioned and stored across brokers. • Kafka replicates topic data in one or more brokers for fault tolerance. • Kafka broker has many optional features which can be toggled on/off through its configuration file server.properties
- 11. Components deep dive: Apache KAFka • Zookeeper - It is centralized service for metadata about nodes in the cluster • Manages cluster membership • Topic leader assignment • Maintains health and synchronization status • Producer • One or more client application that sends messages to Kafka topic. • Kafka producer supports following message sending methods • Fire and Forget (Acks - 0) • Asynchronous send • Synchronous send
- 12. Components deep dive: Apache KAFka • Kafka producer guarantees message ordering within a partition. • Kafka producer supports configurable retry option to resend failed messages. • All messages must be serialized before sending to topic. It supports string serialization by default. • If message sent is an object, producers should pass custom serializer to write messages • Kafka also supports generic serialization library such as Apache Avro to send messages
- 13. Components deep dive: Apache KAFka • Consumer • Client application polls and retrieves messages from the topic • Kafka achieves consumption at scale using Consumer group. • A group of consumer can process distinct messages from topic. • Consumer group can be formed by setting same value for group.id config. property • One or more Kafka consumer can consume same copy of messages from topic. • Consumer commits the last committed offset in special topic named _offsets. • Each consumer can process the message at its will, irrespective of other consumer consumption rate. • You can’t have more than one consumer in a single thread.
- 14. Components deep dive: Docker • Docker is an open platform for developing, shipping and running applications as a light weight, portable, self sufficient container that can run virtually anywhere. • Containers are isolated from other containers run in same hardware. • Each container has it own file system and shares only kernel with others. • Each micro service do not need its own VM, it can coexist without trading off isolation. • Docker containers can be deployed and tested in local machine as same as running in public cloud.
- 15. Components deep dive: Docker swarm • With Docker engine 1.12, Docker ships native cluster management tool called Swarm. • Docker Swarm provides out of box support for the following • Load balancer • Service discovery • Scaling and Rolling updates. • Docker supports multiple networking methods for container communication • Bridge network for communication between containers live in same host • Overlay network for communication between containers across nodes in the cluster • Routing mesh network for routing external service request to containers located in the cluster
- 16. Docker Swarm vs Other cluster mgmt. tools
- 17. Docker Swarm vs Other cluster mgmt. tools • Alternative cluster management tools are Kubernetes, Mesos and ECS. • Kubernetes is powerful cluster management tool for Google. Kubernetes installation is more involved and difficult to use. • Both Docker and Kubernetes renders good performance at scale. Kubernetes has additional nuanced control over containers that makes it slightly better than Docker. • Since the performance gap between Docker and Kubernetes is closing. Docker is great tool for anyone who looks for single solution tool.
- 18. Components deep dive: Spring boot • Spring boot is an opinionated Java framework for building micro services based on Spring dependency injection framework • Spring boot addresses the complexity in getting started with Spring based application development. • Spring boot does things automatic for you but allow you to override the defaults. • Spring boot actuator module exposes application metrics via Rest endpoints for production monitoring • E.g. /metrics, /health
- 19. Components deep dive: Monitoring • Monitoring microservices are little trickier than conventional application. • Monitoring should be enabled for all components that makes up the microservices ecosystem. • Components need to be monitoring for our use case are follows • Monitor and scale Kafka cluster • Monitor and scale Docker swarm nodes • Monitor and scale Spring boot docker applications • Since monitoring is complex, many vendors offers monitoring solution as a service to exploit our knowledge gap.
- 20. Components deep dive: Elastic stack As I mentioned earlier, they are enough open source alternatives for microservice ecosystem including monitoring. Of course, there is no single open source tool that has out of box support for all monitoring needs but with little effort, we can build quality monitoring and dashboards. • Using Elastic stack as an primary tool for monitoring that includes Filebeat, Logstash, Elastic search and Kibana. • Making use of Google’s cadvisor to fetch container resource usage. • Fetching cluster state and usage metrics using Docker remote API. • Collecting kafka broker metrics exposed via Http endpoint by Jolokia.
- 21. Components deep dive: Elastic stack monitoring • All monitoring components are configured and deployed as Docker containers too. • All log aggregation components such as filebeat, logstash are deployed in all cluster nodes • Elastic search and kibana components need not be installed at every node.
- 22. DEMO