the need of cloud-native application
TRANSCRIPT
The Need of Cloud-Native Application (about Microservices, Containers, DevOps)
Emiliano Pecis
Senior Manager & Solution Architect
2
Agenda
Designing Microservices
Introducing New
Architectural Style
Deploying Cloud-Native Application
Cloud-Native Application Lifecycle
Summary
Introducing New Architectural Style
4
What our customers want
1. Improve Time To Market 2. Scale On Demand 3. More Resilient Systems
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
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
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
Yes, probably you’re right!
What do our customers need?
Cloud-Native Applications!
(able to live in distributed systems)
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?
10
Designing Microservices
11
Comparing Monolith Vs Microservices
Monolithic: Application divided by technology
Microservices: Application divided by domain
Image Credits:
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
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
§ 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
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
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
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
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
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
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
How to address distributed data management
Image Credits:
22
How to address distributed data management
Image Credits:
Deploying Cloud-Native Application
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
Docker is a shipping container system for code
26
Docker Vs classic VM
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
RedHat OpenShift (RedHat’s Containers As A Service)
Image Credits: RedHat
Cloud-Native Application LifeCycle (DevOps & CD)
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
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
Continuous Delivery is necessary
Summary
34 Image Credits:
35 Image Credits:
36 Image Credits:
37 Image Credits:
Thanks