Cloud-native architectures are an emerging practice of software development and delivery. This deck was presented at the Pivotal Cloud Native roadshow and teaches developers how to build modern cloud-native applications using the popular JVM-based application framework: Spring Boot. You'll be provided with a walk through from the monolith application architecture into the more modern microservices architecture. Two open source reference architectures are introduced for building cloud-native microservices. Learn the basics of cloud native platforms and also the approaches for integrating and strangling legacy systems.
https://pivotal.io/event/pivotal-cloud-native-roadshow
9. @kennybastani
We have now arrived at microservices…
Each team provisions self-service infrastructure, like a database, and builds a single application
Centralized resources are provided as backing services that are shared for data consistency, caching
19. Eventual consistency
Microservice architectures provide no guarantees about the correctness
of your data
So how can we guarantee high availability while also guaranteeing data
consistency?
21. Event Sourcing
Aggregates can be used to generate the consistent state of any object
It provides an audit trail that can be replayed to generate the state of an object from
any point in time
It provides the many inputs necessary for analyzing data using event stream
processing
It enables the use of compensating transactions to rollback events leading to an
inconsistent application state
It also avoids complex synchronization between microservices, paving the way for
asynchronous non-blocking operations between microservices
24. Event logs are transaction logs
Use event sourcing in your microservices to ensure consistency of your
distributed system
Don’t store state with microservices, store events
Use event stream processing to observe the active usage of your cloud
native application in real-time
29. What is a cloud service?
The platform provides services
The developer provisions services
The application uses services
30. Microservices != Cloud Native
Microservices are an architectural practice
Cloud native is a style of application development
Monoliths can equally be cloud native apps
37. @kennybastani
Application Server Deployment: Monolith
Load balancing requires provisioning
of new VMs and app server
installations
Poor resource isolation; memory
leaks can cause other applications to
become unavailable
Runtime environment is driven by the
operator
Virtual Machine
App
Linux Kernel
App App
Hardware Infrastructure
38. @kennybastani
Linux Container Deployment: Microservices
Development team drives the
application runtime of a container
Containers are resource isolated,
allowing efficient scheduling onto a
grid of VMs
Containers take seconds to start,
VMs take minutesVirtual Machine
Container
Linux Kernel
App App
App App
Container
App App
App App
Container
App App
App App
Hardware Infrastructure
40. @kennybastani
Container scheduling and auto-scaling
Minutes to provision and start a VM, but seconds to schedule and start a container
Auto-scaling becomes a feature of the cloud platform by scheduling on pool of VMs
43. @kennybastani
What is Spring Cloud?
Spring Cloud provides a way to turn Spring Boot microservices into distributed applications
44. @kennybastani
spring cloud
Apache Zookeeper
these logos are all trademark/copyright their respective owners (T-B, L-R):
Netflix, amazon.com, Apache Software Foundation, Cloud Foundry, Hashicorp
they are ALL great organizations and we love their open-source and their APIs!!
*
47. Service Discovery
Allows applications to find each other in an environment
An essential component when using dynamic container scheduling
Each application handles its own routing
Developers only need the name of a dependency, not the URL
A service registry is distributed to all subscriber applications
50. @kennybastani
Client-side Load Balancing
• Create discovery service
• Register user service
• Register user client
• Scale user service
• Reverse proxy from user client
to user service
User
Service
User
Service
User
Client
51. @kennybastani
Client-side Load Balancing
• Create discovery service
• Register user service
• Register user client
• Scale user service
• Reverse proxy from user client
to user service
User
Service
User
Service
User
Client
52. @kennybastani
Client-side Load Balancing
• Create discovery service
• Register user service
• Register user client
• Scale user service
• Reverse proxy from user client
to user service
User
Service
User
Service
User
Client
53. @kennybastani
Client-side Load Balancing
• Create discovery service
• Register user service
• Register user client
• Scale user service
• Reverse proxy from user client
to user service
User
Service
User
Service
User
Client
57. Config Server
Allows applications to source configuration from central service
Application configuration can be changed without deployment
Cascading configuration files for all apps and individual apps
Uses Git repository as file system, providing audit log of changes
Add Spring Cloud Bus to automate config refresh for many instances
63. Edge Service
API gateway pattern using Spring Cloud Netflix Zuul starter project
Embeds relative routes from other services registered with Eureka
Automatic method for reverse proxying to other services
Routes are displayed at /routes of the Spring Boot app
64. Benefits
Provides a secure gateway to compose together REST APIs
exposed by backend microservices
Front-end developers can integrate with a single API over HTTP to
communicate with potentially many microservices
Front-end applications can further embed an edge service to avoid
the need to manage CORS and authentication concerns
67. Spring Cloud Sleuth
Spring Cloud Sleuth is a project that adds distributed tracing
capabilities to your distributed Spring Boot applications
https://cloud.spring.io/spring-cloud-sleuth/
http://zipkin.io/
71. Going Cloud Native
Legacy migration challenges
“How do I change the engine of the aircraft while it’s still in flight?”
Approaches
Lift-and-shift
Big bang refactor and migration
Iterative legacy modernization
73. Strangler Pattern
“Gradually create a new system around the edges
of the old, letting it grow slowly over several years
until the old system is strangled.”
— Martin Fowler
74. Strangler vines—seed in the upper branches of a fig tree and gradually work their
way down to the soil—strangling and eventually and killing the tree
75. Strangling legacy using microservices
How can we take advantage of building microservices that also
strangle data from the edge of legacy systems?
76. The problem with data
The most common pain point that companies experience when
building microservices is handling domain data
Your domain data is likely going to be trapped inside a large
shared database—probably being of the Oracle or IBM variety
Because of this, your new microservices will be dependent on
retrieving data from a large shared database
77. Fetching data from the legacy system
Microservices can reach into the legacy system and fetch data
in the same way that front-end applications do
While this isn’t a good long-term strategy, it can be an
intermediate step in gaining control over the legacy backend
79. Agile benefits of extending domain data
We gain the benefit of agility in microservices by extending base
domain objects retrieved from a legacy system
New feature changes are moved out to the new microservice,
using an indirection layer to maintain backward compatibility
with the legacy system
81. Advantages
The legacy system does not need to be altered to support the
development of new microservices
New features can be deployed independently without being
tightly coupled to the legacy system
It ensures that any existing calls to a legacy web service are
unaltered for other apps
82. Disadvantages
Scalability may be a concern in the case that the base legacy
service is not cloud-native
Availability will be impacted if the base legacy service’s shared
database suffers an outage
The dependency on the legacy system’s shared database is
increased, making it harder to decompose
84. Point-to-point Connections
If your architecture has brittle point-to-point connections, code
changes may be required to create a legacy indirection layer
If you’re building microservices on top of an SOA and are using an
ESB, an indirection layer already exists
87. Data Acquisition
We can use the Legacy Edge service to adapt responses from
microservices into the native formats expected by legacy
applications
We can also acquire data from the legacy system and migrate
the system of record to a microservice, without refactoring the
current database
95. In the end..
Do what makes sense for your architecture
Worry deeply about who cleans up after you
Building software is more about people than it is tools
96. Full open source examples on my blog
http://www.kennybastani.com
98. Cloud native applications
“If you have to implement the same functionality in each
application, it should instead be provided as a service using the
platform” – Matt Curry @ Allstate
Do this well, and the only thing you’ll be left with is the valuable
business logic in your applications
101. Legacy culture
Before you can even begin to address the handling of legacy in a
new microservice architecture, you’ll need to address a legacy
culture
Some developers may believe a piece of legacy code is beautiful,
and has done its job without change for many years
Handling the culture shift is a delicate matter. Get people on
board before imposing changes
103. This is what dropping a legacy application in a Docker
container and calling it a microservice looks like..
104. Legacy applications
Not all legacy needs to be destroyed right away
Make sure to take an iterative approach to go cloud-native that
promises backwards compatibility with legacy applications
The goal is to lessen the impact to users over time before making
a decision to phase out legacy applications and infrastructure
Developers dream of strangling legacy, but it likely still generates
revenue for the business