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