I recently met with a potential client who needed assistance with Kubernetes. Each business unit or business in the group had been making its own decisions on what they wanted to do about the company’s Kubernetes environments. These options ranged from where to run Kubernetes, which flavor to run, how it’s built and security considerations, just to name a few. This isn’t a new problem, though.
I first came across this issue when CI/CD and DevOps first became important. Every application team would insist on their own DevOps toolchain, and everyone had an opinion on what the business can use.
Right now, we see organisations doing the same with “cloud native”: they use many different flavours of Kubernetes — sometimes up to six different versions on-premises and in the cloud. There is a major lack of skills in most organisations when it comes to the cloud, DevOps and Kubernetes, and thinning out your teams only creates more problems.
This means you are spending money on each of these tools and not benefiting from economies of scale for any of them. It also means that you have to train different teams to specialise in different tools. Instead of training everyone on one or two platforms or tools, you now have smaller teams with skills in multiple tools, thinning out your skills pool.
This is bad for everyone. Business suffers because application teams need to manage platforms and tools, instead of writing code. Application teams are not effective as they are managing tools and waiting on IT to deliver resources. Then IT suffers because they are in the middle, wanting to optimise, innovate and grow, but are struggling to keep up with a torrent of requests for support on platforms they don’t manage and or have limited skills in.
If we consider this skills shortage, we need to allow for the largest output with the lowest staff count.
That is where standardisation comes in. We need to do the same for Kubernetes.
Make sure you have done your due diligence, speak to people who have done it before and decide on a company standard.
- Do your research on Kubernetes platforms and look at which vendors you work with already. Is there good overlap?
- Find options that cover your needs now, and in the future.
- Do they provide a secure platform? Supported and secure operating systems? Base images for containers?
- Do they have integration with your existing development tools?
- Does it allow for good observability, so you can monitor your entire IT estate?
- Do they have data integration options or are the ones you are looking at supported?
- Do your existing applications support the platform and operating systems?
Once you have spoken to experts *cough*, done your due diligence and decided on the best way forward, you can start to plan.
Replacing tools won’t work, you need a good plan of action. People do not like change, and you need to make sure that you make the switch very easy. Application teams must write code and commit; with the magic of automation, you take care of the rest. The onboarding process must be easy. Documentation must be ready and easy to consume and follow. Then you automate, providing resources to the app teams.
With financial pressure on every business right now and major KPIs around cost-saving, standardisation will save money in the short and long term. It will create better-equipped IT departments. Teams will be happier when dealing with IT departments. And skills will be shared across a larger group, de-risking the businesses and removing single-person dependencies.
Personally, I enjoy working with companies and helping them streamline, grow and maximise what their systems and people can achieve. Please feel free to reach out on LinkedIn or e-mail me at deon@lsdopen.io.
About LSD
LSD was founded in 2001 and wants to inspire the world by embracing OPEN philosophy and technology. LSD is your cloud-native acceleration partner that provides managed platforms, leveraging a foundation of containerisation, Kubernetes and open-source technologies. We deliver modern platforms for modern applications. For more, visit www.lsdopen.io, e-mail info@lsdopen.io or visit us on LinkedIn, Twitter, Facebook, Instagram, YouTube or GitHub.
- The author, Deon Stroebel, is head of solutions at LSD
- This promoted content was paid for by the party concerned