herzlich willkommen - digicomp...container app container app container app container app container...

2

Herzlich willkommen

DevDay Zürich 2016

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

Building Cloud Native Applications

Andreas Postl Principal Sales Consultant MiddlewarePaaS Ambassador

June 22th 2016


Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.


Software Is Overtaking the World

Time-to-market is key to success

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

Better Segment SoftwareDifferent software has different needs

Find the Next Business

Run the Current Business

Run the Back Office

New IT

Old IT


Different Types of Software Requires Different PracticesA payroll system should be treated very different from a customer-facing .com

Innovation Software - Find the Next Business

Differentiation Software - Run Current Business

Core Software - Keep the Lights On

Release Hourly

Fail Early

Agile

Business-centric

Top Line Growth

Bespoke Software

Product-based

Release Quarterly

Fail Late

Waterfall

IT-centric

Bottom Line Savings

Packaged Software

Project-based



Change How Your Customers Procure SoftwareFocus is on bringing new features to market very quickly

Co

mp

etit

ive

Dif

fere

nti

atio

n

Buy as SaaS Build

Innovation Software

Differentiation Software

Develo

per-led

Pro

curem

ent

Core Software


Innovation and Differentiation Systems are Different!Stop treating them like systems of record

IT-centric

Focus on Saving Money

Release Quarterly

Waterfall

Traditional Infrastructure

Dev/Ops Separated

Project-based

One Large, Monolithic ApplicationSoftware Manually Installed

Manual Scaling

Heavy Weight Governance

Tight Coupling

Stateful Middle Tiers



Introducing Cloud Native ArchitectureUsed to build Cloud Native applications

10


Microservices• Minimal Function• Service Discovery• API-first

3 • Polyglot• Choreography• Loose Coupling

DevOps• Automated Provisioning• Automated Setup• Continuous Integration

1 • Continuous Delivery• Automated Testing• Agile• Culture Change

* as a Service• Consume Infrastructure and

Software as a Service• Fault Tolerant by Definition

2 • Auto-scaling• Infinite Elasticity

What is Cloud Native?A new style of architecture

Distributed Computing• Multi-master• Many Data Centers• Many Fault Domains

4 • Many Regions• Global Server Load Balancing• Replication

Co

mp

eten

cy



Prerequisite #1 - DevOpsRequires changes throughout your entire organization

Culture Technology

Respect

Discuss

Avoid Blaming

“Done” Means Released

Infra as Code

Shared Version Control

One Step Build/Deploy

Don’t Fix Anything

• Dev respect for ops• Ops respect for dev

• Ops should be in dev discussions• Dev should be in ops discussions• Shared runbooks

• No fingerpointing!• Everyone should have some

culpability

• Dev’s responsibility shouldn’t ever end – production support required

• “Throwing it over the wall” is dead

• Don’t build envs by hand• Scripts checked in and

managed as src

• Single system• Ship trunk• Enable features through flags

• One button build/deploy• If verification fails, stop and

alert or take action

• If something breaks, re-deploy. Don’t fix

• Fix environment setup scripts


Start Using ContainersHelpful to microservices but not a requirement

Hardware

Hypervisor

VM 1

OS

App

VM 2

OS

App

Hardware Virtualization

Hardware

Operating System

Hypervisor

VM 1

OS

App

VM 2

OS

App

Para-virtualization

Hardware

Operating System

Container 1

App

Container 2

App

Containers

• #1 value – app packaging

• Microservices doesn't rely on containers but they do help:– Higher density

– Easy to start/stop

– Portability

• Containers are lightweight, just like microservices themselves

• Containers can run in VMs too


Containers Are Now the StandardFour main use cases

Hardware

Operating System

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Hardware

Operating System

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Hardware

Operating System

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Hardware

Operating System

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Hardware

Operating System

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Hardware

Operating System

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Hardware

Operating System

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Hardware

Operating System

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Container

App

Application Packaging

Continuous Integration DIY PaaS

Infrastructure Consolidation

Neatly package applications and supporting environment in immutable, portable containers

All changes to an app are contained in one immutable container image. Container is tested and deployed as one atomic unit

Get infrastructure utilization up to 100% (vs 5-10% with VMs) due to over-subscription of resources and near bare metal performance.

Build a simple PaaS by wiring up containers to a load balancer. New code, patches, etc pushed as new immutable containers.


Artifacts Are Now Immutable Containers – Not EARs, WARsContainers can have anything in them and are highly portable

Hardware

Operating System

Hypervisor

VM 1 VM 2

Legacy

Hardware

Operating System

Container 1 Container 2

Cloud Native

• No more installing a JVM, app server, and then deploying the artifacts to them

• Build the container once, deploy it anywhere. Can include complex environment variables, scripts, etc

