Target Audience Level Extended Abstract - sigs.de · New Design Patterns Emerging ... © Copyright...

transcript

Target Audience: Architects, Developers, Project Leader, Manager, Decision MakersPrerequisites: basic knowledge about cloud and containers helpful but not necessaryLevel: Introductory

Extended AbstractThis session shows a case study about successfully moving from a very complex monolith system to a cloud-native architecture. The architecture leverages containers and Microservices to solve issues such as high efforts for extending the system, and a very slow deployment process. The old system included a few huge Java applications and a complex integration middleware deployment.The new architecture allows flexible development, deployment and operations of business and integration services. Besides, it is vendor-agnostic so that you can leverage on-premise hardware, different public cloud infrastructures, and cloud-native PaaS platforms.The session will describe the challenges of the existing monolith system, the step-by-step procedure to move to the new cloud-native Microservices architecture, and why containers such as Docker play a key role in this scenario.A live demo shows how container solutions such as Docker, PaaS cloud platforms such as CloudFoundry, cluster managers such as Kubernetes or Mesos, and different programming languages are used to implement, deploy and scale cloud-native Microservices in a vendor-agnostic way.

Case Study: How to move from a Monolith to Cloud, Containers and Microservices

Kai WähnerTechnology Evangelist

kontakt@kai-waehner.de

@KaiWaehner

www.kai-waehner.de

OOP 2017 (Munich, Germany)

Case Study: How to move from a Monolith to Cloud, Containers and Microservices

Evolving Demands from the Business

AGILITY & SPEED

REDUCED CYCLE TIMES

WEB SCALE

LOWER COST

FAIL FAST

• A cloud-native architecture enables flexible and agile development• Only vendor- and platform-agnostic architectures are future-safe • Various programming languages, open source frameworks and middleware

complement each other well in a Microservices world

Key Takeaways

1) A Legacy Monolith Application

2) The Move to Microservices

3) The Need for a Cloud Native Platform

4) Cloud Native Microservices

5) Live Demo with Docker, Kubernetes, Cloud Foundry

Agenda

Big and Complex Monolith

Monolith 1

„Big SOA Application“

Monolith 2

Monolith 3

Cloud-Ready

On PremisePublic Cloud

CRM ERM Host ...

#1On premise will not die.

Not everything will or should go to the cloud!

Various Technologies Glued Together

Middleware

Development Environment

Zero Coding

Code Everythingor anything in between

#2 Visual coding works,

even for very complex scenarios. Forget the early 2000 SOA days!

Agenda

Microservices Example

http://www.ibm.com/developerworks/cloud/library/cl-bluemix-microservices-in-action-part-1-trs/

Eachtileisamicroservice

“bookflights”interactswithothermicroservices

Heightcorrespondstousage

Eachmicroservice canbeIndependentlymanaged

à Shorter time to results and increased flexibility / scalability

à Replace small pieces instead of a complete application

From a Monolith to Microservices

Business Service A1

Java EE

Cloud-Ready

On PremisePublic Cloud

CRM ERM Host ...

Business Service A2

Python

Integration Service A3

Middleware

Business Service B1

Business Service B3

Python

Business Service B2

Integration Service B4

Middleware

Various Forms of (Micro)Services

Integration Service

Monolith application SOA

Integration Service

Service ServiceService Service

API Management

SaaS Service BPM Service

Distributed Microservice Architecture

http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the-outside/

”That complexity has moved and

[…] increased [to] the outer

architecture.”

New Challenges Emerging…

http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

”[…] when considering Microservice like architectures, it's really important to not be attracted

to the hype on this one as the challenges and costs are as real as the benefits."

• Different Languages / Technologies• DevOps Skills Required• Distributed System Complexity

• Distributed Configuration• Service Discovery• Resiliency• Client Side Load Balancing

• Testability Challenges• Orchestration / Integration

• Spaghetti Communication (again ?!)• Re-Delivery• Re-Route• Cache• ...

New Design Patterns Emerging…

Resilience Design Patterns

Features• Fail fast and rapidly recover• Prevent cascading failures• Latency tolerance logic• Fault tolerance logic• Fallback Options

