PaaS stacks aren’t just for the public cloud. Private data center operations can use Cloud Foundry as an infrastructure-agnostic way to host cloud-native enterprise applications. To do so, they’ll have to grasp Cloud Foundry BOSH, Diego, Container Runtime and other technologies.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Applications rest on a foundation of many hardware and software services. Platform as a service (PaaS) is the logical evolution of shared cloud services to bring abstraction closer to the application code itself. Cloud Foundry isn’t the only PaaS option. In fact, traditional infrastructure as a service (IaaS) vendors, such as Amazon Web Services (AWS), blur the line into PaaS with more sophisticated data and AI, as well as developer and deployment services. Cloud Foundry and IaaS vendors are not exclusive: Cloud Foundry BOSH manages infrastructure in AWS or a private set of servers with the same general process.
Think of PaaS within the context of the many subsystems required to deliver an application. The Cloud Foundry project for private cloud demarcates traditional IT, IaaS cloud and PaaS cloud by who manages what layer in the application stack hierarchy (See Figure 1). In this model, the base is core infrastructure, which includes networking, storage, servers and a runtime substrate of virtualization and OS. Atop this foundation are software components commonly deployed to run applications, including middleware and container runtime, with the application code and data completing the stack. In a traditional IT environment, operations teams are responsible for the bottom seven layers. Developers handle the application code, and the data layer is typically shared, with operations managing the infrastructure and developers in charge of the data itself. In IaaS, the service provider delivers everything through the OS layer, while, with a PaaS option, such as Cloud Foundry, the stack encompasses the infrastructure, software and management tooling up through the data layer.
Cloud Foundry PaaS works best in organizations that have adopted a DevOps structure to remove barriers between IT operations and application development. Developers usually drive PaaS adoption, as they have primary responsibility for product selection and introduction. However, operations teams must be intimately involved in the infrastructure deployment and management of PaaS. Operations pros must understand and run the networking through OS layers in the Cloud Foundry model. Their engagement is critical, since Cloud Foundry includes several automation tools to streamline deployment, administration and troubleshooting.
Cloud Foundry BOSH, Diego and other components
Cloud Foundry runs on a substrate of virtual servers: component VMs that run the necessary Cloud Foundry platform services and host VMs for a container runtime engine for containerized application code. Cloud Foundry automatically distributes and balances load across multiple containers and their hosts using the Diego orchestration component.
Although Cloud Foundry’s Diego container orchestration system is native to the PaaS, IT operations teams are not excluded from using Kubernetes. Kubernetes clusters work with the PaaS via Cloud Foundry Container Runtime, formerly named Kubo, an open source project that integrates Cloud Foundry’s BOSH infrastructure-as-code utility and Kubernetes. Container Runtime helps organizations containerize existing applications or use prepackaged apps delivered as a container, within a Cloud Foundry framework.
Code must be able to run on any node in the Cloud Foundry cluster, so developers package applications with the OS stack and necessary libraries into a buildpack. The host VM container runtimes unpack, compile and run these buildpacks on demand.
Operations teams are concerned with how the PaaS system creates and deploys host VMs on a server cluster. Cloud Foundry BOSH is used to deploy and configure the physical server and network resources from information in a document.
The components of a BOSH deployment are:
- Stemcell is a template for new VMs that contains a base OS and BOSH agent, which enables the BOSH engine to deploy and control the stemcell VM. VMs cloned from a stemcell can have different CPU, memory, storage and network configurations, along with different software packages installed, as specified by the other elements of a BOSH deployment.
- Release is a versioned package of source code, configuration files and startup scripts, layered upon a stemcell, that BOSH installs as a deployment job along with any dependent packages. For example, a release for the Redis database cache includes Redis startup and shutdown scripts, a source code package (called a tarball) from the official Redis downloads page and some customized configuration files.
- Manifest is a YAML configuration file that details the cloud infrastructure, network architecture, VM types and OS needed for a particular application deployment. The configuration primitives are cloud-agnostic, which allows BOSH to deploy to a variety of platforms regardless of whether Cloud Foundry is running on a private cluster of bare-metal servers or a public cloud, such as AWS or Google Cloud Platform (GCP).
Cloud Foundry’s logical separation of deployments into three levels of abstraction means that the user can change and adapt BOSH deployment for a new situation without redefining the entire bundle. For example, an IT operations team can switch between clouds by pairing an existing release with a stemcell designed for a new cloud — e.g., swapping AWS instances for Microsoft Azure equivalents — and tweaking the manifest. Such infrastructure agnosticism is integral to SAP’s Cloud Platform service, based on Cloud Foundry technology. It runs on SAP’s internal cloud infrastructure or GCP, Azure or AWS IaaS offerings.
Likewise, the user can update and roll back applications via different versions of the release file tied to an existing stemcell and manifest.
Administer a secure Cloud Foundry PaaS
No application platform is complete without a security mechanism, and Cloud Foundry includes components for user authentication and access controls.
The User Account and Authentication (UAA) Server is a service for issuing OAuth 2.0 tokens for client applications that work with user credentials from a login server. The UAA can act as a standalone directory, storing usernames and passwords in an internal encrypted database or connect to external directories, such as Microsoft Active Directory using Lightweight Directory Access Protocol or an external user store using Security Assertion Markup Language.
The PaaS technology also includes hierarchical role-based access control (RBAC) with roles and permissions centrally assigned for a Cloud Foundry organization at the top level of the hierarchy or by user and space for an application-specific security group. As in any RBAC security system, users can possess multiple roles, which each define a set of permissions, such as the ability to manage billing and payment information. Any combination of roles makes up each specific user’s overall access permissions.
Cloud Foundry BOSH software can significantly streamline infrastructure deployment and management, but the PaaS stack introduces many new concepts and requirements for application packaging, infrastructure automation and RBAC security that can impose a learning curve on IT operations teams. Cloud Foundry also requires close collaboration with development teams and is thus best pursued as part of a broader application modernization, Agile development and DevOps strategy.