1. Building Cloud Native Software Navigating the waters of a cloudy infrastructure Paul Fremantle CTO and Co-Founder, WSO2 VP, Apache Synapse ASF Member @pzfreo http://pzf.fremantle.org

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

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

4. One view of Cloud Applications today VM App VM App

5. What’s wrong with this picture?

6. 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

7. © WSO2 2010 Enterprise IT in 2010 7

8. © WSO2 2010 Enterprise IT in 2015+ 8

9. So how do you get into the water? http://www.flickr.com/photos/csessums/

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

11. Why do people choose Cloud? Usually provisioning time is much more important than elasticity Some companies take 3-6 months to provision an application

12. Self-Service Provision your company / dept Provision your application Provision integration Provision users Provision a portal Provision storage Provision queues Etc

13. 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

14. So far (Elastic) Self-Service Multi-tenant

15. 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”

16. So….. You have an elastic, self-service, multi- tenant runtime What next?

17. Money (aka Metering and Billing) http://www.flickr.com/photos/amagill/

18. 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

19. Monolithic is back!!!! And, no, that isn’t good!

20. Wiring! You’ve heard plenty about wiring from Tuscany Wiring is really important in any large application Dynamic wiring for the Cloud

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

22. 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

23. 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

24. “Cloud Native” Self-service Distributed and Elastic Multi-tenant Metered and Billed Dynamically wired Versionable, Incrementally deployable and testable

25. 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

26. Carbon

27. Home page

28. 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

29. 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

30. Next step Security management –Using Java and OSGi security managers to isolate tenants –Come hear my talk on making Tomcat Multi- tenant tomorrow!

31. 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

32. 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

33. 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

34. 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

35. Dynamic Wiring A complete Governance Registry per tenant Supports WS-Discovery seamlessly –i.e. supports both long-lived metadata and presence Not finished yet

36. Quick demo

37. 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

38. “Cloud Native” Self-service Distributed and Elastic Multi-tenant Metered and Billed Dynamically wired Versionable, Incrementally deployable and testable

39. 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