Mar 08, 2023
Mar 08, 2023|
8 min read
Theoretically, Kubernetes is close to perfect. It’s a game-changer for modern businesses because it standardizes and unifies a bunch of functionality that suitably-designed applications can leverage to work securely and reliably without much human intervention.
But working with Kubernetes might be making your developers’ lives significantly harder.
Why? Because Kubernetes, by its nature, is not what developers signed up for. Developers want to focus most of their attention on coding: creating and enhancing applications.
They don’t, however, necessarily want to also be responsible for:
This is “operations” stuff, not coding stuff. These days, many organizations ask developers to do an increasing amount of this operations work – we call it “DevOps.” And part of the reason is that a growing fraction of this work is accomplished by coding. Kubernetes is powerful, in part, because it’s all configured in code, and operated – day to day and moment to moment – by making changes to application and cluster configurations and pushing them to Kubernetes to execute.
But “doing Kubernetes” still looks a whole lot different from your developers’ ideal day. It’s all about building, managing, and securing the many containers required by modern, distributed applications. Wrestling with Kubernetes’ quirks around IP addresses, networking, and storage. Keeping up with constant updates, corrections, and troubleshooting. Not to mention those late-night on-call notifications.
These are necessary parts of using and running Kubernetes. In fact, they’re where a lot of the ROI of Kubernetes and modern software development come from. A fully built-out Kubernetes cluster can host apps more securely and reliably. Automated software assembly gets changes and new features into production quickly – top-ranked Kubernetes teams sometimes deliver improvements to production many times each day. And Kubernetes itself can, in principle, eliminate a lot of the manual labor of operations if configured (in code) correctly.
But that’s a big if. All these tasks are time-consuming, complex, and demand new skills. And developers increasingly report that the demands of DevOps are breaking them.
The pressure to “do it all” isn’t new to developers. Many feel constant pressure to be “full stack,” and master each and every skill that a software engineer could have to become a “jack of all trades.” What’s more, many companies want to hire “full-stack developers” because it seems like they can get more work done with fewer people.
This is a recipe for developer burnout and unhappiness.
Developers aren’t infrastructure and operations experts, and they shouldn’t have to be. Those are different areas of expertise and specialty. When people in most other professions are asked to take on multiple roles at once, they protest, asking for a raise, a new title, or to assign some of the new work to another person. But for some reason, developers exist under the expectation that they should have to “do it all” to keep up with what’s widely expected from the industry.
For our part, we believe this mindset is harming developers, and as a result, more developers are quitting their jobs and even leaving the field entirely! This is creating a tough situation for companies and recruiters, who can’t fill positions.
We shouldn’t demand the world from people who excel in their own lanes. And developers certainly do that: They're mission-critical for business development, and they should be allowed to do what they do best without taking on the world.
Yes, there are developers out there who are “unicorns,” and who can be full-stack, DevOps, Kubernetes rockstars, and not lose any sleep. But that’s simply not realistic for 90% of software professionals. For most developers, focusing on strong skills in just one area is likely the best way forward, both for them and their organization. That’s the way that most developers deliver the best value.
To succeed, organizations need their developers to do what they do best—without burning out.
So, what’s the solution? How can companies make sure their developers are happy, productive, and not burning out? The answer is DevOps-as-a-Service.
DevOps-as-a-Service is a way for companies to outsource the management and maintenance of their Kubernetes infrastructure to a team of experts. These experts have the necessary skills and knowledge to handle all the tasks related to Kubernetes platform engineering:
This frees up developers to focus on what they do best: coding, creating, and developing applications. It also allows them to work on the parts of the project that they’re most interested in and passionate about. And it means that they don’t have to worry about all the “other stuff” that comes with running Kubernetes.
There are several benefits to using DevOps-as-a-Service, including:
In short, DevOps-as-a-Service helps companies get the most out of Kubernetes without burning out their developers. It allows for increased productivity, better team dynamics, more efficient use of resources, better security, faster time-to-market, and scalability.
Now comes the part where we say “call us!” Right?
Wrong. DevOps-as-a-Service is a concept – and you have unique needs that “concepts” alone can’t fulfill. Here are a few questions to ask, as you’re evaluating solutions:
How dependent are you on specific ways of doing things? How wary are you of lock-in?
Software supply chains and DevOps setups are classically assembled from many parts (most open source). This can get complicated quickly. But artisanal supply chains are easier to optimize and bend around a team’s existing skills, preferences, and quirks. And they avoid locking-in critical parts of your supply chain to one vendor’s, project’s, or cloud service provider’s vision, the way end-to-end solutions can.
It takes a provider with vast knowledge and experience to deliver efficient supply chains while enabling customer freedom of choice. The provider you pick should absolutely be “opinionated,” quick to offer solutions they’ve tested rigorously, and quick to explain why they like these solutions. But they should also be able to flex with your needs without abandoning SLOs, SLAs, and guaranteed results.
You can get DevOps-as-a-Service for any subset of these domains. You may already have a hardened, production-ready cluster with underlying infrastructure management under control, and just need build pipelines. But if you need everything (and today, most organizations actually do) make sure your candidate provider has the expertise and capacity to solve your problems.
Delivering software in modern environments is hard. Making any build pipeline run is an accomplishment if it gets production applications up and healthy. But it’s not the whole job. Many software teams lack deep expertise in disciplines like container and cluster security, compliance, observability, and performance optimization – all clearly critical. And these disciplines are most effective when applied consistently throughout the software supply chain and target clusters. Do your candidate Devops-as-a-Service partners have all the answers, here? Because someone is going to have to come up with them.
Do you need a ‘thick’ software supply chain, or a ‘thin’ one?
These “thin stack” folks are in a good position to think of DevOps-as-a-Service in the most revolutionary and disruptive way: i.e., why do we need to manage anything to get to “just push our code?”
There are comprehensive solution-stack-oriented, cloud-based DevOps-as-a-service providers (like amazee.io) who can set you up with everything you need (including cloud-resident Kubernetes) to modernize and operationalize your web application. We host Lagoon – an operationalizing framework for solution stacks, including yours, that handles all the mechanics of making a standard web app efficiently self-scaling and self-repairing and observable on Kubernetes. We do all the work of curating the bits and pieces of your core stack and integrating it with the Lagoon framework.
And then we run your apps for you – you just push your code, and keep improving it.
Depending on infrastructure and Kubernetes investments you may already have made, you can get pieces of this, as well. Amazee’s Lagoon-as-a-Service just hosts the Lagoon instance, which can integrate with your on-premises or public cloud Kubernetes. Or if you just love DIY, you can install and operate your own Lagoon instance – it’s open source.
Now comes the part where we say “please contact us.”