Goodbye K8s! It's Still a Business!
We’ve exited Kubernetes after 20 months. Here’s everything we wish we would have known about the business case we never made.
This article is part of the “Goodbye K8s” series, looking at the reasons that eventually drove us away from one of the hottest platforms on the market:
Time to Reflect
After exiting K8s and migrating to our new technology stack, we took some time to reflect on the lessons learned. Plus, collate everything we wish we would have known before jumping right into using the platform.
So, let’s start with the one thing that I personally overlooked most. That led us to diving into K8s head first and down a garden path. For which we ended up paying a hefty price. But which eventually also brought us back on track.
After all, this was — and still is — just a spare time project. And the ever-so-curious inner “techie” in me wanted to have a go at K8s. So, who needs a business case?!
The Business Case
Well, as it turns out: almost everyone and everything.
In the finite world we live in, everything is a trade between finite resources which can differ in valuation at any point in time. Amongst other things, we exchange time for money, money for services, and services for time. This naturally defines an underlying business case. And it’s not a good idea to ignore it as I did.
While costs are usually measured in monetary units, they also extend to time and missed opportunities. So, even when there is no money directly involved in carrying out an activity, there are still costs associated with it.
In our case, running a K8s cluster on GKE was “free” thanks to the generous free credits GCP handed out to new customers. However, the total costs of providing the service were staggering when including the time and missed opportunities entailed by leveraging the “free” service.
This was actually a misalignment of the solutions for achieving our objectives, especially primary and secondary ones — publishing quality content people want to read and providing hosting services for a website. Moreover, this was also a lack of an priori assessment of the impact of the objectives in the first place.
The Business You’re In
When it comes to business, it really pays to know the business you’re actually in. And then ruthlessly sticking to it unless there is a really good reason to change or pivot.
This means saying “No” to many things. Many good things. Many really good things. Many shiny things. Many things others are using and questioning why you’re not using them as well.
Remember the comment above about this being a spare time project?!
We knew we were in the “delivery of quality content people want to read” business. But even with managed K8s we suddenly found ourselves in the platform management business. Drifting further away from our core “business” objectives.
For us, the failure of assessing the impact of the choice of technology platform led to a further misalignment of our objectives. Up to an eventual reversal of them. Superimposed by the platform. Self-inflicted pain, if you want.
The Platform Selection
The choice (or dismissal) of a platform usually has a non-negligible impact on the overall performance of the business. It pays to have a broad and open view of the available choices. Note also that the choice of platform largely dictates all other subsequent technical decisions.
While it might be difficult to ignore the attractiveness of a platform, in a holistic assessment, it should just be one dimension in an n-dimensional space of metrics. Where the resulting vector then gets compressed into a binary yes/no answer.
Unless you’re rolling your own, modern platforms can broadly be categorised into Infrastructure-as-a-Service (in short IaaS), Platform-as-a-Service (in short PaaS), and Software-as-a-Service (in short SaaS).
In that order, they increasingly shift more responsibility from the consumer to the service provider while at the same time taking more control away from the consumer.
When the inherent loss of control is acceptable, the above categories also define a value chain. By increasingly outsourcing more of the undifferentiated heavy lifting to the service provider, businesses can focus on providing value added services. In that sense, and with every pun intended
Chose your aaS wisely!
We started out by using K8s, which can be regarded as an “IaaS for containers”. Eventually, we ended up leveraging AWS S3 and AWS CloudFront, which, even though they technically might be IaaS platform services, allowed us to treat them as PaaS- or almost SaaS-like specialised offerings.
This means that we are no longer running on one of the hottest platforms on the market. We’re back to boring and proven. Most likely, we won’t have long queues of people admiring our technology stack — but we now have a lot more time to write longer articles. Such as this one!
The Financials of K8s
As with any IaaS service, there is a certain amount of overhead required to provide basic services before apps can then start leveraging them. K8s is no exception.
Every cluster comes with a minimum footprint. The more additional services that are required in a cluster, the bigger the footprint. For us, the minimum footprint for running a simple Ghost blog server ended up being three machine for around £5 per day which just isn’t economical by any standards.
However, there’s a decent chance that our use case of running a single installation in isolation is also part of the problem and not doing K8s any justice. The platform is extremely well suited for the economy of scale.
This means running multiple apps — and thus containers — in the same cluster, squeezing as many compute tasks on the available machines as possible (within the predefined virtual CPU requirements, if stated). This leaves K8s well positioned for horizontal scaling.
In general, we find it hard to justify the expense for running a single app in a cluster unless there are hard requirements.
The Technical Lessons Learned
The next article in this series sums up the technical lessons we’ve learned from running K8s in production for 20 months. From creating clusters to managing containerised apps.
While there’s a decent chance not all of our lessons might be applicable to other areas, there’s enough opportunity to avoid re-learning them. No need to repeat our mistakes!
Subscribe to How Hard Can It Be?!
Get the latest posts by following us on LinkedIn and Twitter
