An Intellyx BrainBlog for Cloud Foundry by eric newcomer
A big debate in platform engineering is how opinionated an internal developer platform (IDP) should be, and how much should be left to the developers’ discretion.
A successful IDP draws a fine line between being too opinionated and being too open. Generally speaking, an organization tends toward being opinionated about standardizing on a small number of platform choices, while developers often prefer a platform to be more open to selecting their own tools.
Different reasons impact selection of an IDP:
- The organizational tendency toward being opinionated is typically due to the cost of buying and supporting too many software products, and because of the high cost of recruiting and training developers. Too many options increases the cost of both.
- A big driver for choosing an opinionated IDP is ensuring application compatibility across the organization, especially when the application consists of hundreds or even thousands of microservices that need to work together.
- But primarily, the choice of an opinionated IDP is about having someone with the right skills and experience and perspective choose the right technology to simplify the developer’s job.
Organizations will often try to be flexible when different options produce the same result – such as using different IDEs of testing tools to produce compatible source code. But at the end of the day organizations will tip the balance toward opinionated solutions for cost efficiency.
The Role of Kubernetes IDP
As many people know by now, Kubernetes evolved out of an internal Google project called Borg, which was developed to automatically deploy programs across multiple VM clusters.
Working with Kubernetes involves two main aspects: configuring and setting up the clusters, and deploying programs into the configured clusters.
Many organizations, especially those with large volumes of Kubernetes clusters, set up Site Reliability Engineering (SRE) teams to configure and maintain the Kubernetes clusters for the developers to use.
Many open source projects and vendor products are available to complement Kubernetes for this reason – i.e. to reduce the overall effort of the SRE teams. Not to mention reducing the need for highly skilled Kubernetes experts, which are in short supply.
Other projects simplify the entire process of development and deployment for Kubernetes – this is the role of the Kubernetes IDP.
Effective Automation with a Kubernetes IDP
People often consider the moving assembly line the key enabler of mass production, or that the CI/CD pipeline is key to automated deployment. In fact it’s the standardization of components that enables automation in both cases.
So an opinionated Kubernetes IDP needs to support a build pipeline that deploys standard components into clusters that can be assembled with other standard components, for example to create applications based on microservices that work seamlessly with each other.
Containers are an essential component of an opinionated Kubernetes IDP, because they allow developers the flexibility to use almost any development language.
However, applications typically have integrations with several services, such as working with persistent stores, secrets management, authentication and authorization policies, networking, microservice discovery mechanisms, and API frameworks, and so on.
The choice of OCI container formats and Kubernetes as standard components for a Kubernetes IDP are essential, but only the beginning of the choices for an opinionated Kubernetes IDP.
Buildpacks for Container Dependencies
When building a container for a microservice, there are typically multiple options to consider. Organizations often maintain an opinionated library of approved images to include for various standard functions, such as authentication and authorization.
As the previous blog in this series describes, using Paketo Buildpacks help standardize container builds. Buildpacks transform source code into container images, including all declared dependencies.
Buildpacks simplify automation, reduce build times, create more efficient workflows, and reduce overall cost.
The Korifi Kubernetes IDP
The Korifi Kubernetes IDP from Cloud Foundry supports the Cloud Foundry approach and implements the Cloud Foundry APIs on Kubernetes. Most core Cloud Foundry components are replaced by implementations using cloud native equivalents.
Korifi brings to Kubernetes the classic Cloud Foundry experience of deploying microservices written using any language or framework with a single cf push command. Developers don’t have to worry about creating and maintaining their own complex YAML and Docker files.
Cloud Foundry was however originally developed before Docker and Kubernetes became standard choices. The Cloud Foundry community is now bringing its long-standing expertise in the area of a first-class developer experience to Kubernetes, however, offering an IDP that can run existing workloads on Kubernetes, and quickly create entirely new workloads for deployment to Kubernetes clusters.
Why Cloud Foundry for Kubernetes?
Cloud Foundry was among the pioneers of cloud native computing. Its implementation of the 12-factor approach was widely recognized as an essential approach to successful cloud native computing.
One of the great achievements of Cloud Foundry and its consulting practice was helping traditional developers grapple with the differences between the traditional “scale up” environment and the cloud native “scale out” environment.
Many developers find the Kubernetes part of the equation to be complex, and difficult to work with. Developer abstractions such as the Korfi IDP for Kubernetes significantly simplify the process of automated deployment on Kubernetes.
Cloud Foundry’s history of cloud agnosticism helps to build solutions that work with any flavor of Kubernetes, and deploy on any cloud provider, data center, or hybrid infrastructure.
The Intellyx Take
The Korfi IDP with Paketo Buildpacks provide application delivery teams with total flexibility in selecting their platforms and open source components of choice, with automation and reproducibility.
That’s why many development teams are adopting buildpacks, and removing the black box around containerization—no matter what deployment platform and methodology they use.
An opinionated Kubernetes IDP such as Korfi helps organizations navigate the complexities of deploying on Kubernetes by making some important technology choices for you, while leaving in place the flexibility for developers to choose their own language and dependencies.
Copyright © Intellyx BV. Cloud Foundry is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used to write this article. Image credit: Cottonbro studio on Pexels.
