Is Kubernetes right for us? That’s a question that will have been asked many times, but perhaps not publicly, for fear of looking out of touch, or behind the curve. After all, the term “imposter syndrome” was coined to describe the anxiety we face as we try to keep current with technology and what is happening in the industry.
Pictured above: Gartner’s Hype Cycle describe the effect of new and innovating technology on the ecosystem, from inflated expectations, to disillusionment.
In this post I’ll introduce a real-life example from a consulting prospect, who asked me whether he should adopt Kubernetes, and a blog post that I wrote to show that there’s more to cloud than Kubernetes
Part 1 — There’s a spectrum
About six months ago, I wrote a blog post called “Your team might not need Kubernetes.” It was a simple hypothesis and I outlined several ways that a company with legacy IT could begin to modernise their applications, without necessarily making a leap directly to Kubernetes.
It starts off with the idea of cloud technology as a spectrum of complexity vs. potential benefits. At one end, you’re completely on-premises running on bare-metal on servers that you own or rent and are in full-control. At the other end, you’re running everything on public cloud with a managed Kubernetes cluster.
I don’t believe that Kubernetes is the destination for all users.
You can start to leverage the benefits of the cloud just by lifting & shifting existing code to managed compute services. This may reduce the overheads and management costs of bare-metal, and even enable some level of elasticity, enabling faster growth. Remember that just like in the Dilbert cartoon below, you may also need to consider rebuilding or redesigning parts of your system, and that may require going outside of your area of expertise.
An experienced cloud architect, or DevOps professional should be able to help you make smart choices, and to guide your IT modernisation process.
It may actually be that compute is not the lowest hanging fruit for your business, and that simply by moving your database from on-premises to the cloud, using something like RDS (Relational Database Service) could increase reliability. It may be that your reports are taking too long to produce, and that moving to a managed option may reduce the time needed to run them.
Traditional applications that require Windows, a legacy .NET runtime and IIS don’t tend to fit quite as seamlessly into modern cloud practices. So a low-risk approach to adopting cloud can be as simple as building new functionality with a modern framework designed to run on the cloud like .NET Core, Node.js, Vert.x, or Golang.
There is a spectrum — between doing everything with your internal IT team, and hardware estate and jumping in with both feet — going fully managed.
Between those two points you will find plenty of other options, including Heroku (PaaS), AWS Lambda (FaaS), and Google’s Cloud Run (CaaS). These are broadly known as “Platform as a Service” products. They make it easy to drop code somewhere, and to have the heavy lifting done for you. If your team is comfortable building containers, you may even look at AWS’ Elastic Container Service, which has a lower barrier to entry than Kubernetes.
The final point to consider is whether portability is a true concern. The ThoughtWorks technology radar states that anti-lock-in abstractions are productive, but that using Docker containers provides an industry-standard for packaging applications. Perhaps then, if portability is a primary concern, starting with packaging code with Docker, could be a first step?
Let’s look at a real-world example.
Part 2 — the real world example
This part is adapted from my Insiders Update: 12th July 2020 — is Kubernetes right for us? 🤔 Spotlight on arkade & k3sup. To receive them each week, subscribe on GitHub.
As part of my business I sometimes meet with consulting prospects to see if I can be of help to them, and whether we’d be a good fit for each other on a project. At other times I may have a call with a friend or connection where it is unlikely that a paid project would result from it, but there may be some other insights we can both take away.
Last week I spent an hour with an old colleague and he told me about a SaaS product that he’d built almost single-handedly, which was now handling over 200k active clients. The code was written in Node.js and deployed to a single DigitalOcean virtual-machine (aka Droplet) using Dokku (an open-source Heroku clone).
Heroku is an example of a managed container/compute platform, a PaaS. The idea is that the developers can push their code to git, and a container will be built and deployed for them, with a live endpoint up shortly after that. If you have been following my work, you’ll know that OpenFaaS Cloud is very similar to this, but for Kubernetes.
My friend also had an application that was leaking memory and had to be restarted on a cron schedule. These kinds of issues are difficult to track down and we often underestimate the time it will take to find and resolve.
I agreed to speak to him, and after exchanging niceties he said: “I keep hearing you talk about Cloud Native and Kubernetes. Is Kubernetes right for us, will it fix these problems? What even is Cloud Native?”
I’m not sure that my description of Cloud Native would win any awards. For some it means hand-picking open-source projects from the CNCF Landscape, to others a 12-factor app design, or simply being packaged in Docker Containers, for others, it means running solely on products sold by AWS. In general we’re talking about applications that run well on cloud platforms, in addition: scalability, durability, and portability are often concerns.
Now before recommending a product or technology, or even answering a support question, I like to know: “What problem are you trying to solve? And what constraints do you have in place?”
He told me that the main application was deployed on a single Droplet, and that it had no fail-over mechanisms. This meant that an outage, could affect all 200k of his customers, and was going to be close to impossible to recover from.
He also had no type of monitoring or metrics, which meant the issue with the memory leak was potentially going to be hard to monitor, and if fixed, difficult to verify.
Now his constraints were that any solution must be easy to understand and that his three other developers would need to be able to operate it without spending a lot of time learning something new. It needed to use a Git-based pipeline (he already had that from Dokku) and there was also very limited budget for operations. All spend really needed to be directed to new features, to pick up more paying customers.
Does any of this sound familiar? There was a definite conflict between profitability, and stability in the platform.
My main concerns were lack of fail-over, disaster recovery and the memory leak. So what did I tell him to do? To move to Kubernetes?
I’ll let you know what I advised below, but first of all, I tweeted and that thread gained dozens and dozens of comments. The answers ranged from “Yes Kubernetes”, to “just use Heroku”, to “just use Fargate” to myriad of other “just use X” comments.
These kind of “just use X” comments don’t tend to appreciate the problem being solved, or the constraints. Now there was a second wave of comments that felt much more insightful to me: “tell your friend that he needs to invest in operations” — “there’s a lack of DevOps knowledge, at some point you need to hire someone to manage this”, “sell him OpenFaaS”, and even “why doesn’t he contract you to run this for him?”
As much as I espouse and evangelise, and build tools for making Kubernetes easier to operate, I’m not here to give a hard sell. As you know from earlier, I’ve written a blog post showing that it’s not the only option. The learning curve for Kubernetes is just unfair, when you’re coming at it from scratch, here’s a little sample of what you need:
As was pointed out by the second wave of comments, he needed to invest in operations. A skilled DevOps engineer would have already taken the lowest-hanging fruits to secure the 200k users.
For the memory leak, and lack of monitoring, they would have found out that Dokku supports Prometheus metrics via an add-on, they would have enabled it and installed a dashboard to monitor the situation. The information gleaned, would be passed to the developers. They may also have added code to restart the poorly performing service at regular internals.
For the lack of durability, the first port of call would have been to take regular VM backups. After that, they may have deployed a second Dokku droplet for load-balancing, maybe even three of them, so that the traffic could be spread.
Then they may have stopped there, and monitored the situation. Perhaps they would evaluate a longer-term vision for the infrastructure like using Heroku or Google Cloud Run. They would go back to the problem being solved, reevaluate the constraints, and apply their experience and problem solving skills.
If the term “Cloud Native” is confusing to you, if asking “Is Kubernetes is right for us” fills you with imposter syndrome, and if you’re worried about your legacy IT investment, then I hope you found something of value in this post.
For my friend, it seems that investing in operations would be of benefit to him and his business, and as developers we may get blindsided building an effective architecture in code, but lacking in our infrastructure. We may also be under external pressures to move faster and we don’t have to bear the full weight on our own shoulders.
There are many independent, certified vendors who can provide hands-on expertise, guidance and reassurance for your IT strategy. My advice is for you to have a vision for what you’d like to achieve, but to give yourself permission to make that journey over several years if needs be. After having managed everything internally, with your own skills, maybe it’s time to speak to someone external who can answer questions, and help you map out a path?
Are you looking for some guidance, or an external view with one of your projects? Send me an email, or book some time to talk
If you liked this post, then you can get more today. Parts of this discussion were originally published in my weekly Insiders Update emails. Subscribe to follow my OSS work and to learn about Cloud Native projects, Raspberry Pi, and Kubernetes.
You may also like my recent interview on the Kubernetes Podcast by Google on Independent Open Source. You’ll hear about my early career, how I came to create OpenFaaS and go on to form an independent business.