Kubernetes is an open-source system released by Google in 2014 to automate the deployment, scaling, and management of applications, and is present in the infrastructure of 90% of Fortune 500 companies. Its adoption speed was driven by the need to develop and manage applications more efficiently and by digital transformation and application portfolio modernization initiatives in companies.

However, Kubernetes is not a simple technology to use or operate; on the contrary, it is quite complex. This does not diminish its value, as its complexity is linked to the fact that it touches many parts of the infrastructure and application management process. These aspects are exactly where the benefits lie, since Kubernetes, when well-configured and used with the correct strategy, eliminates the "toll" of managing infrastructure and applications from your daily routine. At Getup we call this invisible infrastructure.

If you are a CTO/CIO undergoing innovation or digital transformation and thinking about moving your applications to Kubernetes, this is a guide designed to help you increase your chances of success.

Why are you adopting Kubernetes?

Using Kubernetes has ceased to be a question of "If" and has become one of "When". The use of Kubernetes, configured correctly, can have a huge impact on organizations. The platform provides an environment ready to meet the dynamism of modern software development.

Ideally, the decision to change any technology platform (for lack of a better term) should be made considering two points: 1. Whether we have the necessary prerequisites to 2. Reap the benefits generated by the change.

That said, the main prerequisites for a successful journey with Kubernetes involve:

1. Are your applications "compatible"? (here we have an article covering this topic). You can run that Java monolith on Kubernetes and get some benefits, that is true. However, the greatest benefits are only available for applications with microservices architecture, that are stateless, and capable of scaling horizontally…

2. 
   

   
   

3. Tools and processes for automated deployment. Kubernetes offers a perfect environment for gaining productivity and resource sharing, both in development and operation. Your developers can deploy applications manually, but the experience will be compromised. Your developers will likely hate Kubernetes given the complexity they will have to deal with, going against the main objective here: more productive developers. Consider investing time in CI/CD (Continuous Integration and Continuous Delivery), GitOps, GitLab, as well as reviewing your processes to enable an application to reach production automatically.

4. 
   

   
   

5. Will Kubernetes actually improve delivery speed / my customers' experience / or provide another benefit? Many companies are delivering software with great speed using Kubernetes, that is true, but it is still valid to ask whether this will be your case. Many factors can contribute to slowing down this process of evolution and efficiency gain, so before proceeding with the reading and exploring what they are, I will rephrase the question: will improving your delivery speed actually improve your business? Kubernetes is the answer if you are using microservices, need to scale horizontally to respond to seasonal demands and peaks, or for fast development cycles to validate hypotheses of a new product. If this is not your scenario, you probably do not need Kubernetes.

Does your infrastructure have the necessary attributes to run Kubernetes?

Starting Kubernetes on the right foot involves having a good foundation, and the infrastructure where it will run is an important piece.

Being able to provision machines, network, storage, DNS, and load balancers automatically, compiled in versions (IaC), and with those resources accessible via API is essential to achieving the experience and speed your company needs.

If you are spinning up Kubernetes in the cloud, which is highly recommended, these capabilities are already in place. However, you need to leverage them through modern ways to ensure agility and efficiency. Use IaC tools, like Terraform for example, to not only have visibility over your infrastructure but also simplify audit processes, share the "recipes" of this infrastructure, and even create Disaster Recovery plans.

If you are on-premise and do not have the mentioned capabilities installed and stable, running and maintaining Kubernetes will be challenging for your team.

Do you have the necessary time to manage Kubernetes?

Even if you choose a managed Kubernetes (highly recommended), such as Google GKE, AWS EKS, or Azure AKS, your team will still need to invest a significant amount of time maintaining your clusters.

A managed Kubernetes makes it easier to start and follow the accelerated update cycle for new versions. However, the activities involved in keeping or managing environments in production go far beyond the features offered by the "managed" service. Activities that will be under your team's management:

