Your SlideShare is downloading. ×
Building Cloud Native Software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Building Cloud Native Software

5,936
views

Published on

To really take advantage of cloud, software must be optimized to run in the cloud. This presentation explores what it means to be "Cloud Native" and looks at a real open source project that has built …

To really take advantage of cloud, software must be optimized to run in the cloud. This presentation explores what it means to be "Cloud Native" and looks at a real open source project that has built a complete Cloud Native platform. Cloud is not just a better way to run existing software, there are core enhancements that need to be made to software to enable it to run really effectively in a cloud environment. Often the first thought is about massive scalability, but actually there are other key enablers: multi-tenancy, metering, dynamic distribution, self-service and incremental deployment and testability. This presentation explores these enablers and looks at how an Open Source project (Carbon) built on Apache technology was re-built to be cloud native. The presentation will cover not just the concepts but dive into the practical issues in making a cloud native system and also explore which Apache technologies can help along the way.

Published in: Technology, Business

2 Comments
5 Likes
Statistics
Notes
  • Thank you! I always worry that my slides are too optimized to be talked to and not optimized to be read. So I'm very glad you got something out of it.

    Paul
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Outstanding. And comprehensible. Apache and us standards geeks are lucky to have you. Cheers Jamie
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
5,936
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
140
Comments
2
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • 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)
  • Transcript

    • 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 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