Do you know who can create the biggest challenges?….engineers!
Not to be a traitor to my kind but we can occasionally get quite hung up on using the latest toys on the market and as a result intentionally find ways to use them within our environments.
Now, there are two perfectly acceptable reasons for this. Firstly, we want to make the life of all the users and developers as easy as possible because well, we’re just nice guys, and secondly, we like to keep abreast of what’s happening in the market. After all, that makes us more useful to the organisation.
The problem is that, very rarely of course, we don’t see the larger organisational picture and can come across as slightly blinkered in our selection of toolset/platforms etc. As such, any suggestions that we engineers make will need to be analysed by those better placed to make a considered choice i.e. those with exposure to all aspects of the business, from finance to customer experience.
Let’s take Kubernetes as an example. This platform (?) is the market leader in container orchestration and is the ‘Travis Scott’ of the DevOps world at the moment but the question no one seems to be asking is “do we really need this?”. One important aspect is fully understanding….
What was Kubernetes designed for?
Asking this question doesn’t mean you’re going to be laughed at during a standup. In fact, I’d hazard a guess there’s a number of engineers in every organisation who don’t have a clue what Kubernetes really does, and knowing the answer to this question will guide you in making the correct choice.
Kubernetes was designed by Google to run their container workloads at scale. Massive scale. Gmail scale. It has evolved over time from an in-house product to being open sourced and is now supported by the community as well as having a number of companies that offer paid-for support (which is well worth bearing in mind).
Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service from AWS, delivering the tight integration with other AWS services, while maintaining workload portability to other Kubernetes platforms.
There are numerous benefits that come with Kubernetes. Self-healing, auto-scaling, zero downtime deployments, service replication to name a few. It’s a great tool, but a principle that we at Airwalk hold key to all our engagements is — make the client aware of all the choices that are available. So, let’s talk more about whether you should use it.
When you SHOULD choose it
1) You’re already running lightweight containerised applications — If you’re currently running an ecosystem of lightweight, separate, containerised apps then you’ll be doing what it’s meant for.
2) You are looking to speed up your deployment process — Kubernetes is designed to allow consumers to release quickly and safely with rollback features and traffic routing to control versioned releases.
3) You may want to be platform agnostic — The portability of Kubernetes is one of its strengths, so if you intend to move your containers then shifting to Kubernetes will facilitate that. At the time of writing it’s available on both Linux and Windows as well as being available on the major cloud providers in a number of flavours.
4) You’re looking to give more time to devs — Using Kubernetes to remove the need for devs to worry about capacity management, reliability etc… will give them more time to put into development.
5) You’re looking to get/provide cheaper infrastructure costs at scale — The automatic scaling of Kubernetes can reduce the amount and length of time you’ll need your infrastructure and so allows you to pass on the cost savings to your customers. It does require some effort to get a decent costing model set up but once it’s in place the enormous number of metrics available can provide you with accurate, visible cross-charging.
So, when is it best not move to Kubernetes…?
1) Moving a monolith — If your apps are currently tightly coupled and aren’t either micro-services or ready to be divided into micro-services then it’s advisable to do that part first. If you are undertaking any major re-factoring then you may want to consider an AWS Serverless model, missing out the containerised step and leaving you no servers to manage.
2) Slow development process — Speeding up your development and deployment process is a fundamental reason for moving to Kubernetes and this is best achieved by having both a performant deployment process and a well organised code repository. If you’re still doing large scale, multi change deployments then it will prove difficult to harness a lot of the useful features that Kubernetes brings.
3) Lacking in expertise — It’s well known that Kubernetes has a very steep learning curve and if you’re planning on building a production platform it’s essential that you have a number of onsite SMEs. Firstly, to run the platform but also to pass the knowledge around to the rest of your staff. Going in blind will take a great deal of time out of your current engineering timetable. The time, effort and energy that will get sunk into your organisation learning, training, developing and making a whole lot of mistakes (as well as getting your butt handed to you by cyber security) probably isn’t what you need.
4) You don’t have the footprint — This is mainly for on-premise housing but having the infrastructure space available is a major factor to consider. If you’re migrating to Kubernetes then it’s highly likely that you’re going to need a footprint that’s equivalent to your current running environment to move into. This can be expensive but shouldn’t stop you from experimenting. Kubernetes, if configured correctly, could outperform a cloud counterpart when run on bare metal but you’ll lose the infinite elasticity and so undoubtedly end up with an infrastructure that is under-used at points and can be seen as wasted money.
You may not be losing without it
A key part to this has less to do with the technical aspects but more around the culture, mentality and practice changes that need to be undertaken when making any large-scale change. We’ve recently helped companies that have pushed to “keep up with the Joneses” by leaping into the cloud when numerous parts of the business weren’t mature enough to make the move.
If you’re not running at the scale that would reap the benefits or you don’t have the cultural requirements, then there are a number of other options that will suit. Running containers “as is” in a managed service such as AWS Fargate or AWS ECS or Google Compute Engine can give you a perfectly functional and scalable method without the administrative headache of Kubernetes. There are a number of other methods to run practical, secure, scalable, containerised applications and there’s nothing wrong with doing it. Providing it will suit your business needs better, which is key, ensure you get your analysis completed upfront and rigorously. There will probably be kick back from your engineers about not being able to play with the latest toys and, as mentioned earlier, they’ll find a bundle of reasons why they need it, but look at all the options first and make a decision based on what fits best for the company as a whole (skill sets, organ structures, costs etc) and not just what your engineers want!! Be strong!
To clarify, we’re certainly not saying that you should discount Kubernetes outright, only that you are absolutely sure you know why you’re using it. It shouldn’t just be so that your engineers get to put it on their CV’s! .
One last thought though…
What will it cost you?
Kubernetes is designed to run at scale so you should be looking to maximise the usage of your cluster in order to get the best possible value for money. It’s possible to run a small cluster and have a small number of apps on it but the return on investment with Kubernetes comes in the form of getting 100s if not 1,000s of nodes running to spread the cost across your customers. Once at that scale your infrastructure costs could be optimal, but don’t ignore workload segmentation as a factor.
It’s possibly a controversial viewpoint, but Kubernetes (and EKS) is hardly ever the first answer for most Enterprise Applications – the costs of adoption are steep and the benefits are gained by managing massive scale and complexity, so validate your decisions up front as you could be paying down the debt for years to come. Consider AWS Fargate/ECS or AWS Serverless before you commit to EKS, you’ll then fully understand the complexity that you are taking on.
Conversely, if you’re only running a small number of apps then it’s unlikely to give you a true return of value against the infrastructure costs so you might be better suited to offer another business unit the option of being a tenant on the cluster…
On that note, it’s worth taking a very broad look across your organisation to see which other departments will benefit from such a move. Providing the platform that can ease the workload of devs elsewhere may get you funny looks at the water cooler but when the future costings filter up the food chain and you’re receiving the praise (yeah like engineers get praise…!) then it won’t make too much difference.
Airwalk Reply offers Kubernetes consulting services, contact us for more information.
