Kubernetes and Cloud Native are two of the hottest topics in IT at the moment. From the CIO to the development teams, people are looking at Kubernetes and application modernisation to accelerate business innovation, and reduce time to market for new products and features. But how do these get managed? Do you need to do it in-house utilising your own talent, or would the better option be to find a managed service provider to do it for you?
Cloud Native is a much broader topic than just Kubernetes, and both are extremely complex new technologies. Let’s look at Kubernetes first as the foundation and work our way to cloud native.
So many options to choose from
We’ve already covered what Kubernetes is and where comes from in an earlier blog post. Companies are modernising their applications to run in a cloud native way to provide digital services to their customers wherever they are (I won’t go into much detail of the modernisation process, but you can read up on containers and microservices in an article published here by my colleague Andrew McIver). These modernised applications are refactored to run in containers, which are typically orchestrated with Kubernetes and can feature infrastructure both on-premise and in the cloud. Kubernetes is a popular choice as the orchestrator because of what it enables, yes – but it also has to do with the fact that it is an open source project with many different distributions that cater to different preferences of the organisations that use it.
We have seen vendors pick up Kubernetes solutions with Red Hat Openshift, VMware Tanzu and SUSE Rancher, being some of the top distributions adopted globally. We also see public cloud vendors come up with their own flavours of Kubernetes with EKS from AWS, AKS from Azure and GKE or Anthos from Google. Then there are the open source projects which are also in use, like OpenShift Community Edition (OKD), Rancher and Kubernetes itself, on which all of these editions are based.
Once your organisation has decided that containers and Kubernetes are right for you, how do you get started and what is the best for the business? Do you build and manage Kubernetes yourself, or do you partner up with a service provider to manage that for you? I think we can all agree that there is no one right answer to suit everyone, and not only each company, but each business unit in a large organisation will have different requirements. In general, we can look at the pros and cons, and hopefully help you make your decision.
I speak to many companies every day about this topic, and I can completely understand why this is an important consideration. Organisations want to make sure they empower their employees, reduce costs and reduce the reliance on outsourcing.
Start with the Business Goals
Firstly, we need to understand the business strategy, objectives and goals. We want to answer a few questions, which will really help us determine the best course of action:
- What is the urgency? Do we need this platform done immediately, or can we take 12 to 18 months (unfortunately, this is typically the time it takes if you have a high-performing Linux team)
- What kind of skills do we have internally? And what is their availability like with everything else on their plates?
- Are you looking into public cloud? Do you have a timeframe in mind for including public cloud in our infrastructure? And are you going with a Hybrid- or Multi-Cloud configuration?
- Do we have good automation, DevSecOps, Infrastructure-as-Code patterns and principles in our organisation?
Once you have answers to these questions, you can start to make sense of what the best options are. I won’t go into detail for each of them, but the important considerations are around urgency and skill.
Urgency and skill
If you are looking to move fast, getting a skilled Kubernetes-focused company to assist in the deployment and management of the platform makes a lot of sense. It removes the burden and worry from the organisation and gives your team the time to learn essential cloud native skills.
There is a major skills shortage at the moment, and it is very difficult to find people with not only skills but experience managing Kubernetes. Building it usually can be done with vendor documents, but managing and supporting Kubernetes is complex, and one of the reasons we get contacted the most from companies that aren’t LSD customers yet.
Doing it yourself
Let’s look at the Benefits of the DIY approach:
- Your team will grow and learn a new technology
- You do not need to rely on outside skills to ensure business continuity
- It might be more cost-effective to use existing skills.
- Internal growth for your employees
As for drawbacks of the DIY approach, let’s consider the following:
- It can be a slow process to upskill people
- As mentioned above, there is a big gap in skills and finding people is difficult, and keeping them is even harder.
- When something goes wrong, your team is responsible for fixing it, and might not be able to just yet.
Using a Managed Service
If we look at managed services that are done correctly, they should give your business the following:
- A platform deployed faster and to the vendor’s standards.
- Bring all the skills needed for the job. Not just a certification, but actual experience having built these platforms. Too many companies get paid to learn by their clients.
- Have 24/7 support, because even if you have some skill, expecting them to work around the clock is not sustainable, and those people will leave.
- It also takes away the key person dependency that so many companies are plagued by.
- If you take the cost of time, certifications, losing talent, rehiring and more, it actually works out more economically to go the managed service route.
- Free up your internal resources to focus on what they do best, especially developers.
- Platforms deployed by partners/consulting companies must be done to open standards from the vendors and must be done in such a way that you can take it over once your team has the skill.
The drawbacks of using a managed service are:
- Your business is relying on external skills
- The perceived threat of replacement of your team can be difficult to navigate and alleviate
One of the things I feel very strongly about is that we do not want to replace people. We want to grow and empower people. The goal with a managed service should never be to replace staff, it should be to give the business the best chance of success and to get up and running fast while giving the staff the time to learn and grow. It essentially becomes another tool in their toolbox.
I want to also add that services like EKS, AKS and GKE from the hyperscalers still require a lot of management and support. The management they provide is not enough, and I include a managed service to manage those nodes too.
Hopefully, you now have a better understanding of how a managed service weighs up with doing it yourself. There are benefits and drawbacks to both methods, and how effective a method performs depends on each unique scenario.