• Containers should be free of state and configuration

• Containers should not assume they are able to write to a persistent local file system

OS

App Server

EAR/WAR

OS

App Server

EAR/WAR The Artifact You Deploy


Strict Requirement: One Instance Per Container

• Run ONE instance (unique host/port combination) per container

• Running multiple instances of the same application or different applications will make scheduling very difficult

• Expose one port per containerPhysical Host

Operating System

Container

App

Container

App

Just One Per Container


How Do You Deploy Containers to Physical Hosts?The emerging space of container orchestration

What Do Container Orchestration Solutions Do?• Map containers back to physical

hosts, taking into account user-defined placement rules, the utilization of each host, and the needs of each container. Can be very complex

• Set up overlay networking, firewalls, ensure network QoS, etc

• Auto-scaling

• Local and external load balancers

• Service registry / discovery

HostHost

HostHost

HostHost

HostHost

HostHost

Container

• Inventory Microservice

• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container

App

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container


• AcmeCo• v1.2

Container

App

Many Containers

HostHost

HostHost

HostHost

HostHost

HostHost

Many Hosts

Docker Swarm

Emerging space. Solutions are very early and lack any real notion of an application. Still very much infrastructure-focused


Best to Declaratively Build Containers Using DockerfilesFROM centos:centos6

# Enable Extra Packages for Enterprise Linux (EPEL) for CentOS

RUN yum install -y epel-release

# Install Node.js and npm

RUN yum install -y nodejs npm

# Install app dependencies

COPY package.json /src/package.json

RUN cd /src; npm install

# Bundle app source

COPY . /src

EXPOSE 8080

CMD ["node", "/src/index.js"]


Everyone Should Be Able to Build Anything At Any Time

• Manual one button build/deploy

• Scheduled builds - every day, every week, etc

• Builds triggered by code checkins

• If post-build validation fails, report it

Set it and forget it


Ongoing Operations is Now a Shared ResponsibilityIn perpetuity. No more “throwing it over the wall”

New GoalAdd new features and keep the system stable, fast and available

DevelopersPaid to add new features

that may break things

OperationsPaid to keep system

available, stable, and fast


Stop Manually Fixing ProblemsIn no case should an administrator fix issues by hand. Should be 100% automated

Auto-scaling will automatically launch a new container on new hardware as load dictates

Hardware FailureExample: motherboard failed

Auto-scaling will automatically launch new containers as load dictates

Network FailureExample: switch failed

Health checking should fail and the container will be culled. Auto-scaling will automatically launch a new container as load dictates

System Software FailureExample: kernel panic

Application Software FailureExample: bad file permissions

Fix the source (your application, your container, your Dockerfile, etc) and re-deploy your entire application


Prerequisite #2 - * as a ServiceRequires fundamental shift in how applications are built


Your CodeHighly innovative, differentiated, etc

Configuration

Caching

Load Balancing Eventing

Logging

Monitoring

Database

NoSQLState

Messaging

3rd Party Cloud – On or Off Premise

Building Block

Building Block

Building Block

Building Block

Building Block

Building Block

Building Block

Building Block

Building Block

Building Block

Building Block

Building Block

Where you’re not differentiating, consume building blocks from 3rd party cloud vendor


Everything is Now SoftwareProvision a new server just like you would provision a new object in Java

Person p = new Person();

$ docker run -v /host:/container example/myapp

curl -X POST "name=MyFirstApp" "runtime=java” "archiveURL=/binaries/myapp.zip"

$ puppet module install puppetlabs-java


Today, Everything is 100% Code.

Automation at scale is standard


Remove All Hard-coded IPs, Host Names, etc

24

Use service discovery, DNS, etc instead. Everything should be dynamic


Make Your Middle Tier Stateless

25

Push all state and configuration down to highly available cloud services

Application Server

File System

Application Server

File System

Application Server

File System

Application Server

File System

Application Instance

File System

Load BalancerSticky to an Individual Instance

Application InstanceApplication

InstanceApplication InstanceApplication

Instance

Load BalancerNOT Sticky to an Individual Instance

StateService

ConfigurationService

Application Instance

Key to Cloud Native

Session StateShopping cart contents, page view data, personalization, etc

Application ConfigurationPort numbers, file system paths, host names, etc

Legacy Cloud Native


Remember That Latency is EverywhereAsynchronously make calls to all remote systems

High latency within a single cloud. Can no longer assume 2ms between

application and data tiers

Application is now comprised of many different microservices, each

with its own datastore/database

Application is now deployed to multiple data centers, in multiple

availability zones, in multiple regions

26



Empower Developers to Make Procurement Decisions

Core Software Differentiation Software Innovation Software


