Downloaded 172 times
Uploaded byPaul Fremantle
Building Cloud Native Software
The document discusses the concept of cloud-native software, highlighting its essential attributes such as self-service, elasticity, multi-tenancy, and metering. It presents the Stratos middleware platform as an example of a cloud-native architecture based on OSGi that incorporates dynamic discovery and incremental deployment. Additionally, it emphasizes the importance of metering and automatic load balancing in cloud environments.
More Related Content
Similar to Building Cloud Native Software
Building Cloud Native Software
- 1. Building Cloud NativeSoftware 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.
- 3.
- 4. One view ofCloud Applications today VM App VM VM App
- 5. What’s wrong withthis picture?
- 6. Cloud computing inone 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 EnterpriseIT in 2010 7
- 8. © WSO2 2010 EnterpriseIT in 2015+ 8
- 9. So how doyou get into the water? http://www.flickr.com/photos/csessums/
- 10.
- 11. Why do peoplechoose Cloud? • Usually provisioning time is much more important than elasticity • Some companies take 3-6 months to provision an application
- 12. Self-Service • Provision yourcompany / dept • Provision your application • Provision integration • Provision users • Provision a portal • Provision storage • Provision queues • Etc
- 13. How do youeffectively 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 youcan (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 havean elastic, self-service, multi- tenant runtime • What next?
- 17. Money (aka Meteringand Billing) http://www.flickr.com/photos/amagill/
- 18. Metering • For manybusinesses, 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 heardplenty about wiring from Tuscany • Wiring is really important in any large application • Dynamic wiring for the Cloud
- 21.
- 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 andtest • 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.
- 27.
- 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 • Securitymanagement – 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 LoadBalancer – 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 distributionmodel 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 incrementalbehaviour • 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 • Acomplete Governance Registry per tenant • Supports WS-Discovery seamlessly – i.e. supports both long-lived metadata and presence • Not finished yet
- 36.
- 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 Nativeattributes 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
Editor's Notes
- #8 Data center provisioned for peak capacity Utilization is 5-10% or up to 50% with virt Tight coupling between applications and hardware allocation Bought app silos (e.g. SAP) Provisioned for peak capacity Build apps using enterprise middleware Provisioned for peak capacity Hardware & app provisioning takes months
- #9 Has a private IaaS Overflows to one or more public IaaS Uses a bunch of public SaaS Has a bunch of private SaaS, both build & buy Internally built SaaS is HUGE Because that is the competitive differentiator for every business Private SaaS running on PaaS using private hybrid IaaS PaaS also could be private or public Has unified identity, security, audit, etc. across all of these Has federated identity management across public / private infra (SaaS/IaaS)