Common Assumptions to Avoid When Starting with Kubernetes
This article originally appeared on Forbes.
As businesses increasingly realize that they are technology companies that happen to make a product or service, the line of business (LOB) often becomes more involved in technology processes. A natural evolution of this is that the LOB will look to find ways to help a development team deploy and scale faster, bringing solutions to market as quickly and competitively as possible. Many organizations are turning to containerization to easily and efficiently achieve these goals.
With their extreme portability and lightweight nature, containers encourage agility and scalability that accelerate the development process. Clearly, they are a deployment model of the future. Yet organizations need tools to manage and maintain containers, and Kubernetes is increasingly becoming the solution of choice. Indeed, a 451 Research survey (via TechCrunch) of enterprises using containers found that 71% of respondents use the technology. Kubernetes is a powerful tool, thus making it important to start on the right foot.
To avoid unnecessary diversions on your path to success, look beyond the technology and avoid these common assumptions.
Assumption No. 1: Everyone Uses It, So How Hard Can It Be?
While Kubernetes is a widely used solution, that doesn’t mean that it’s push-button easy. Container clustering, networking and deployment automation are still difficult problems to solve. And the broader your cloud deployment, the more complex it can be.
To ensure Kubernetes success from the get-go, it is important that staff with the right skills and experience are assigned to the team as they can help expedite both strategic decisions (e.g., where, when and how to start) and tactical tasks like installation and configuration. For this reason, demand for Kubernetes skills has grown 752% over the past two years. According to research by CyberArk (via Cloud Pro), Kubernetes is among the most in-demand IT skills in terms of growth, moving up 729 places to the top 250 most required IT skills.
As a result, teams should be prepared to think about the skills they already have. Do you need to hire a new resource? Will you provide training for the existing team? How will training occur? Or, will you hire a specialist to play the role of a Kubernetes lead while providing critical knowledge transfer? These are valuable questions to ask to ensure you have the needed skills on hand as you get started.
Assumption No. 2: Kubernetes Is The End Destination
There is no platform that does everything, and Kubernetes is no exception. Rather than a destination, when you adopt Kubernetes, you are joining a journey. As I mentioned above, automating deployment, scaling, backups and more are genuinely difficult challenges. And while Kubernetes is an excellent tool, and one that we at Flux7 use regularly, it does have room for improvement.
Positively, the Kubernetes community is quite active and has many contributors working to address these shortcomings. However, it should be noted that it can take some time before solutions are added into a Kubernetes release. Although this process may sound slow, it’s not. Kubernetes is rapidly changing, and you’ll need to stay on your toes to keep up with new features and functionality. While you won’t necessarily need to adopt every new feature the minute it’s released, it is important to keep up; otherwise, you’ll quickly find yourself left behind.
Assumption No. 3: Finance Will Figure Out Cost Allocation
Kubernetes uses a shared resource model in which infrastructure resources are pooled into clusters, and lower-level computing complexity is abstracted away. While that is great for development efficiency, it is the very thing that makes accounting more difficult. With resources shared across teams and services, it becomes quite difficult for all involved (IT, LOB and finance) to ascertain which Kubernetes costs are associated with a given project or team.
Also making it difficult to align spend with resources used is the fact that Kubernetes, due to its infrastructure-agnostic nature, can appear anywhere across your cluster. If you need to split costs across projects or teams, tracking where Kubernetes runs is quite important. While this hurdle is not insurmountable (and there are workarounds like using Kubernetes Namespaces), it’s important to approach the accounting-side of Kubernetes with eyes wide open, addressing cost challenges as part of your build rather than having to go back and do the rework.
Kubernetes has many benefits. From the ability to move from test to production with a single click to load balancing and service healing, it is a powerful tool that organizations are understandably eager to adopt. However, increasing the speed of development and deployment should not be an end goal in and of itself but rather a means to achieve specific business goals. Plan for these common skill, agility and cost assumptions, and you’ll avoid the missteps of those who have gone before you, starting out on the right foot with a solid plan for success.