• #1 focus of cloud native: time to market. Long-term maintenance should not be a big consideration

• Let developers who are innovating pick the absolute best technology for their own use

• Each small team supports their own microservice in perpetuity. No need to have large maintenance teams

• Standardization is best for system of record-style applications


Emit Logs as Event Streams

28

Can’t do anything with log files sitting on a container’s local storage volume

Log Entry Log EntryLog Entry

Log Entry

Log Entry

Log Entry

Log EntryLog Entry

Log Entry

Log Entry

Log Entry

Log Entry

Log EntryLog Entry

Log Entry Log Entry

Container

Instance of Application


Log Entry

Log Entry

Log Entry

Log EntryLog Entry

Log Entry

Log Entry

Log Entry

Log Entry

Log EntryLog Entry

Log Entry Log Entry

Container



Log Entry

Log Entry

Log Entry

Log EntryLog Entry

Log Entry

Log Entry

Log Entry

Log Entry

Log EntryLog Entry

Log Entry Log Entry

Container


Capture, Aggregate, Search, Troubleshoot, etc


Prerequisite #3 – Microservices

• Single monolithic application -> small, independently deployable microservices

• Each microservice:– Has its own team that designs, builds,

deploys and maintains it

– Exposes an API, which can be consumed elsewhere

– Has its own datastore/database

• Microservices are loosely coupled, with most communication over REST and async messaging

29

Break up your application into many small pieces to get features to market quickly

User Interface

Application

Datastore

Infrastructure

Status Quo

One Application

Microservices

Many Small Microservices

API

Application

Datastore

Infrastructure

InventoryMicroservice

API

Application

Datastore

Infrastructure

PaymentMicroservice

API

Application

Datastore

Infrastructure

ProfileMicroservice

API

Application

Datastore

Infrastructure

Product CatalogMicroservice


Monolithic ApplicationsSingle, Monolithic App

Must Deploy Entire App

One Database for Entire App

Organized Around Technology Layers

State In Each Runtime Instance

One Technology Stack for Entire App

In-process Calls Locally, SOAP Externally

MicroservicesMany, Smaller Minimal Function Microservices

Can Deploy Each Microservice Independently

Each Microservice Has Its Own Datastore

Organized Around Business Capabilities

State is Externalized

Choice of Technology for Each Microservice

REST Calls Over HTTP, Messaging, or Binary

What Are Microservices?Minimal function services that are deployed separately but can interact together to achieve a broader use-case



Three Key Rules to Microservices

Don’t share a datasource across microservices

Can release each microservice independently

Can build a microservice independently


Horizontally Tiered Enterprises == Horizontally Tiered AppsConway’s Law: Software reflects the structure of the organization that produced it

User Interface

Application

Datastore

Infrastructure

Resulting SoftwareTypical Enterprise Organization Structure

Head of IT

Head of Operations

Head of DBAsHead of

InfrastructureHead of App

DevHead of UI

Head of Development

An Enormous Monolith


Re-structure Your Organization – Put Conway’s Law to Work

33

Build small product-focused teams – strict one team to one microservice mapping

Resulting SoftwareMicroservices Organization Structure

Many Small Microservices

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

Product Lead

Project Manager

Sys Admin DBAJavaScript Developer

Developer

Developer

Sys Admin

Storage Admin

Graphic ArtistNoSQL Admin

Product Lead

Project Manager


Developer

Developer

Sys Admin

Storage Admin


Product Lead

Project Manager


Developer

Developer

Sys Admin

Storage Admin


Product Lead

Project Manager


Developer

Developer

Sys Admin

Storage Admin



Even Simple Changes Are Hard to Implement With Monoliths

34

Organizational boundaries introduce the need to extensively coordinate

User Interface

Application

Datastore

Infrastructure

New requirement: Add a birthdate property to the customer’s profile. How does this get implemented?

Application developer tickets DBAs to have them add that property as a column in the database

1.

Application developer tickets UI team to have them add that property to the profile screens

3.

Application developer adds the new property to the application-level code

2. Different TeamsDifferent TimelinesDifferent PrioritiesDifferent Ticketing


Much Faster Turnaround With Microservices

The profile microservice team – three people total, all sitting together

Turn around changes in hours vs. months

Hey Jim, can you add that column to the

database before lunch?


Low latency, high bandwidth communication


Do One Thing and Do It Well

Focus on Business Capabilities

Avoid Inter-dependencies

Start Managing Small, Vertical TeamsCan have hundreds of microservices for a larger application

Large

Medium

Small

11-15 PeopleExample: Order Microservice

4-10 PeopleExample: Inventory Microservice

1-3 PeopleExample: Order Status Microservice


Owners Support in Production

Everythingis Owned by a Small Team

Owners Implement

Owners Architect

