Building Cloud Native Architectures with Spring

© 2016 Pivotal Software, Inc. All rights reserved.@kennybastani

Building Cloud Native Architectures with Spring

Kenny Bastani Spring Developer Advocate Pivotal Cloud Native Roadshow 2016

1

Kenny Bastani

@kennybastani

Spring Developer Advocate

Agenda

Agenda

1 Microservices & Cloud Native

2 Reference Architecture

3 Spring Boot

4 Spring Cloud

5 Dealing with Legacy


MicroservicesHow did we get there?

4

We started with the monolith…


Cultural problems with monoliths

6

Slows our velocity getting into production

It takes too long to ramp up new engineers

The code base is just too large for anyone one person to fully comprehend

Centralized authority and change management slows progress (DBA, Ops)


Operational problems with monoliths

7

Coordinated releases batch many changes together from different teams

Operations drives the runtime environment of applications

Operators take on all operational responsibility (including VM upgrades)

Deploy everything at once or nothing at all

We then moved towards SOA…

@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


Online Store ExampleCloud native application as microservices

10

@kennybastani

Open Source Example

http://online-store-web.cfapps.io https://github.com/kbastani/spring-cloud-event-sourcing-example

Demo Username: user Password: password

http://online-store-web.cfapps.io

https://github.com/kbastani/spring-cloud-event-sourcing-example


Eventual consistencyHandling the guarantees of an eventually consistent microservices architecture

18

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?

Transaction logs

Event SourcingAggregates 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

Event Types

Event Log

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


The Cloud Native StackWhat are the components of a cloud-native architecture?

25

What is a cloud-native application?

The cloud provides resources

The platform provides services

The application provides value

Platform Services

What is a cloud service?

The platform provides services

The developer provisions services

The application uses services

Microservices != Cloud Native

Microservices are an architectural practice

Cloud native is a style of application development

Monoliths can equally be cloud native apps

Monolith to Microservice

Splitting the Monolith: User Service Migration


Spring BootA JVM micro-framework for building microservices

33

What is Spring Boot?

@kennybastani

spring boot

Spring Initializr for boostraping your applications

supports rapid development of production-ready applications and services


Cloud Native PlatformsShipping applications in containers instead of shared application servers

36

@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

@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

ContainerApp App

App App

ContainerApp App

App App

Hardware Infrastructure

@kennybastani

Microservices: Container Deployment

Each microservice can be containerized with their application dependencies

Containers get scheduled on virtual machines with an allotted resource policy

@kennybastani

Container scheduling and auto-scalingMinutes 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

@kennybastani

Distributed ApplicationsEach microservice will likely need to communicate with other containers

Service discovery automates how distributed apps find service dependencies


Spring CloudA toolset designed for building distributed systems

42

@kennybastani

What is Spring Cloud?Spring Cloud provides a way to turn Spring Boot microservices into distributed applications

@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!!

*

http://amazon.com


Spring Cloud DemosApplying the patterns of cloud-native architectures with Spring Boot and Spring Cloud

45

@kennybastani

Spring Cloud: Cloud Native Patterns

Service Discovery

API Gateway

Config Server

Circuit Breakers

Distributed Tracing

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

Discovery Service

Service Registry

@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

UserService

UserService

UserClient


Config ServerCentralizing config management for microservices with Spring Cloud Config Server

56

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

Configuration Server


API GatewayBuilding edge services that route requests to backend microservices

60

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

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


Distributed TracingTracing the Online Store

66

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/

https://cloud.spring.io/spring-cloud-sleuth/

http://zipkin.io/

Zipkin Dashboard


Strangling Legacy with MicroservicesHow do I build microservices that are cloud-native without doing a big bang refactor?

70

Going Cloud NativeLegacy 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

Problems with lift-and-shift

Brings your tech debt into the cloud

Rolling maintenance windows until migration is complete

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

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

Strangling legacy using microservices

How can we take advantage of building microservices that also strangle data from the edge of legacy systems?

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

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

Extending Domain Data

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

Legacy Indirection Layer

AdvantagesThe 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

DisadvantagesScalability 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

Point-to-point Connections

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

Centralized ESB

ESB Indirection Layer

Data AcquisitionWe 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


Reference applicationOpen source example of strangling legacy

88

Let’s talk about theory and practice

The first law of microservices.

It depends.

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

Full open source examples on my blog

http://www.kennybastani.com

http://www.kennybastani.com

Wrapping up…

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

The two road blocks of cloud native

Legacy culture

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

Legacy applications

This is what dropping a legacy application in a Docker container and calling it a microservice looks like..

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

Building Cloud Native Architectures with Spring

Software

Transcript of Building Cloud Native Architectures with Spring