The Need of Cloud-Native Application
9 likes2,404 views
The document discusses the need for cloud-native applications using microservices, containers, and DevOps to improve time to market, scalability, and system resilience. It contrasts microservices with monolithic architectures, emphasizing the benefits of decentralized data management and service orchestration. Key components such as API gateways, service discovery, and circuit breakers are highlighted as essential for managing cloud-native application lifecycles.
The Need of Cloud-Native Application
- 1. The Need of Cloud-Native Application (about Microservices, Containers, DevOps) Emiliano Pecis Senior Manager & Solution Architect
- 3. Introducing New Architectural Style
- 4. 4 What our customers want 1. Improve Time To Market 2. Scale On Demand 3. More Resilient Systems
- 5. 5 Why SOA can’t 1. Improve Time To Market 2. Scale On Demand 3. More Resilient Systems Think to the real-world use cases: • Is SOA able to introduce new features quickly? • Have you ever seen a SOA in the cloud? • Is SOA able to degrade gracefully?
- 6. 6 Why Monolith can’t Monolith is simple to develop, test and deploy but: • If project is alive it grows and become a ball of mud • It is too large for any single developer to fully understand • Startup time could take from 10 to 15 mins • A bug in any module can potentially bring down all 1. Improve Time To Market 2. Scale On Demand 3. More Resilient Systems
- 7. 7 Netflix was still operating as a monolith, a single missing semicolon “;” brought down the entire Netflix website for several hours… Why monolith can’t
- 8. 8 Yes, probably you’re right! What do our customers need? Cloud-Native Applications! (able to live in distributed systems)
- 9. 9 How to develop & deploy cloud-native applications? Adopting a Microservices Architecture Pattern leveraging on infrastructure automation (on prem and cloud) using DevOps tools and culture. What do you mean?
- 11. 11 Comparing Monolith Vs Microservices Monolithic: Application divided by technology Microservices: Application divided by domain Image Credits:
- 12. 12 Introducing Microservices • Microservices are “small Autonomous services that work together” • All microservices must be independently deployable and upgradable • Microservices must respect “Single Responsibility Principle” • Some microservices expose an API that’s consumed by other microservices • Other microservices communicate with each other through asynchronous messaging Image Credits:
- 13. 13 Decentralized Data Management • The microservices architecture pattern impacts the relationship between application and the database • Each of the services has its own database • A service can use a type of database that is best suited to its needs! • It often results in duplication of some data but is necessary to ensures loose coupling! Image Credits:
- 14. 14 § Orchestration needs a director to change things at runtime § The downside to this orchestration approach is that the customer service can become too much of a central governing authority Orchestration Vs Choreography § Choreography is decided at design time (but you can change frequently thanks to CD) § The downside is the monitoring that is too complex Customer Service Loyalty points bank Post Service Email Service Create point balance Send Welcome Pack Send Welcome Pack Customer created event Loyalty points bank Post Service Email Service Subscribes Subscribes Subscribes Customer Service Publishes
- 15. 15 The need of API Gateway • An API Gateway is a server that is the single entry point into the system • The API Gateway is responsible for request routing, composition, and protocol translation • All requests from clients first go through the API Gateway. It then routes requests to the appropriate microservice • It might have other responsibilities such as authentication, monitoring, load balancing, caching, request shaping and management, and static response handling Image Credits:
- 16. 16 The need of API Gateway • To reduce the chattiness inherent in the REST API, the discrete requests in the diagram above will be collapsed into a single request optimized for a given client. • The benefit is that the device then pays the price of WAN latency once and leverages the low latency and more powerful hardware server-side.
- 17. 17 The need of Service Discovery • The network location of a service instance is registered with the service registry when it starts up • It is removed from the service registry when the instance terminates • The service instance’s registration is typically refreshed periodically using a heartbeat mechanism Image Credits:
- 18. 18 The need of Circuit Breaker • Circuit breaker pattern: track the number of successful and failed requests. If the error rate exceeds a configured threshold, close the circuit breaker so that further attempts fail immediately. • If a large number of requests are failing, that suggests the service is unavailable and that sending requests is pointless. After a timeout period, the client should try again and, if successful, close the circuit breaker. • Provide fallbacks: perform fallback logic when a request fails. For example, return cached data or a default value, such as an empty set of recommendations.
- 19. 19 Don’t reinvent the wheel! Netflix open sourced all its software and Spring has productized all of them: • Netflix Eureka: Service registry & discovery • Netflix Hystrix: Circuit breaker and dashboard • Netflix Ribbon: Client-side load balancing • Netflix Zuul: Reverse proxy for API Gateway • Spring Cloud Config: Centralize configuration • Spring Cloud Bus: Publish events over RabbitMQ Lightbend built a new Microservices framework from scratch called Lagom, composed by: • Play • Akka • Cassandra • Sbt • Guice
- 20. 20 Good. But what about Data Consistency? Consistency Partition Tolerance Availability N/A • Acid Transactios are perfect in a monolithic application • They cannot work on distributed system because of CAP Theorem but also because, by design: • Each microservice can have a different type of database • The data owned by each microservice is private and can only by accessed via its API CAP Theorem: pick 2 of 3
- 21. 21 How to address distributed data management Image Credits:
- 22. 22 How to address distributed data management Image Credits:
- 24. 24 Virtual Machines needs care and feeding: § Name the VM § Tune and groom regulary § Feed pets with good food § Take pets to the vet when they are sick Treating servers as cattle, not as pets! Cloud servers are disposable: § VM are not unique § Tune and groom apps not the cattle § Replace when necessary § Kill it when it is sick
- 25. 25 Docker is a shipping container system for code
- 26. 26 Docker Vs classic VM
- 27. 27 Docker ecosystem • Docker Compose is a tool for defining and running multi-container Docker applications • Docker Swarm provides native clustering capabilities to turn a group of Docker engines into a single, virtual Docker Engine. With these pooled resources, you can scale out your application as if it were running on a single, huge computer. • Docker Hub is Docker’s cloud service for publishing and discovering container images through the public registry
- 28. 28 RedHat OpenShift (RedHat’s Containers As A Service) Image Credits: RedHat
- 30. 30 Life Cycle changes with Microservices ! • Cross-functional team. Because we are following mostly the domain-driven approach, the idea is to have a cross- functional team • Just two pizzas. Jeff Bezos said:“If you can't feed a team with two pizzas, it's too large. That limits a task force to five to seven people, depending on their appetites” • Products not Projects. Team responsible for a service should own a product over its full lifetime, from development to mantainance.!
- 31. 31 What does “cross-functional team” mean? • A team able to develop, test, deploy a (micro)service from dev to production env • A team with the all necessary skills: developers, testers, dba, sysadmins, and so on… • A team that takes responsability of its project product All these things mean DevOps!
- 32. 32 Continuous Delivery is necessary
- 33. Summary
- 38. Thanks