Where SOA and Monolitch EAR have failed. It's not simple to have your Apps scaling automagically without a very complex architecture. We're going to show pros and cons of so called Cloud-Native Applications based on Microservices, Caas, DevOps, Continuous Delivery....

1. The Need of Cloud-Native Application
(about Microservices, Containers, DevOps)
Emiliano Pecis
Senior Manager & Solution Architect

2. 2
Agenda
Designing
Microservices
Introducing
New
Architectural
Style
Deploying
Cloud-Native
Application
Cloud-Native
Application
Lifecycle
Summary

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?

10. 10
Designing Microservices

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:

23. Deploying Cloud-Native
Application

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

29. Cloud-Native Application
LifeCycle (DevOps & CD)

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

34. 34 Image Credits:

35. 35 Image Credits:

36. 36 Image Credits:

37. 37 Image Credits:

38. Thanks