Building Cloud Native Software

Navigating the waters of a cloudy infrastructure

Paul FremantleCTO and Co-Founder, WSO2

VP, Apache SynapseASF Member

@pzfreo http://pzf.fremantle.org

http://www.flickr.com/photos/ladymaggic/

http://www.flickr.com/photos/jurvetson/

One view of Cloud Applications today

VM

App

VM VM

App

What’s wrong with this picture?

Cloud computing in one page

The Big Picture• Infrastructure as a Service

– Servers, storage & networking– For infrastructure specialists

• Platform as a Service– Middleware and Core Services– For developers, integrators, architects

• Software as a Service– Applications– For end-users

© WSO2 2010

Enterprise IT in 2010

7

© WSO2 2010

Enterprise IT in 2015+

8

So how do you get into the water?

http://www.flickr.com/photos/csessums/

Elasticity

http://www.flickr.com/photos/clanlife/

Why do people choose Cloud?

• Usually provisioning time is much more important than elasticity

• Some companies take 3-6 months to provision an application

Self-Service

• Provision your company / dept • Provision your application• Provision integration• Provision users• Provision a portal• Provision storage• Provision queues• Etc

How do you effectively provision systems?

• They should be multi-tenant

• Why?– Per instance cost is very small

• Unless the instance is used– Better shared resources– Infinitely simpler management

So far

• (Elastic)• Self-Service• Multi-tenant

Elasticity

• Yes you can (sometimes) rely on the IaaS– E.g. Amazon

• But ultimately we will want to provide more intelligent elasticity– E.g. Coach/Business/Private Jet– Or based on market pricing– Or……

• Elasticity requires the underlying code to be “distributed”

So…..

• You have an elastic, self-service, multi-tenant runtime

• What next?

Money (aka Metering and Billing)

http://www.flickr.com/photos/amagill/

Metering

• For many businesses, internal billing hasn’t been successful– That will have to change!

• Metering is very important– And overall system, service and tenant

monitoring

Monolithic is back!!!!

• And, no, that isn’t good!

Wiring!

• You’ve heard plenty about wiring from Tuscany

• Wiring is really important in any large application

• Dynamic wiring for the Cloud

Dynamic Discovery

http://www.flickr.com/photos/unc-cfc-usfk/

Discovering other services?

• Registry – for long term metadata• WS-Discovery – for “who is where now?”

– “aka Discovery Proxy”• Probe (types, scope)• ProbeMatch <- UUID• Resolve(UUID)• ResolveMatch <- Transport Address

Incremental deployment and test

• Co-deploy version 5.5.4 next to 5.5.3– Implies versioned

• Test in place• Partially switch 5% of live traffic over• Monitor CPU and Memory usage

– And billing!• Switch the rest over• Revert

“Cloud Native”

• Self-service• Distributed and Elastic • Multi-tenant• Metered and Billed• Dynamically wired • Versionable, Incrementally deployable and

testable

A case study – “Stratos”

• A full middleware platform• Based on OSGi• Self-service• Multi-tenant, Elastic, Metered and Billed• Partial versioning, dynamic discovery• Distributed but not yet endlessly scalable• Available under the Apache License

– Heavily based on Apache projects• Tomcat, Axis2, Synapse, ODE, Shindig, Abdera, Commons, etc• Looking at Cassandra, QPid, etc

Carbon

Home page

First steps

• Identity (and hence Multi-Tenancy)– Every domain/tenant has its own single-sign on

and identity manager– Based on LDAP – which is inherently multi-

tenant– Supporting SAML2, OpenId, OAuth, XACML,

Infocard, WS-Trust

Next step – Registry/Repository

• Added a tenant id column to every database in our registry/repository schema

• Used to store:– Permissions– Metadata / Configuration– Code– The works

Next step

• Security management– Using Java and OSGi security managers to isolate

tenants– Come hear my talk on making Tomcat Multi-

tenant tomorrow!

Billing and Metering

• A generic multi-tenanted metering and billing module

• Written as OSGi• Uses Drools to implement service levels

– E.g. 10 users, 100Mb transfer/month, 15 deployed services for free level of subscription

• Can be used to meter real business events– How many sales transactions / month

Elasticity

• Elastic Load Balancer– Apache Synapse

• Always done load balancing• Now has full transparent HTTP support• Has “Autoscale” mediators

– Based on Azeez’s Master’s thesis• Priority Execution support and throttling (Business

Class)– Underlying Cloud API

• We have based on Amazon/Eucalyptus/Ubuntu API• Adding support for vmWare underneath

Distributed

• Our distribution model is based on Apache Tribes

• Adjusted Tribes to support WKA model• In a large cloud (e.g. Amazon) you cannot

rely on subnet communications between nodes

• Nominate two Well Known Addresses– Tribes contacts the WKA and uses that the

bootstrap the fabric

Versioning and incremental behaviour

• OSGi• We have a simple deployment model (CAR)

– Each CAR consists of stuff• Webapps, ESB flows, BPEL, Registry entries, etc• Simple XML syntax is used to wrap everything as OSGi• Each Bundle has a version

Dynamic Wiring

• A complete Governance Registry per tenant• Supports WS-Discovery seamlessly

– i.e. supports both long-lived metadata and presence

• Not finished yet

Quick demo

Still to do

• Lots– Multi-tenant services

• Log, Cache, Data, …– Better support for incremental deployment and

test– Better support for coach/business/private jet– Extreme scale

“Cloud Native”

• Self-service• Distributed and Elastic • Multi-tenant• Metered and Billed• Dynamically wired • Versionable, Incrementally deployable and

testable

Summary

• Cloud Native attributes distinguish code that just floats on top of the cloud from applications that live in the cloud

• This actually applies to Infrastructure (IaaS), Platform (PaaS) and Applications (SaaS)

• Stratos is an example of a making an OSGi system Cloud Native

• Read my blog entry on this:– http://bit.ly/CloudNative