http://martinfowler.com/bliki/CircuitBreaker.htmlhttps://github.com/Netflix/Hystrix/wiki

maxFailures = 5

resetTimeout = 1min

callTimeout = 10sà maxFailures++

Example: Circuit Breaker

#3 Microservices are not free lunch.

They do not fit into every scenario!

Open API and API Management

New Design Patterns Emerging…

http://samnewman.io/patterns/architectural/bffhttps://www.thoughtworks.com/insights/blog/bff-soundcloud

Example: Backends for Fronteds (BfF)

#4 Design Microservices

with open APIs in mind!

Agenda

“Cloud washing is the purposeful and sometimes deceptive attempt by a vendor to rebrand an old product or service by associating the buzzword ‘cloud’ with it [and offering it via a public cloud infrastructure].”

Cloud Washing vs. Cloud Native

http://searchcloudstorage.techtarget.com/definition/cloud-washing

12 Factor Apps for Cloud Native Microservices

Codebase

One codebase tracked in

revision control, many deploys.

Dependencies

Explicitly declare and isolate

dependencies.

Config

Store config in the environment.

BackingServices

Treat backing services as attached resources.

Build, Release, Run

Strictly separate build and run

stages.

Processes

Execute the app as one or more

stateless processes.

Port Binding

Export services via port binding.

Concurrency

Scale out via the process model.

Disposability

Maximize robustness with fast startup and

graceful shutdown.

Dev / Prod Parity

Keep dev,staging, and

prod as similar as possible.

Treat logs as event streams.

Admin Processes

Run admin/mgmt

tasks as one-off processes.

https://12factor.net/

• Scalable services

• Service Discovery

• Load balancing and failover

• Resiliency

• DevOps and automation

• Usage of public cloud platforms, but also private or hybrid

• Self-service, pay-as-you-use, multi-tenancy

• Vendor-agnostic deployment

Cloud Native (à not just Microservices)

à Focus on business problems (after initial start-up efforts)

#5 Cloud-Native means much more

than a “cloud-washed” application deployed to a cloud provider!

== The Momentum of Containers

How to deploy independent Applications or (Micro)Services?

Garden

Why Containers?

http://www.slideshare.net/andersjanmyr/docker-the-future-of-devops

Containers enable:

• Lightweight deployment

• Automation

• Better resource utilization

• Scaling up and down quickly

• Platform agnostic deployment

• Innovation and Fail Fast Concepts

• Standardization ? Ø The Open Container Initiative (OCI)Ø Docker Fork Discussions (!!!)

… the Container Wars just began!

https://www.infoq.com/articles/container-landscape-2016

#6 Microservices and Containers are often used together,

but also work very well without each other!

Cloud-Native Architecture

Containers are just the Foundation for a Cloud Native Architecture!

Cloud Native Platform (Infrastructure-as-a-Service)

Choose your IaaS

Private or Hybrid Cloud

Reduced costs of Infra

Self-hosted & Controlled Env

Servers

Storage

Network

Cloud Native Platform (Platform-as-a-Service)

Choose your PaaS / Container

Cloud-Native App Dev

Self-service agile

infrastructure

Elasticity & Scalability

OS & Containers

Scalability

Routing

Logging / Monitoring

Cloud Native Platform (IaaS + PaaS)

Choose your IaaS

Choose your PaaS / Container

Private or Hybrid Cloud

Cloud-Native App Dev

Reduced costs of Infra

Self-service agile

infrastructure

Self-hosted & Controlled Env

Elasticity & Scalability

Servers

Storage

Network

OS & Containers

Scalability

Routing

Logging / Monitoring

Kubernetes (K8S)

http://kubernetes.io/docs/getting-started-guides/#cloud

Cloud Foundry

http://www.slideshare.net/cdavisafc/cloud-foundry-technical-overview

#7 Containers are a lower level technology.

Only the infrastructure provider should care, but not the application developer!

Apache Mesos – a “Cloud Operating System”

http://www.slideshare.net/Docker/building-web-scale-apps-with-docker-and-mesos/30

• Enterprises have to manage different clusters with different technologies

• Based on containers (but no specific technology, e.g. you can use Docker and rkt)

