In the previous post, we discussed why Organizations need to build an internal Kubernetes platform to enhance the developer experience. We covered the first three capabilities of such a platform:
- Simplified, Enterprise Grade Cluster Provisioning
- Application Centric Configuration Management
- Integrated Observability
In this second part, let’s uncover some of the other capabilities that the platform needs to provide.
Multi Cloud / Hybrid Cloud
One of the primary reasons why many organizations (specifically Enterprises) show tremendous interest in Kubernetes is the promise of portability. Kubernetes provides the ability to shift or run workloads in any underlying infrastructure be it a Cloud Provider or on-premises.
Hence the platform should provide the capability for developers to choose the underlying infrastructure provider and seamlessly deploy their applications.
Developers need a similar interface or workflow to seamlessly deploy in any underlying infrastructure. This ensures that developers do not have to switch between different terminologies or workflows and the experience remains the same irrespective of the underlying infrastructure (be it Cloud or on-premises).
Automated Cloud Services Provisioning
The applications that you deploy within your Kubernetes environments may require few cloud services to function. Say, your applications need an Amazon SQS queue or GCP’s Cloud SQL.
Typically these are provisioned either directly using the Cloud Provider’s management tools or Infrastructure As Code tools such as Terraform.
However, when you are building out a platform for your developers, it is not desirable for them to hop to other tools for provisioning Cloud Resources. This introduces complexities in terms of Access Management, Governance, Standardization, etc.
Hence it is imperative that the platform that your developers use to deploy their applications also allows them to seamlessly provision required cloud services too.
There are many open source extensions/addons built over Kubernetes that can be used to provide this capability. These include Crossplane, Kubernetes Service Catalog (implemented using Open Service Broker), AWS Controllers for Kubernetes, GCP Config Connector, Azure Service Operator.
Fine Grained Cost Visibility
Last but not least, just like how you deployed Cost Management tools to analyze your Cloud spends deeper, you need to build similar capabilities for your Kubernetes environments.
The lens that you used to visualize your Cloud spends at a Virtual Machine level now needs to be magnified to visualize your spending at a Container level.
You are likely to deploy multiple Kubernetes clusters and more importantly many workloads within a single cluster. Hence the platform should provide out-of-the-box cost visibility to your developers where they are able to see costs for their deployed apps and optimize if required.
Conclusion
Kubernetes further blurs the line between Development and Operations teams. While Kubernetes is now typically embraced by Operations folks, for large scale adoption within your organization, it is important that your Developers too embrace it.
However, they need not be forced to understand and live with the complexities that Kubernetes brings with.
A Kubernetes platform that’s focused on providing a simplified developer experience and at the same time allowing your operations team to securely manage your infrastructure will result in the widespread, successful adoption of Kubernetes.
Are there any other capabilities that you would like to see in such platforms? Let us know in the comments below.
One thought on “Part 2 – The need for developer focused Kubernetes Platforms”