Apachecon 2014 Keynote: The Apache Way in the Cloud with Cloud Foundry
•Download as PPTX, PDF•
5 likes•3,155 views
Apachecon 2014 Keynote: The Apache Way in the Cloud with Cloud Foundry
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Apachecon 2014 Keynote: The Apache Way in the Cloud with Cloud Foundry
Similar to Apachecon 2014 Keynote: The Apache Way in the Cloud with Cloud Foundry (20)
More from James Watters
More from James Watters (11)
Recently uploaded
Recently uploaded (20)
Apachecon 2014 Keynote: The Apache Way in the Cloud with Cloud Foundry
- 1. A NEW PLATFORM FOR A NEW ERA
- 2. 2© Copyright 2014 Pivotal. All rights reserved. 2© Copyright 2014 Pivotal. All rights reserved. The Apache Way in the Cloud Apachecon 2014 James Watters @wattersjames
- 3. 3© Copyright 2014 Pivotal. All rights reserved. Agenda Our credentials: open source at Pivotal The four Cs: code, community, collaboration, & commerce Collaboration models in the era of strategic OSS The purpose motive and direction of the Cloud Foundry project
- 4. 4© Copyright 2014 Pivotal. All rights reserved. Personal History: Lessons Learned in OSS Timing 10 years too late, reactive Business Motivation Protect/revive an existing business in decline License Corporate created Self Interest ―Open Solaris Exists for our interests―—SVP Collaboration 980 Sun Engineers Outcome Acquired by Oracle, shuttered
- 5. 5© Copyright 2014 Pivotal. All rights reserved. Open Source at Pivotal
- 6. 6© Copyright 2014 Pivotal. All rights reserved. CODE
- 7. 7© Copyright 2014 Pivotal. All rights reserved. No Negotiation on this Standard
- 8. 8© Copyright 2014 Pivotal. All rights reserved. COMMUNITY
- 9. 9© Copyright 2014 Pivotal. All rights reserved. Invested In a Cloud Hosted Version Since Day One Pivotal Web Services. Run by the Cloud Foundry Experts.
- 10. 10© Copyright 2014 Pivotal. All rights reserved. COLLABORATION
- 11. 11© Copyright 2014 Pivotal. All rights reserved. Cloud Foundry Open Source Dojo Pair programing with IBM, SAP, Swisscom, Altoros, Cloud Credo: all send developers to San Francisco HQ of Pivotal for intensive 8 week residencies Work directly on the CF OSS engineering team and innovate together with us
- 12. 12© Copyright 2014 Pivotal. All rights reserved. COMMERCE
- 13. 13© Copyright 2014 Pivotal. All rights reserved. IBM Bets $1B On Cloud Foundry
- 14. 14© Copyright 2014 Pivotal. All rights reserved. Industry Transformation In the beginning… Open vs Proprietary Open Source is the new Open Standard Open Source as a strategic asset Purpose Motive as competitive differentiator
- 15. 15© Copyright 2014 Pivotal. All rights reserved. NO ONE WANTS TO BE LOCKED IN
- 16. 16© Copyright 2014 Pivotal. All rights reserved. OPEN SOURCE IS THE NEW OPEN STANDARD
- 17. 17© Copyright 2014 Pivotal. All rights reserved. STRATEGIC OPEN SOURCE
- 18. 18© Copyright 2014 Pivotal. All rights reserved. Black Duck Survey Results Show The Change • 2014: 80% of respondents say code quality vs. proprietary why they choose OSS software – In 2007 80% ranked costs as primary driver • 2014: 80% says access to source code a primary driver – Up from 57% in 2007 • ―Attract and retain talent‖ http://www.slideshare.net/blackducksoftware/2014-future-of-open-source-survey-results
- 19. 19© Copyright 2014 Pivotal. All rights reserved. From Cost Savings to Collaboration ―And while cost is still important to companies, the way cost savings are realized differs from 10 years ago. Before it was a matter of downloading free stuff. This year the primary reason for participating in open-source communities is to help reduce costs. Not installing the software, but actually getting involved in its creation and maintenance.‖ --Matt Asay, Read Write Web http://readwrite.com/author/matt-asay#awesm=~oAKXbOiXYvnSJR
- 20. 20© Copyright 2014 Pivotal. All rights reserved. Daniel Pink: Purpose Motive
- 21. 21© Copyright 2014 Pivotal. All rights reserved. Collaboration Models for Strategic OSS Dedicated Foundation Shared Foundation GitHub
- 22. 22© Copyright 2014 Pivotal. All rights reserved. Coming Soon…Cloud Foundry Foundation more to come…
- 23. 23© Copyright 2014 Pivotal. All rights reserved. Purpose Motives for Cloud Foundry Proprietary services should not define the cloud consumption model; treat an IaaS like hardware Both enterprise and startup developers should ―have nice things‖ Give disparate OSS communities a common OSS cloud consumption engine
- 24. 24© Copyright 2014 Pivotal. All rights reserved. Google Cloud and CF Share a Vision Fully managed serving stack Run App files or Dockerfiles OS management, logging and monitoring Declarative deployments, provisioning and health checking Raw infrastructure
- 25. 25© Copyright 2014 Pivotal. All rights reserved. A Cloud Consumption Platform for OSS CF-ERS (Apache Tomcat, Node, Ruby, Docker..) Apache Hadoop Jenkins Service Google Redis Cloud Foundry BOSH Apache Cassan- dra Cloudstack EC2Openstack Multi-Cloud Declarative Service Deployment, Operations Elastic managed runtime service integrated into leading data services; all scaled and managed by CF BOSH What’s Next?
- 26. 26© Copyright 2014 Pivotal. All rights reserved. Faster and Easier than Amazon: Tomcat + ERS Cloud Foundry Runtime Amazon Beanstalk Lightweight containers, seconds to thousands of instances Heavy VM overhead and waste, several minutes to change scale 12 Factor Compliant Bindings Some in-app configuration files Built-in logging Retrieve logs from each VM.. Instant Blue/Green updates DNS changes in Rt 53, hours Any cloud AWS Only
- 27. 27© Copyright 2014 Pivotal. All rights reserved. Cloud Foundry Elastic Runtime in Enterprise • Generational architecture shift happening in enterprise • Cloud Foundry Elastic Runtime viewed as innovation leader for cloud era of applications • Apache Tomcat at the core of enterprise use of ERS • Key moment for OSS in enterprise middleware….
- 28. 28© Copyright 2014 Pivotal. All rights reserved. 28© Copyright 2014 Pivotal. All rights reserved. Instant Apache Hadoop on Google Cloud Demo
- 29. 29© Copyright 2014 Pivotal. All rights reserved. Proof Point: Faster and Easier than AWS https://www.youtube.com/watch?v=LHIEQB0C4Ko
- 30. 30© Copyright 2014 Pivotal. All rights reserved. Cloud Independent Software Delivery Simple, Developer Friendly Commands and API • CF Push [Appfile] • CF Push [Docker] • Or IDE based control, Eclipse, STS, Intellij,etc. Operational Benefits for Every Application • Instant Dynamic Routing • Streaming Logging Agg • ID/team/RBAC/Policy • Application performance management • Auto-scaling, scheduling • Four layers of built-in Availability and health management Built-in and Ecosystem Services • MySQL HA • Redis • Rabbit MQ • HAWQ Analytics • Elastic Pivotal HD • Elastic Search • Mobile Back End • Jenkins • Cassandra Deploy, Operate Update, Scale Platform on Any IaaS
- 31. 31© Copyright 2014 Pivotal. All rights reserved. …This Time Around Timing Rapid push to launch and open source early Business Motivation Create a new open community and build a new company around it License Apache 2, Industry standard Self Interest ―Leap of faith‖ to make CF OSS bloom and find the right business along the way, CF Foundation Collaboration Github, Dojo and Community Pairs… Outcome Looking bright …
- 32. 32© Copyright 2014 Pivotal. All rights reserved. Summary Code, Community, Collaboration, & Commerce are all important considerations for OSS Open source is the leading edge of industry innovation and has usurped open standards The ASF is the right choice in many situations For multi-faceted collaboration around a collection of projects forming a platform, consider a dedicated foundation Common cloud delivery architecture is key opportunity for OSS community to solve vs. proprietary IaaS bound approaches
- 33. 33© Copyright 2014 Pivotal. All rights reserved. 33© Copyright 2014 Pivotal. All rights reserved. Thank You
- 34. A NEW PLATFORM FOR A NEW ERA
Editor's Notes
- Overview of key open source projects at Pivotal.LHS is our apps stack, RHS is our data stack. [Redis & Rabbit really play in both]We’ve been involved with building successful open source projects and communities for many years.Programming languages such as Groovy and AspectJDevelopment frameworks such as Grails and Spring (defacto standard, ~3M devs etc.)Modern messaging & middleware: rabbitmq, redis, apache tomcat, apache http serverCloud Platforms: Cloud FoundryUnderpinning some of the biggest enterprises in the world, both in a traditional enterprise context, and in the new consumer-grade internet companies (Netflix, Twitter, Pinterest, ….) [See Pivotal P.O.V. for some great case studies]On the data side we’re fully committed to Hadoop and increasing our investment and contributions to the Hadoop projects [get the latest phrasing & stats here from Roman]We’re using open source to collaborate with leading academic researchers on MADlib, a big data machine learning library in SQL (Pivotal, Berkeley, Stanford, Florida)And we’re collaborating in open source to create collaborative environments for data explanation and analysis with Open ChorusSome of these projects are hosted at the Apache Software Foundation (tomcat, httpd, hadoop) . Even more of them use the Apache License [CLICK]And we’ve been doing it for a long time – over ten years, despite Pivotal as a company having just celebrated our first birthday.During that time we’ve learned a lot about the contributing factors to successful open source: code, community, collaboration, and commerce!
- Many people starting out in open source think that it’s just about the code. That it is sufficient for example to simply license a body of code under the Apache License and collaborators will flock to help you, and a huge user community appear over the horizon.Some are motivated by freedoms – free as in speech, free in spirit.Some want to lower barriers to adoption – free as in beerOf course having an open source & appropriately licensed code base is fundamentally important and underpins everything else we do with open source. For many organisations involved in open source, the motivations go beyond just setting the code free. They may be hoping to drive adoption – to build a big user community. They may be hoping to share development effort and expertise across a number of collaborators. And increasingly all of this is driven by underlying commercial considerations.
- Open sourcing your code base can certainly lower barriers to adoption, but building a strong and vibrant community around an open source project takes a lot more than just good code.In fact, some good advice is to think of building a user community a bit like building a customer base – except that you don’t get paid! Building a community around an open source project is an investment: you will need good documentation, tutorials, a website. You will need to interact on forums and in user groups, to give talks at conferences such as this one. And then you want to empower your community so that they can start to do some of these things for you too. The close interaction with a user community that well-managed open source projects foster also creates a wonderful feedback loop, helping to quickly create projects that have very strong community (market) fit. This rapid feedback loop can be very difficult for closed source alternatives to compete with. In fact, in many sectors of our industry, being an open source project is no longer a competitive advantage when it comes to community adoption – it’s become a cost of doing business. So we see competition between open source projects for community mindshare. And the benchmark can be very high – a typical VC backed open source project may be using A/B testing and a whole range of analytics to optimize their site and community experience.
- Open source has become an essential foundation for collaboration on a shared code base. This is an area in which the Apache Software Foundation has excelled, providing a neutral place for individuals and organizations to work together towards shared goals. Collaboration can be motivated by a desire to pool expertise – with each party bringing something unique to the picture and creating a whole that no-one organisation or individual could do on their own. Collaboration can also be motivated by a desire to share costs – particularly when many stakeholders gain advantage from something existing, but aren’t necessarily looking for individual competitive advantage through unique implementations. The open source project can become a shared industry asset – developed in collaboration by the industry, for the benefit of multiple industry players. But what prevents this situation from degrading into a Tragedy of the Commons? Why not stand by and let everyone else invest in building out the open source component, and then just come along and use it after the fact? For the answer to this question, we need to look into our fourth C, commerce….
- When I look at all of the open source projects that Pivotal is involved in, the truth is that the vast majority of development effort is undertaken by developers who are paid full-time to work on these projects. And this holds true for many successful open source projects today. Full-time developers are paid a salary, and someone has to pay that salary. So commercial considerations underpin open source. What commercial motivations might there be? We can divide them into three basic camps: Cost reduction: Collaborating in order to share development costs or gain access to expertise you do not have (and would otherwise have to pay for) Commercial enablement: building a business directly on top of, or incorporating, open source components. This is what prevents a Tragedy of the Commons meltdown in many situations – committers have become a valuable commercial commodity and the ability to support open source with deep expertise (“from the source”), and to be able to influence roadmap and features is commercially differentiating in a world where the software itself is available to anyone for free Indirect – for example, a company may get involved with open source to demonstrate its technical credentials and aid in recruitmentThe commercial underpinning of open source is vital to the world of open source as we know it today. This is also something for which we very much have the ASF to thank. The Apache License enables commercial freedom and innovation to flourish alongside open source. It has been instrumental in supporting business models that are necessary to keep the whole machine working smoothly. In fact, this mechanism is so powerful that it has fundamentally transformed the industry.
- In the beginning people used to say that open source couldn’t innovate. That it was only good for commoditizing existing capabilities. That it was a race to the bottom which would destroy industry value. Bullshit.We never believed that. Still don’t. Open source is the best way to innovate because of the short feedback cycles it can create that we talked about previously. In the last few weeks, we’ve seen a subset of the vendors in the Hadoop space, which is itself just a part of the over 140 projects at the Apache Software Foundation, achieve a combined market valuation of $3Bn (Cloudera = $2Bn, HW = $1Bn). That’s a whole lot of industry value being created through open source. What happened?First open source became a means of overcoming proprietary lock-in,. Then it replaced standards at the leading edge of industry adoption, fueled by a rate of innovation that standards could never keep up with. Then it became a strategic asset and an integral part of corporate strategy.
- The fear of vendor lock-in is buried deep in the enterprise psyche. And for good reason – lock-in can be very expensive! So if you’re a vendor, especially in the enterprise application development, integration, middleware and data spaces that Pivotal is involved in, it’s very hard to create commercial adoption and success around a proprietary interface. One of the ways that the industry solves this problem is through standards. For example, the SQL standard, or the Java Enterprise Edition platform specification. Multiple vendors can then compete on implementations of a standard, and perhaps differentiate through qualities of services, installation, configuration, management, and so forth. Innovation at the interface layer is discouraged under such a model. Open source has emerged as an industry accepted alternative to standards as a means of combating vendor lock-in. This allows open source projects – and the vendors behind them – to innovate freely, making deep improvements and new advances that are indeed – of necessity - reflected in the interfaces that an enterprise will ultimately bind to. Much of this transformation has been driven at and by the Apache Software Foundation.Open source has become the new Open standard.
- The rate and pace of change in our industry only continues to rise. We’re undergoing a transition to a whole new set of platforms and a whole new set of concerns. Cloud platforms, big data, real-time analytics, mobile delivery, systems of engagement and more are all bringing in waves of change and innovation. The old model of committee-based collaboration to create a standard specification that can then be implemented by multiple vendors is just too slow for this world. Not only is it too slow, but it also does not produce solutions that are as good as those created by refining open source projects in the fire of real user feedback. So the industry has mostly replaced a standards-first approach with an open-source first approach. In many cases, with an open-source *only* approach, but there are also examples of open standards being created behind the bow-wave of open source, ratifying what have become defacto standards. [This recently happened with the Spring Batch project for example, where the lag between the first open source version being used in production, and the JEE standard being complete was about 5 years! That’s an eternity in today’s world of IT].
- Open source is also at the heart of many corporate strategies. Today there are a lot of VC-backed open source companies that treat open source as an integral, central part of their strategy. This is pushing the notion of professional open source to new levels – not just full-time developers, but the full gamut of business development tools and strategies being deployed around the creation of successful open source projects in the pursuit of commercial success. In hotly contested areas, the table stakes in the open source game have become very high indeed. So if open source is the leading edge of innovation, and a core part of many strategies and business models, what are some of the choices facing us when it comes to competing and collaborating around open source?
- In which we use the four C’s model to analyse some common options in the world of strategic OSS.[ALT – each of these could also be broken out into a picture slide following the format of the previous sections]I want to talk about three common choices for running an open source project. The most basic option these days is simply to host your code and project wiki / website at GitHub. This is can be a great way of getting your code out there, and of starting to build a user community. It is often chosen when the open source project is very largely developed by committers working for a single company. This option is less attractive if you want to enable development collaboration with other stakeholders – you have to manage all of the IP issues associated with that for yourself, and often need to provide a way to reassure other contributors that they can be equal partners. It does enable product-oriented business models (commerce), but makes it harder to support some other business models where the open source is intended to be the shared foundation for a platform and ecosystem.There are many advantages to hosting a project at a shared foundation – The Apache Software Foundation in particular – especially if fostering genuine collaboration is an important goal. Some projects, for example Twitter’s Storm, start off with the GitHub only model and then later on apply to move to a foundation. Storm is currently being incubated at Apache. Apache enables collaboration in two fundamental ways :- it can hold intellectual property in a neutral way such that the foundation and its users need not fear any lock-in, and it establishes a meritocracy giving everyone an equal opportunity to participate. The Apache Software Foundation checks all four of our boxes – it enables open distribution of code (with strong intellectual property management;, it has proven time and time again its ability to build communities; it provides a solid footing for collaboration; and it has licensing that facilities commercial backing and exploitation. With venture-backed companies looking to use open source for strategic advantage, the importance of a level playing field for collaboration has never been greater. So why did we not choose to go this route with Cloud Foundry? We elected for the third way. The creation of a dedicated foundation. This is an expensive and resource-intensive option and certainly not to be taken lightly! A dedicated foundation provides collaboration opportunities that go beyond just the code and related artifacts. It can facilitate collaboration around marketing and ecosystem development. It’s an option that only makes sense when you’re looking to establish broad ecosystem adoption around a collection of projects that collectively define a platform. Eclipse was an early example of this approach, and OpenStack a more recent one. We recently announced that we are collaborating with a number of partners to create a Cloud Foundry Foundation around the extensive set of projects that now make up Cloud Foundry. All under the Apache License version 2 of course.
- https://www.youtube.com/watch?v=6G3zYusffuw