OwnersCare

Owners Can Fix Things

Ownership is Key to the Success ofCloud NativeIn traditional enterprises, any one individual has very low ownership of anything. It’s classic tragedy of the commons


Teams Do Not Have 100% FreedomStandardize where it makes sense. Be pragmatic

Custom Code

Communication Protocol

Data Format

Infrastructure

Datastore

Sou

rce

Co

ntr

ol

Co

nfi

gura

tio

n M

anag

emen

t

Dev

elo

pm

ent

Too

ling

Alerting

Monitoring

Standardize on One

Offer a Menu of 2-3 Options

Team Has Complete Choice

Programming Language

Messaging


Developers Want Choice in Programming Language

• Different languages for different specialized microservices

• Remember – the goal of cloud native is time to market. It is NOT about long-term maintainability

• If maintenance becomes an issue, rewrite the microservice over a weekend

Use the language that works best

API

Application

Datastore

Infrastructure

InventoryMicroservice

API

Application

Datastore

Infrastructure

ChatMicroservice

API

Application

Datastore

Infrastructure

Product RecommendationMicroservice


Run Many Versions of the Same Microservice Concurrently

Monolithic Application

v1.1

Microservice AMicroservice A


Microservice AMicroservice Bv1.1



Microservice A



Microservice AMicroservice Bv1.2



Microservice A

Run only one version of the same application in the same environment

Run many versions of each microservice in the same environment

Microservice Av1.2

Microservice Av1.1


Use Blue/Green Deployments When One Version Can Be LiveBlue is current. Deploy new code to green. Switch load balancer from blue to green

ApplicationLive in production - v1.1

ApplicationIn production but no

traffic from load balancer

v1.2

“Blue” Environment “Green” Environment

Identical EnvironmentsEach capable of handling 100% of production traffic

“Blue” can be shut down after code deployment is successful.

New CodeCurrent Code


4

Scenario: eCommerce user returns a widget through web-facing .com

Example of Orchestration

Centralized Workflow

Self Service Help

Initiate Return

Workflow

Increment Inventory

Done

Inventory

Record Refund

Done

Customer Profile

Done

Payment

Refund Money

Brittle | Centralized | Tightly Coupled


Scenario: Inventory microservice

Example of Choreography

Inventory Microservice

All asynchronous

Event Bus

New Inventory

Events This Microservice Cares About Events This Microservice Emits

Product Returned

Product Sold

Product Recalled

Inventory Incremented

Inventory Created

Inventory Decremented

Inventory Deleted

For Anyone Who Cares...


Avoid Synchronous Calls for Read-only Data By Copying

Product PricingInventory

Promotions


Promotions


Promotions

Product Catalog• Synchronous in-memory calls• Data is 100% consistent• No data is duplicated

Request for Category Page

Product Catalog

Product

Pricing

Inventory

Promotions

• Synchronous calls to product catalog microservice• Product, pricing, inventory and promotions

microservices are systems of record; they publish asynchronously to Product Catalog microservice when updated

• Product Catalog microservice is not always consistent• Data is duplicated – two or more microservices may

contain the same data

TraditionalMonoliths

New Microservices


Prerequisite #4 – Distributed ComputingRun your applications across multiple data centers, fault domains, regions, etc


Cloud

Region

Fault Domain

Data Center

Host

Container

Microservice

Microservice

Microservice

Microservice

Hundreds of milliseconds

of latency

Everything is now distributedEven within the same data center


Everything Is Now Distributed. Get Used To It

Applications Infrastructure Teams

Applications are now broken up into small microservices, with separate frontends and backends

Different data centers, fault domains, regions, etc. Even within the same data center, latency may be unacceptably high

Many small teams, each responsible for their own microservice. Each team is often geographically distributed


Microservices Forces Move To Distributed ComputingIntroduces enormous complexity – monoliths don’t suffer from this

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

Microservice A Microservice B Microservice C Microservice D

• Distributed computing is a natural consequence of microservices because each microservice has its own datastore

• Sharing datastores across microservices introduces coupling – very bad!

• There will always be latency between microservices

• Latency = eventual consistency

• All data exchange between microservices must be through API layer or messaging – no accessing datastores cross-microservices

• Must implement high-speed messaging for synchronous calls between microservices. REST + HTTP probably isn’t fast enough

• May end up duplicating data across datastores –e.g. a customer’s profile


Eliminate SingletonsSingletons are an evil necessity. They do not have to be “fixed”

DynamicAvailable at well known service

name. Instances are dynamically elected at runtime. If instance

goes down, another will take over

FixedAvailable at IP/ports. Instances are long-lived, though IP/ports change. If instance goes down,

people will know

herzlich willkommen - digicomp...container app container app container app container app container...

Documents