• Have a plan for updates. Although managed Kubernetes makes new versions and patches available, your team will still have to apply them to the environments, and this procedure can impact the availability of some applications. Certain updates even impact the deprecation or alteration of Kubernetes components which, in an eventual update, will also involve the development team. Updating Kubernetes goes beyond Kubernetes; applications may become unavailable during the process due to not following certain Cloud Native best practices, such as number of replicas or even the use of basic Kubernetes components like P.D.B.

• 
  

  
  

• Monitoring for Kubernetes and applications. Monitoring in Kubernetes, or any distributed system, tends to be more complex because it requires a strategy that goes beyond the 4 Golden Signals. You need to think about observability, how you will collect application metrics and where you will plug them in, whether in a proprietary or open-source solution. We have several options available such as Loki, Prometheus, Grafana, NewRelic, Datadog, Sysdig, OpenTelemetry. Finding the best one for your scenario, and taking care of their compatibility and integration, will demand considerable time and expertise. It is worth checking out our observability marathon in podcast format.

• 
  

  
  

• Security approach. Security in Kubernetes or Cloud-Native environments requires a specific approach given the dynamism and speed of changes. Delivery speed or multiple deployments mean you have different versions going to production, which may contain flaws that were not present in the previous version. You can set up a decentralized operation, known as "You Build It You Run It", giving teams more autonomy, but your security baseline or best practices can be lost over time. It is worth investing time thinking and defining a set of rules, how developers will access the environments, and what the usage policies are: where images can come from, security scanning, from the code through to the images in the repository, as well as at run time (runtime). Lastly, make use of admission controllers to force that best practices are being followed, and if possible have a tool that alerts if they are not.

• 
  

  
  

• Availability (backup). It may seem obvious, after all, availability is important in any scenario, but with Kubernetes we deal with something called density. It is common to have a high concentration of applications or microservices in a single Kubernetes cluster, so losing a single environment can have a significant impact on your operation. Your team will need to think of an architecture (both for Kubernetes and applications) capable of withstanding infrastructure losses, as well as a backup strategy capable of restoring anything from a namespace up to an entire cluster. A good tool for backing up Kubernetes environments is Velero.

Do you have the necessary time for your team to gain sufficient experience to manage environments in production?

To significantly reap the benefits of Kubernetes, you will need time and investment in training to raise the bar for everyone on the development and operations teams. Here, planning, a long-term vision, and support are essential to transform technology into results.

Remember, meaningful transformations take time. AWS invested a good amount of time and involved over 100 teams to replace Oracle databases, while Netflix took 7 years to migrate its applications to the cloud.

A certain anxiety to make changes is understandable and even positive, especially when it comes to getting rid of legacy applications. So here is a curiosity that might make you feel better: know that in Japan, 1900 government procedures still require the use of floppy disks. Even if outside the Kubernetes topic, the anecdote is valid.

How will you deploy the applications?

Not only does Kubernetes management need to be automated (Terraform). How you deploy applications will have a direct effect on whether or not you get the expected benefits. You can opt for manual deployment, but the experience will be far from what you imagined, in addition to being extremely difficult for developers, which usually results in adoption failures or shadow IT. Have the use of continuous delivery or, better yet, continuous deployment in your plan. Take a look at Gitlab, Azure Devops and Gitops tools like Flux, ArgoCD, GitlabCI, Github Actions.

Is managing Kubernetes a differentiator?

This is a strategic question, after all, managing Kubernetes can consume a lot of energy from the teams. Keeping environments updated, having a plan for continuous improvement of the infrastructure, security, training, dissemination of knowledge, and turnover will be constant items on the agenda.

You can look at Kubernetes in the same way we look at datacenter infrastructure (on-premise) where, in most segments, it no longer makes any sense to have, because today we have something much more aligned with companies' needs: Cloud Computing.

Want to advance on this journey? Speak with a Kubernetes specialist.