Your product teams shouldn’t care about Kubernetes. In fact, they shouldn’t care about DevSecOps, at least not when building and maintaining the complex tooling needed to drive CI/CD automation.
This may sound bizarre, especially coming from someone who works for a company specialising in Kubernetes and cloud-native technology. To explain the rationale, I’ll provide an example of a common pattern we’ve seen when helping teams to modernise over the last half a decade:
“We need to move faster! I want so many new features in our customers’ hands that they’ll be sick of app updates! And scale! I want Google to be in awe of how many transactions we’re handling every nanosecond!”
And with this aspirational call to action, our modernisation journey begins. I won’t delve into the 5 Rs of application modernisation (although I would propose a 6th “R”: resign, which is what you do after an expensive modernisation project fails).
For the sake of our example, let’s assume what follows is a complex refactoring exercise. Architects speak loftily about domain-driven design. Contexts are bounded. Squads are selected. What emerges is a brand-new microservices architecture. Did someone say smaller codebases, improved fault isolation and independent scalability and releases? You bet they did!
A few iterations into the project, our devs, who’ve been using containers to package microservices, realised that running containers across a few VMs simply won’t pass muster in production.
This Kubernetes thing
The team needs machinery to handle high availability, graceful deployments, resource isolation, networking, health monitoring and autoscaling. And so, with our go-live date looming, an industrious senior developer starts digging into this Kubernetes thing. Emerging red-eyed after late nights pouring through Kubernetes the Hard Way, a Kubernetes cluster is built, demoed and heralded as the platform du jour — ticking all the container orchestration boxes and then some.
Over the following weeks, it becomes clear that without a consistent way to build, test, secure, version and deploy containers to our recently minted Kubernetes substrate, the product team will be cursed to toil in release automation purgatory, wrangling unknowable artefact versioning spreadsheets and running arcane bash scripts to get their code deployed (true story!).
And so, with the dictums of full-stack DevOps in mind, two more developers are tasked with engineering CI/CD automation capable of handling our elaborate build process, rapidly executing myriad test cases, scanning code and container images for vulnerabilities, cryptographically signing container images, and deploying and promoting containers from development to production.
Fast-forward through multiple sprints and many gallons of coffee, and we are post-go-live. The launch was a resounding success and our refactored microservices app is performant and stable. Worryingly, our feature backlog is growing, and several release dates have been missed.
The reason for this loss of cadence and a product team that looks like they’ve gone a few rounds with a (young) Mike Tyson? Well, it so transpires that keeping our production Kubernetes cluster operational, not forgetting the diaspora of supportive technologies running within it, from ingress controllers to logging and monitoring stacks, has become a full-time job for a handful of senior developers, often having to work in late-night maintenance windows.
Worse yet, maintaining our CI/CD automation toolchain has become an exercise in quantum mechanics, consuming many developer hours in fixing integrations and pipelines, which frequently block releases. There must be a better way.
And there is! The answer lies in the emerging practice of platform engineering and creation of internal developer platforms (IDPs). Many highly successful engineering organisations, such as Spotify, Netflix and Twilio, have established centralised platform engineering teams whose primary mandate is to eliminate developer toil, a metric Twilio measures as “time spent outside of code”.
This extends beyond centralising DevOps, but rather creating a laser focus on building and evolving an IDP that can be consumed across the organisation. IDPs are designed to abstract the underlying machinery and infrastructure developers require to build and deploy their applications, creating a “golden path” that product teams can follow to accelerate velocity and reduce cognitive load. Notably, the make-up of IDPs may vary drastically between organisations, but should be consistent when it comes to the following tenets:
- IDPs should be treated as an internal product, with a defined product road map, versioning and customer feedback.
- Developers should be able to self-provide everything they require through an established service catalogue, whether it’s a software library, CI/CD pipeline, Kubernetes cluster, etc.
- An IDP should impose standards from a technology and tooling perspective that align with organisational requirements. Mature IDPs strike a good balance between enabling consumers’ flexibility and diverse options while maintaining guardrails to drive consistency and supportability. This extends across governance, access control and security standards.
- Documentation on how the IDP is consumed should be extensive and updated. Teams should go from zero to up and running by simply following the docs.
- Ideally, consuming teams should be able to interact with the IDP using their preferred means, whether it’s through a Web UI, CLI tool or API.
The rationale for investing in an IDP is simple: let product teams focus on delivering better digital experiences to customers and enable them with a consistent delivery process while addressing their specific needs.
As organisations converge on modern application architectures and cloud native ecosystems, IDPs create soft landings for developers whose time is better spent building new features than reading Kubernetes the Hard Way.
About LSD Open
LSD was founded in 2001 and wants to inspire the world by embracing OPEN philosophy and technology. LSD is your cloud-native acceleration partner that provides managed platforms, leveraging a foundation of containerisation, Kubernetes and open-source technologies. We deliver modern platforms for modern applications.
For more, visit www.lsdopen.io, e-mail [email protected] or visit us on LinkedIn, Twitter, Facebook, Instagram and YouTube.
- The author, Julian Gericke, is chief technology officer at LSD
- This promoted content was paid for by the party concerned