Chapter 3. Cloud-Native Platforms
“Cloud Foundry is so resilient that the reliability of the underlying infrastructure becomes inconsequential.”
Julian Fischer, anynines
The previous chapter explored the current technical driving forces impacting software development and delivery. This chapter explores the key concepts that underpin the Cloud Foundry platform and how it is uniquely positioned to leverage the technical driving forces discussed in the previous chapter.
You Need a Cloud-Native Platform, Not a PaaS
Cloud Foundry is a cloud-native platform offering features that can be consumed “as a service.” Historically, it has been referred to as a platform as a service (PaaS).
Legacy PaaS
PaaS has been around in various forms for some time; but compared to the IaaS or SaaS layers, PaaS is not well understood because it is an overloaded and ambiguous acronym causing confusion. Everything from configuration-management solutions and middleware-provisioning systems to container-management and orchestration tools have, at some point, all been referred to as a PaaS. Early versions of PaaS struggled to gain broad market adoption because of:
-
Limitations around visibility into the platform
-
Lack of integration points to extend the platform
-
Limited or single language / framework support
-
Lock-in concern (due to no open source ecosystem) with a lack of non-public cloud options
The additional challenge with the term PaaS is that the boundaries between SaaS, PaaS, and IaaS are extremely blurred. For example, Amazon now offers a rich set of services natively on its Elastic Compute Cloud (EC2). Does that mean AWS is still just an IaaS, or is it now a PaaS?
The term PaaS should die, if it is not dead already. However, the reality is that the term PaaS is still out there in the marketplace, and its usage may not become obsolete as fast as it should.
Cloud-Native Platforms
Cloud Foundry is an opinionated, structured platform that rectifies the PaaS confusion by imposing a strict contract between:
-
The infrastructure layer underpinning it
-
The applications and services that it supports
Cloud-native platforms offer a super set of functionality over and above the earlier PaaS offerings. They do far more than provide self-service of resources through abstracting infrastructure. Their inbuilt features, such as resiliency, log aggregation, user management and security, are discussed at length in the next chapter. The key is that cloud-native platforms are designed to do more for you so that you can focus on what is important. Specifically, they are designed to do more (including reliably and predictably running and scaling applications) on top of potentially unreliable cloud-based infrastructure.
Cloud-native platforms are focused on what they enable you to achieve, meaning what is important is not so much what a platform is, or what it does, but rather what it enables you to achieve. What it enables you to achieve is this: it has the potential to make the software build, test, deploy, and scale cycle significantly faster. It removes many of the hurdles involved in deploying software, enabling you to release software at will.
Not all cloud-native platforms are the same. Some are self-built and pieced together from various components; others are black boxed and completely proprietary. The Cloud Foundry cloud-native platform has three defining characteristics: it is structured, opinionated, and open.
The Structured Platform
Within the platform space, two distinct architectural patterns have emerged: structured and unstructured:
-
Structured platforms provide built-in capabilities and integration points for key concerns such as enterprise-wide user management, security, and compliance. Everything you need to run your applications should be provided in repeatable way, regardless of what infrastructure you run on. Cloud Foundry is a perfect example of a structured platform.
-
Unstructured platforms have the flexibility to define a bespoke solution at a granular level. An example of an unstructured platform would involve a “build your own platform” approach with a mix of cloud-provided services and homegrown tools, assembled for an individual company.
Structured platforms are focused on eliminating the earlier PaaS-related problems mentioned above. For example, Cloud Foundry provides:
-
A rich and continuous stream of log information with integration points into application performance management (APM) solutions for visibility into how applications are performing
-
A rich set of continually streamed metrics for understanding how the platform itself is operating
-
Integration points into existing enterprise technologies (database services, message brokers, LDAP, SAML, etc.)
-
Support for numerous languages, frameworks, and services (polyglot)
-
An open source code base with a large supporting ecosystem, backed by a foundation of over 60 companies and an API not tied to any one vendor
-
Support for a number of different deployment options, including public and non-public cloud infrastructure
Structured platforms also focus on simplifying the overall operational model. Rather than integrating, operating, and maintaining numerous individual components, the platform operator just deals with the one platform. Structured platforms remove all the undifferentiated heavy lifting, tasks that must be done—for example, service discovery or application placement—but which are not directly related to revenue-generating software.
While structured platforms are targeted for building new cloud-native applications, they also support legacy application integration where it makes sense to do so, allowing for a broader mix of workloads. Similar to the following argument for opinionated platforms, the structured approach provides a much faster “getting started” experience with a lower overall effort required to operate and maintain the environment.
As a general rule, enterprise businesses gravitate to structured platforms as they offer the “on rails” approach to development and deployment. Some enterprises operate under a perception that their requirements are unique, and therefore, unstructured highly configurable platforms appear appealing. However the reality is that deviation of enterprise requirements, and the need for bespoke solutions is exceptionally low. Unstructured platforms can appeal to startups, as they are typically suited to pure greenfield development with no legacy IT applications or technical debt.
Platform Opinions
When you look at successful software, the greatest and most widely adopted technologies are incredibly opinionated. What this means is that they are built on, and adhere to, a set of well-defined principles employing best practices. They are proven to work in a practical way and reflect how things can and should be done when not constrained by the baggage of technical debt. Opinions produce contracts to ensure applications are constrained to do the right thing.
Like frameworks, which became popular in the early 2000s, platforms are opinionated because they make specific assumptions and optimizations to remove complexity and pain from the user. Frameworks focus on removing implementation pain from developers. This includes removing complex or repetitive tasks that are potentially error prone. The Spring Framework, for example, provides implementations of repetitive “boilerplate code” (code that must exist). Conversely, Java is less opinionated than Spring. If developers do not use opinionated frameworks, they are typically required to develop more code.
Non-opinionated software may support a wider set of use cases through more extensive configuration. They appear attractive at first sight because they can be taken in numerous directions and integrated with several components. You can swap pieces in and out at will and configure and extend it as you wish. However, at scale, these technologies become overly complex and work against you as they move into areas where scaling is limited by implementation complexity or brittle dependencies.
Platforms are opinionated because they make specific assumptions and optimizations to remove complexity and pain from the user. Opinionated platforms are designed to be consistent across environments, with every feature working as designed out of the box. They can still be configurable, and extended, but not to the extent that the nature of the platform changes. Platforms should have opinions on how your software is deployed, run, and scaled, not where an application is deployed; this means that, with respect to infrastructure choice, applications should run anywhere.
The Open Platform
Cloud Foundry is an open platform. It is open on three axes:
-
It allows a choice of IaaS layer to underpin it (AWS, vSphere, etc.).
-
It allows for a number of different developer frameworks, polyglot languages, and application services (Ruby, Go, Spring, etc.).
-
It is open sourced under an Apache 2 license and governed by a multi-organization foundation.
Closed platforms may be proprietary, and often focus on a specific problem. They may only support a single infrastructure, language or use case. Open platforms offer choice where it matters.
Choice of Infrastructure
This first point is crucial: Cloud Foundry is designed to leverage your infrastructure of choice. As such, it has been referred to as the operating system of the cloud. It serves as the standard way of leveraging cloud computing resources in order to deploy applications and services.
In the same way that the operating system on your phone, tablet, or laptop abstracts the underlying physical compute resource, Cloud Foundry abstracts the infrastructure’s compute resource (specifically virtual storage, networking, RAM, and CPU). The net effect is that Cloud Foundry serves as a standard way to deploy applications and services across different cloud computing resources.
The beauty of this approach is that it does not matter which cloud infrastructure you use, be it AWS, vSphere, OpenStack, Azure, Google, or Photon; Cloud Foundry gives you a platform to deploy against. While IaaS offers many advantages, the underlying platform infrastructure does not have to be cloud based. There is an initiative to support deploying Cloud Foundry directly onto physical servers. However, the principle requirements for self-service, on-demand, and elastic infrastructure still stand.
This infrastructure-agnostic approach provides a uniform API to avoid being locked into a specific infrastructure layer. If you want to have different parts of your business in different places, you are free to do this. This is known as the hybrid cloud approach. With Cloud Foundry, your developers and operators can have very similar user experiences whether on private clouds such as VMware or Openstack, or on public clouds like AWS or Digital Ocean. Applications can be freely moved between environments without complicated refactoring of the application or service layer. This approach is in stark contrast to teams that make direct use of a specific IaaS environments. Directly leveraging IaaS specific APIs requires developer patterns and operations knowledge to be extremely specific to the underlying IaaS technology, frequently resulting in applications tightly coupling to the underlying infrastructure.
Choice of Languages and Services
Developers need a certain level of flexibility and control over how they develop. They need to be allowed to choose the best language and service for the job. If this flexibility is denied them, then innovation can be stifled through conformity. At the same time, however, legitimate requirements exist to ensure that the technology has the appropriate level of governance and support. An employee can build an amazing application, but if it cannot be supported and maintained in production, it is of little use. Therefore, many companies want to standardize at the application layer while allowing a wider array of backing services.
Cloud Foundry can be tailored by a platform operator to offer the appropriate level of choice to the developer. The platform can support a rich set of languages (e.g., Java, Ruby, Go, Python), frameworks (e.g,. Spring, Akka, Play, Rails), and runtime technologies such as Tomcat. In addition, it supports a rich and consistent suite of services and libraries for the developer to leverage.
The Polyglot Dilemma
Some enterprises favor a polyglot approach because they feel that providing developers with choice promotes innovation. Other enterprises favor a streamlined approach of picking a smaller set of languages and services to ease ongoing maintenance and management. The choice is yours; you are free to lock down or open up the language and service choice as you see fit.
What you choose to make available to individual teams and developers is configurable on a per team basis. Configuring an appropriate set of languages and services allows for a diverse set of requirements. Some companies I have worked with offer more than 30 services to their developers. This can make sense in a microservices world where every service is free to implement its own backing store. Other companies may choose to offer only a handful of services, for example, a database such as Postgres, a distributed cache such as Redis, and a message broker such as RabbitMQ.
The Open Source Ecosystem
The middleware estate of well established enterprises has, until recently, included a hefty mix of proprietary middleware such as EJB-based application servers, service oriented architecture (SOA)-based messaging, and commercial monitoring and logging.
Companies embarking on a journey toward a cloud-native platform have, in general, already started a move toward lighter-weight open source components with commercial service and support as required. Cloud Foundry becomes a logical next step in that journey.
Open source is important, not just because it is free, but because anyone can get access to it. Consequently, open source becomes primarily important because it is where ecosystems are being built. Ecosystems have promoted a shift from vendored products controlled by the interest of a single company to open source ecosystems offering a suite of services, battle tested through broad adoption. When an ecosystem is established, it becomes a safe choice for enterprise adoption because you are aligning with a vibrant community pulling in the same direction.
The Cloud Foundry ecosystem is not only backed by open source, it is backed by a foundation. The foundation was born out of a shared belief within its growing community that Cloud Foundry was too important a technology to remain the property of any one vendor. The foundation serves as the home for all the shared intellectual property. It provides the mechanism with which the member organizations and the broader community are able to collaborate and contribute both money and effort. This includes technical contributions to create software from a shared vision to support a common cause.
The foundation currently includes nearly 50 members, and that list continues to expand rapidly. It ensures that the overall direction is not tightly controlled by the interest of one specific vendor but controlled by all the members with the interest of the entire community seen as paramount.
Products and services that call themselves “Cloud Foundry” are making a commitment to users and to the broader ecosystem that they will offer a common experience across the vendors. For application developers, this means being able to deploy and manage applications in a consistent manner. For platform operations, this means that knowledge and skills are portable across the commercial products. It also means there are clearly defined integration points for the ecosystem to leverage to extend the platform’s core functionality.
Chip Childers, VP Technology of Cloud Foundry Foundation
Cloud Foundry Constructs
Cloud Foundry is a cloud-native platform. Cloud-native platforms are essential for adapting to the aforementioned IT trends in Chapter 2. Specifically, the Cloud Foundry platform offers:
-
Services as a higher level of abstraction above infrastructure: Cloud Foundry provides a self-service mechanism for the on-demand deployment of applications bound to an array of provisioned middleware services. This benefit removes the management overhead of both the middleware and infrastructure layer from the developer, significantly reducing the “development to deployment” time.
-
Containers: Cloud Foundry supports the use of container images such as Docker as a first-class citizen. It also supports running applications artifacts deployed “as is,” containerizing them on the user’s behalf. This flexibility allows companies already established with Docker to use their existing assets. Containerizing applications on the user’s behalf offers additional productivity and operational benefits because the resulting container image is built from known and vetted platform components, leaving only the application source code to require vulnerability scanning.
-
Agile and automation: Cloud Foundry can be leveraged as part of a CI/CD pipeline to provision environments and services on demand as the application moves through the pipeline to a production-ready state. This helps satisfy the key Agile requirement of getting code into the hands of end users when required.
-
A cultural shift to DevOps: Cross-cutting concerns is a well-understood concept by developers. Cloud Foundry is ideally accompanied by a cultural shift to DevOps.
-
Microservices support: Cloud Foundry supports microservices through providing mechanisms for integrating and coordinating loosely coupled services. In order to realize the benefits of microservices, a platform is required to provide additional supporting capabilities, such as built-in resilience and application authentication.
-
Cloud-native application support: Cloud Foundry provides a contract for applications to be developed against. This contract makes doing the right thing the easy thing and will result in better application performance, management, and resilience.
Chapter Summary
Cloud Foundry is an opinionated, structured, and open platform.
Opinionated platforms are:
-
Built on, and adhere to, a set of well-defined principles employing best practices
-
Constrained to do the right thing for your application, based on defined contracts
-
Consistent across environments, with every feature working as designed out of the box
-
Configurable, and extendable, but not to the extent that the nature of the platform changes
Structured platforms offer:
-
A fast “on rails” development and deployment experience
-
Lower overall effort required to operate and maintain the environment than unstructured platforms
-
Built-in capabilities and integration points for key enterprise concerns such as user management, security, and audit compliance
Cloud Foundry is primarily concerned with how you achieve things and not where you achieve things. The how is key:
-
How do you deploy quickly?
-
How do you keep applications running?
-
How do you provision and bind an application to a service?
-
How do you scale?
-
How do you stream logs?
The where, as in what type of infrastructure is supporting the platform, or what container engine the application runs in, should be immaterial to the platform and entirely up to you.
This chapter assessed the nature of cloud-native platforms over and above the earlier PaaS offerings. The next chapter focuses on the specific features and benefits of the Cloud Foundry platform.