PaaS or Fail? The Advantages of Platform-as-a-Service
Cloud Foundry sponsored this post.
A common pattern in the behavior of software engineering teams can be summarized as follows:
- Always start by deploying to Heroku. If not, use Firebase.
- Only when you’re scaling fast, containerize with Docker and deploy to your infrastructure.
- If you’re worrying about the plight of your containers at 3 a.m. on a Sunday, only then is it time to switch to Kubernetes.
By all measures, this is a reasonable path to take for any software development team. They are minimizing effort at each stage, while climbing up the maturity model in terms of managing their infrastructure.
This is true for teams of different sizes. They could be startup-scale, agency devs, or small teams bootstrapping a project within a large organization. Everyone is tempted to take this path of least resistance.
However, what tends to get lost in each stage of this progression is the significant volume of technical debt that is accumulated. That translates to added friction in the overall developer experience. Obviously, the preference of these teams — especially small ones — is to remain laser-focused on solving the business problems. Any deviation from this feels like it is a waste of valuable developer time and effort.
The argument against Kubernetes is that deployments are fairly complex and the trade-off is acceptable only if engineering teams have exhausted Docker’s capabilities. This argument is slowly losing favor, as engineering teams are beginning to realize that Kubernetes can benefit teams that have different sizes and deployment velocities. Leapfrogging to a Kubernetes-first deployment approach can have many benefits.
Is there a path these engineering teams can take that provides a dynamic interface over evolving infrastructure needs and trends?
It turns out, there are plenty of options. Some are battle-tested — like Cloud Foundry and OpenShift. Some are recent, such as Google Kf, Waypoint, and App Platform — which typically tend to work well for a niche audience. All of these options aim at providing one thing: a simplified experience for developers. As a bonus, they all support deployment to Kubernetes.
This article will focus on how Cloud Foundry is capable of providing a superior developer experience, while deploying applications as per modern standards (read Kubernetes) — plus accomplish all of this with fully open source components. Why Cloud Foundry, you may ask. For many reasons that will be highlighted in detail; but mostly because it is vendor-neutral, supported by a large and active open source community, and has a history of planet-scale deployments.
Historically, Cloud Foundry has had a simplified developer experience as the core of its mission. The Cloud Foundry community has steered the project across the VM and container landscapes without ever compromising on its simplified developer experience.
Today, with CF-for-K8s (and KubeCF), Cloud Foundry offers an easy path to begin a Kube-idiomatic path for any team to adopt Kubernetes for deployment; and simultaneously take advantage of the simplified Cloud Foundry developer experience. This way, engineering teams are not forced to make a choice between complexity and deployment best-practices.
Let’s examine the Cloud Foundry advantages from three distinct dimensions:
- Simple Deployments
- (Sm)All teams
- Open source
The Promise
Cloud Foundry provides a simple interface for developers to deploy their applications. This simplicity does not come at the cost of control. Developers can make granular modifications to their deployments with some additional declarative syntax when needed. The interaction with the Kubernetes API is obfuscated completely and in its place, the cf PaaS experience takes over.
Service Brokers enable services to be created, bound, and deleted. Separate subsystems are available for UAA (User Account and Authentication), RBAC (Role-Based Access Control), monitoring, logging, and networking. Some of these are an overlay over Kubernetes components, while others are native to Cloud Foundry. Multitenancy is built into the Cloud Foundry experience. Teams that need a multitenant Kubernetes architecture don’t have to architect their own platform, and can simply take advantage of the out-of-the-box capabilities. Similarly, these subsystems allow developers to deploy apps without having to go through a voluminous deployment checklist.
One Size Fits All?
Most engineering teams have bespoke needs and use home-grown techniques to deploy their software to production. Cloud Foundry can accommodate all of these changes as downstream to the fundamental cf push experience.
Changes to the pipeline, infrastructure, packaging and release, can all be accommodated with a reasonable amount of effort and without affecting the developer experience. Choices of different languages and frameworks for development can be made without worrying about any additional overhead. This is largely thanks to the use of Buildpacks, which are designed to work with any programming language and generate immutable artifacts for deployment. Small teams can stay nimble and large(r) teams can remain compliant.
Bring Your Own Infrastructure
The open source nature of Cloud Foundry makes it very advantageous for teams that are looking for transparency and governance. Cloud Foundry can deploy to public, private, or hybrid clouds; and can also work with a host of local dev environments. A uniform developer experience is made available across all of these varied deployments. A lot of the subsystems for CF-for-K8s come from the Cloud Native Computing Foundation projects which are open source themselves. Istio, Fluentd, and Envoy are a few noteworthy open source projects that the CF-for-K8s uses internally.
Risk-aware engineering teams will benefit from knowing that the major contributors to the CF-for-K8s project come from VMware, SUSE, IBM and SAP — among others. There is also an active ecosystem of system integrators, who are available to help with deployments when the demand for experienced contractors arises.
The bottom line is that there is never a silver bullet for resolving all the deployment needs in the world. Every engineering team creates its own culture of how to configure dev environments, CI/CD pipelines, deployment cadences, etc. However, from a lot of experience having observed the evolution of software and learning from our success stories, we can safely say that the Cloud Foundry experience can only add positive value to your present dev and delivery practices.
AWS, CNCF, VMware, Red Hat and SAP are sponsors of The New Stack.
Feature image via Pixabay
