We are running a #KubernetesPlatforms series where we are sharing our experiences and thoughts on how to build Internal Kubernetes Platforms. This is the first post in the series.
In the introductory post of the series, we saw how Kubernetes is best designed to be consumed through internal platforms. In this post, we will dive deeper into the first and foremost aspect of a Kubernetes Platform – Self Service.
Self Service is the Highest Evolution of DevOps
While most of the DevOps capabilities remain behind closed doors (such as part of CI/CD Pipelines), providing a self service capability indicates the highest evolution of DevOps in an organization.
Puppet calls out in their 2020 State of DevOps Report that
Highly evolved organizations are 6 times more likely than the least evolved organizations to report high usage of self-service platforms.Puppet 2020 State of DevOps Report
The 2021 State of DevOps Report further states that,
Platform team adoption differentiates those toward the higher end of mid-level evolution from those toward the lower end, with 65% of those toward the higher end (“high-mid”) using self-service platforms and only 40% of those toward the lower end (“low-mid”) saying the samePage 4, Puppet 2021 State of DevOps Report
So why Self Service and what does it really mean?
The traditional ticket based approach between dev and ops teams introduces significant delay in providing development teams access to infrastructure. Cloud has fundamentally changed that by providing self service access to infrastructure in the hands of developers.
When you are transitioning from Virtual Machines to Containers, a similar self service experience needs to exist for developers. Developers should be able to create Kubernetes infrastructure and deploy their apps to Kubernetes in a self service manner without much interaction with ops teams.
The ops teams on the other hand would be able to manage various Kubernetes environments as per the organization’s needs without affecting development teams’ day to day workflows.
Such a self service experience is definitely required in large organizations that have 1000s of developers where it is virtually impossible for ops teams to serve individual dev teams.
A Purpose Built Experience for Developers
Providing a successful self service experience starts with deeper understanding of developer workflows. Software development methodologies and processes are unique to every organization based on their culture and business demands. Day to day activities and workflows that are performed by developers can vary between organizations.
Hence it is important that platform teams think of themselves as product owners and build a self service experience that caters to the needs of the users of the platform – development teams.
Do teams follow Continuous Deployments? What does their release process look like? Can the experience start directly from a Container Registry? Or should it be deeply integrated with CI pipelines? How much of security can be shifted left?
Answers to questions like above should be asked by platform teams so as to offer an experience that works the best for developers.
How much Kubernetes should developers be exposed to?
The next and probably the most important aspect of building a self service experience is deciding how much Kubernetes should the developers be exposed to or expected to know.
Kubernetes by any means is not a simple piece of technology. Folks who have tons of experience in managing infrastructure have found it to be challenging to adapt to the steep learning curve that Kubernetes demands.
Expecting developers to understand the inner workings of Operators, CRDs and Service Mesh is a tall order.
However, different companies have different cultures. Many companies follow the “You build it, You run it” culture where the engineering teams are expected to own everything.
So, depending on an organization’s culture, platform teams need to decide the level of Kubernetes the self service experience demands from the developers.
Should the developers be expected to provide YAML based inputs? Can they access Kubernetes environments through kubectl? Or should the self-service experience remove all the underlying Kubernetes complexities and provide abstractions through a user interface or CLI that are easy for developers?
Questions like these needs to be answered during the design phase of the platform to make sure the self service experience doesn’t end up lowering developer productivity.
Non Production Environments
Developers often need non production environments (such as Dev/Stage/Test) that can be created on demand and disposed when not required. Developers should be able to create such environments by themselves through a self service experience without waiting on Ops teams.
The platform should abstract away most of the defaults for such environments so that developers do not have to tinker with many configurations every time they create an environment. This greatly improves developer productivity.
Depending on the maturity of organizations, even Production environments can be allowed to be created on-demand through self service.
Providing self service experience for creating environments drastically reduces the amount of time Ops teams focus on serving tickets and reduces any duplication of efforts.
Cloud Services Provisioning & Integration
The whole Cloud Services provisioning & integration in itself is a deep topic and warrants a separate post. We will be doing that in a future article in this series. But one of the key elements of a Self Service experience is to think about not just Kubernetes but also the Cloud Services Integration.
Most Kubernetes workloads would also integrate with Cloud Services (such as Amazon S3, Amazon RDS, Amazon DynamoDB). Those cloud services need to be provisioned first and then integrated with the apps.
The integration part requires apps getting the service details (such as service endpoints) as ENV and also getting required credentials to connect to those cloud services.
This entire aspect of provisioning and integration needs to be provided in a self service manner. Of course, you can ask developers to directly use Cloud Provider’s management console or Terraform scripts to provision resources.
However, the integration part still needs to be done for each and every application. This results in many monotonous tasks for the ops teams to create Kubernetes Service Accounts, IAM Roles & Policies, etc.
A Self Service experience, apart from web based UI, should also provide all the required tools that developers may need as part of their day to day workflows. These may include:
- CLI – Many developers may like to carry out their day to day workflows through a CLI. The same set of features available on the web based UI must also be available in a easy to use CLI
- Shell: Even with robust observability, there may be situations where someone needs to drop into a Shell of a running Pod / Container / Namespace. Developers should be able to seamlessly do this either from the web interface or the CLI
- Proxies: Sometimes one may need to test whether an internal Microservice is responding as expected or not. They would like to send, say, a HTTP request to test out their APIs. A browser based tool that can spin up on-demand proxies to such internal microservices would help in quick troubleshooting
- Load Testing Infra: As part of production deployments, developers may need to perform load testing and measure performance. Can they spin up the load testing infrastructure on demand? Can that be integrated as part of their delivery pipelines?
Of course the above list is in no way a conclusive set. Different organizations may adopt different sets of tools based on their needs. Platform / DevOps teams should provide a self service experience for developers to access those tools with least friction.
Benefits of Self Service
Providing self service access to Kubernetes infrastructure brings along tons of benefits for both developers and ops teams.
Focus on SRE activities
By rolling out a self service platform to developers, ops teams no longer have to spend time on addressing individual tickets and duplicating work across different teams. This helps them focus on higher order infrastructure activities such as performance, availability.
Bake in Best Practices
Ops teams can bake in best practices as part of the platform and provide meaningful defaults whenever developers create resources. Ops can provide pre-validated container registries, source repositories, observability infrastructure, etc. They can do this transparently without impacting developers’ day to day workflows.
Rollout Features Faster
Through a self service platform developers are no longer blocked for access to infrastructure. Their productivity drastically improves and allows them to ship features faster. They also no longer have to tinker around or worry about configuring infrastructure but rather focus on building their apps better.
Providing a Self Service platform experience for Kubernetes brings lots of benefits to both developers and ops while meeting them where they are.
By offering such a platform, ops teams are able to drastically improve developer productivity and help them ship features faster while they can focus on higher order of activities such as SRE.
As more and more organizations look to move faster, such self-service platforms are becoming the norm.
In the next post, we dive into the first self-service capability of a Kubernetes Platform – Cluster Management.