“The basic resource for CaaS is a container, rather than a virtual machine (VM) or a bare metal hardware host system.”

Container-as-a-Service (CaaS)

http://searchcloudcomputing.techtarget.com/definition/Containers-as-a-Service-CaaS

Serverless Computing

• Bring a function (not an entire application) up for one single request.

• No cluster or server instance management.

• Small microservice-style functions running for a few (milli)seconds or at latest a few minutes.

• 100% utilization (!!!)

“Sponsored by Red Hat / JBoss"

#8 Be cloud platform agnostic.

The (container) world changes fast!

DevOps Elements – Culture and Technology!

Process

Automation

Culture

Continuous Integration/Continuous Development

APIsMicroservicesFrequent releases

Collaboration

#9 Automation (CI / CD / DevOps) and the related

cultural change are key for success. Especially for Cloud-Native Microservices!

Agenda

Develop Deploy

Commit

Config

The Need for Various Technologies

Cloud, Container, PaaS, iPaaS, iSaaS,

Coding, Visual Dev, …

Show me some different cloud native examples!

• Open Source

• Runs on OpenShift PaaS (which is based on Kubernetes)

• Also available as iPaaS

• JBoss Fuse (based on Apache Camel and JBoss A-MQ)

• For Integration Specialists

• Focus on writing source code

JBoss Middleware Services

https://www.openshift.com/container-platform/middleware-services.html

JBoss Example: Apache Camel Integration Service

Java DSL

new RouteBuilder() { public void configure() {

from(”jms:myQueue").loadBalance() .circuitBreaker(2, 1000L, MyCustomException.class)

.to("mock:result"); }};

XML DSL

<circuitBreaker threshold="2" halfOpenAfter="1000"> <exception>MyCustomException</exception>

</circuitBreaker><to uri="mock:result"/>

</loadBalance> </route>

http://wso2.com/cloud/paas/

• Open Source

• Runs on different cloud platforms

• Also available as iPaaS

• WSO2 Products (like ESB or CEP) containerized for cloud offerings

• WSO2 Microservices Framework for Java

• For Integration Specialists

• Focus on writing source code and configuration

• Runs on various cloud platforms (TIBCO BusinessWorks Container Edition)

• Native integration with 3rd party frameworks like Consul or Hystrix

• Also available as iPaaS (TIBCO Cloud Integration)

• Focus on visual coding and productivity

• Powerful IDE (Visual Coding) + Web user interface

• For Integration Specialists and Citizen Integrators

#10 A cloud native architecture

leverages various programming languages, open source frameworks and middleware!

Agenda

Develop Deploy

Commit

Config

Demo Setup

Live Demo

Cloud-Native Middleware Development with

• Pivotal Cloud Foundry• Spring Cloud Config• Docker• Kubernetes• Consul• Hystrix• TIBCO BusinessWorks Container Edition • TIBCO Mashery• Papertrail

#1 - On premise will not die. Not everything will or should go to the cloud!

#2 - Tools (visual coding) works, even for very complex scenarios. Forget the early 2000 SOA days!

#3 - Microservices are not free lunch. They do not fit into every scenario!

#4 - Design Microservices with open APIs in mind!

#5 - Cloud-Native means much more than a “cloud-washed” application deployed to a cloud provider!

#6 - Microservices and Containers are often used together, but also work very well without each other!

#7 - Containers are a lower level technology. Only the infrastructure provider should care, but not the application developer!

#8 - Be cloud platform agnostic. The world changes fast!

#9 - Automation (CI / CD / DevOps) and the related cultural change is key for success. Especially for Cloud-Native Microservices!

#10 - A cloud native architecture leverages various programming languages, open source frameworks and middleware!

10 Lessons Learned

• A cloud-native architecture enables flexible and agile development• Only vendor- and platform-agnostic architectures are future-safe • Various programming languages, open source frameworks and middleware

complement each other well in a Microservices world

Key Takeaways

Questions? Please contact me!

Kai WähnerTechnology Evangelist at TIBCO

kontakt@kai-waehner.de@KaiWaehnerwww.kai-waehner.deLinkedIn

Target Audience Level Extended Abstract - sigs.de · New Design Patterns Emerging ... © Copyright...

Documents