Cloud Foundry Guides Enterprise IT Towards Cloud Native Applications

Premise

Whether CIOs recognize it or not (yet), Software is Eating the World, and there’s a good chance that their industry might be next on the menu. The emerging PaaS platforms (Cloud Foundry, Heroku, OpenShift, Docker) are all evolving to capture the mindshare of developers. While the PaaS battles are still in early days, Cloud Foundry is emerging as a leading open source platform and ecosystem to build and deploy the new Cloud Native applications that are driving these economic changes via software. But this Platform-as-a-Service (PaaS) model requires changes to technology, skills (people) and internal IT processes. This means enterprises need to become familiar with this development and operational model to best understand how they can accelerate using Cloud Native applications to give themselves a business differentiation.

Content

1. The Why: Why PaaS? Why Cloud Foundry? Why Cloud Native Applications?
2. The Now: The Ecosystem, Foundation and Competition
3. The Conversation: Transformation to Software-Centric Enterprises
4. Final Thoughts

The Why: Why PaaS? Why Cloud Foundry? Why Cloud Native Applications?

The promise of Platform-as-a-Service (PaaS) is a cloud model that allows developers to just write applications and not have to worry about how the underlying infrastructure works. The business value being faster deployment of revenue generating or differentiated applications. Various PaaS platforms have been in existence since the mid-2000s, with language-centric platforms such as Heroku (acquired by Salesforce.com) Windows Azure and Google App Engine. While they attracted some developers and web start-ups, they failed to attain widespread Enterprise adoption.

Introduced in 2011 as an open source project from VMware, Cloud Foundry changed the PaaS model in three significant ways:

1. “Polyglot” – it supported multiple development languages (Java, Ruby, Node.js, Python, .NET, Go, etc.), allowing a broader range of applications to be supported.
2. “Multi-Cloud” – it could be run on multiple cloud providers, both public and private.
3. “Open Source” – it allow multiple groups to contribute and reduces the change of single-vendor lock-in.

Over time, VMware spun off the Cloud Foundry organization into Pivotal, the Cloud Foundry project moved under the independent Cloud Foundry Foundation. This provided transparency, governance and a defined model for (vendors, ISVs, customers, cloud providers) to participate in the projects.

Cloud Foundry is architected to deploy and operate modern applications. These applications are known by many names – 3^rd Platform, Cloud Native, Twelve-Factor, Microservices. Regardless of name, they are designed to be more modular than applications in the past, and seek to be web-scale in size and impact. Cloud Native applications are designed to be more modular and better aligned to Agile development and Continuous Delivery (CI/CD) models (eg. “DevOps”).

The Now: The Ecosystem, Foundation and Competition

The Cloud Foundry ecosystem is made up of the industry’s leading software vendors (Pivotal, IBM, SAP, Microsoft, HP, Huiwei, Intel, Canonical, Cisco, VMware, etc.), leading service providers (Comcast, Verizon, Canopy, CenturyLink, Orange, Rackspace, Swisscom, NTT) and many large Enterprise companies and universities.

While Cloud Foundry is not the native operating environment on mega-clouds such as AWS, Microsoft Azure and Google Compute Engine, it can be deployed on any cloud. For example, Pivotal Web Services runs on AWS, and Microsoft Azure recently account Cloud Foundry as a native service on their cloud. IBM BlueMix runs on the global SoftLayer cloud data centers.

In order to drive architectural consistency and interoperability of implementations between vendors, the Cloud Foundry Foundation was established in 2014. Application portability between clouds and reduction of vendor lock-in are critical requirements for Enterprise IT organizations, so maintaining a high level of consistency will be a crucial measuring stick for the Foundation. This interoperability will not only let the various contributors focus higher in the stack, but also leverage the variety of private and public IaaS infrastructures to run these new Cloud Native applications.

The competitive landscape for Cloud Foundry will have several factors and layers.

1. First, at the PaaS layer, Cloud Foundry faces some challenge from RedHat’s OpenShift, but OpenShift does not appear to have the same broad community support as Cloud Foundry.
2. Second, Cloud Foundry must compete with existing Infrastructure-as-a-Service (IaaS) offerings, both public and private, from AWS, Google, Microsoft, OpenStack and VMware. Developers can deploy Cloud Native applications on these clouds today, using their existing tools and frameworks. While this approach does make scaling more difficult, it maintains a level of consistency with existing processes and tooling.
3. Third, the Cloud Foundry ecosystem must find the right balance between consistency and differentiation of offerings. Some of the parties involved are new to open source communities, or are bitter rivals in other areas of IT. It will be crucial for the Cloud Foundry Foundation to play an active role in driving that level of consistency and including end-customer input in the overall development process.
4. Fourth, Cloud Foundry will be challenged by the fast-moving “Unstructured PaaS” movement, that’s being lead by various container-centric projects and offerings (Docker, CoreOS, Kubernetes, Hashicorp, Mesos, LXD, etc.). Many startups and technology-centric companies have built their own platform, using modular open source elements. 

The Conversation: Transformation to Software-Centric Enterprises

While startups like Uber, AirBnB, Square, Tesla, eSurance, Twitter and many others are disrupting established industries, they lack the legacy application portfolio that burdens many Enterprises. So what’s the blueprint for established companies to mange this transition and make software a core competency?

1. Leave the Legacy Behind – Too many companies believe they will be able to “re-architect” decades old applications. Instead, they should think in smaller increments, or focus on new application development.
2. Experiment with Structured and Unstructured PaaS Platforms – Regardless of how the company builds Cloud Native applications, it’s important to have an underlying “platform”. Both Structured PaaS (eg. Cloud Foundry) and Unstructured PaaS models have freely available open source options to start, as do several of the commercial PaaS vendors. Understand what models fits best for your business culture and skills.
3. Embrace DevOps Culture and Collaboration – The operating model of successful Software-Centric Enterprises is DevOps. At it’s core is a collaboration culture that will be different that exists in the business today. It’s critical to learn the best practices before making technology changes.
4. Don’t Fear Open Source – At the core of these evolving Cloud Native models is open source. It’s important to understand how these communities work in terms of licensing, contributions, collaboration and support. It’s equally important to understand how the technology transitions from open to commercial and the vendors involved.
5. Engage Help and Establish Early Wins – Engaging expertise from vendors in the Cloud Native and PaaS communities are a great way to create a successful PoC. These early results will help win internal followers in the business that have to part of the change to becoming more Software-Centric.

theCUBE interviewed Cloud Foundry Foundation CEO Sam Ramji at the OpenStack Summit Vancouver 2015 – see the full interview below

Final Thoughts

There is no doubt that Cloud Native applications are changing both the economic and technology landscape for most Enterprise organizations. But how to get there has many options. PaaS such as Cloud Foundry is one option that has significant potential, but it involves multiple levels of change to any organization. It’s critical for IT leadership to quickly gets practical experience with multiple models to understand which one best aligns to the company culture, skills and business