Kubernetes Consulting

Kubernetes is brilliantly designed. It provides an easy-to-use interface to begin with, allowing one to quickly deploy an application in a reliable and scalable way. But at the same time, it provides some advanced functionality, for those who dare to dig deep and configure Kubernetes to exactly match their needs. Kubernetes consulting, for one, includes assisting in creating a Kubernetes Operator, that allows integrating application logic into Kubernetes API, and manage events based on custom logic

Kubernetes perfectly fits for new-fashioned applications - stateless micro services, serverless, and cloud native applications, but it might bring more harm than good for old-fashioned legacy applications. Kubernetes does not favor sacred cows, which state is of great importance. Instead, it prefers to operate a fleet of temporary, interchangeable microservices. As a result, deployment of a monolithic application might be longer and more complicated than deployment to a simple server, bring literally no advantages, making the whole effort of moving to Kubernetes, meaningless.

The migration to Kubernetes has the same patterns, and can be classified the same way as cloud migration. Each strategy has its own timelines, amount of effort, and the required expertise of the team. For example, the lift and shift method is the fastest and easiest way to go to leverage Kubernetes. In some cases, a month might be enough to migrate this way. IT does not require extensive knowledge of Kubernetes and can usually be done by in-house employees. On the other hand, it does not allow one to leverage all the benefits of Kubernetes and will cause certain issues and blockers in the future. On the contrary, lift, tinker, and shift method is more expensive than the first one, requires extensive expertise, and longer timelines (at least 3-5 months), but brings significant profit in the long run, as it improves the delivery and development velocity. 

Infrastructure has to at a minimum cover the following aspects: deployment, backups, disaster recovery, internal routing, security, and scaling. At Alpacked, we usually solve this by leveraging Helm for configuration management and deployments (as part of larger setups like ArgoCD), Istio for security and internal routing, Cloud-specific tools for backups and scaling, Kubernetes Autoscaler for both internal and external scaling (pods and nodes), and both Kubernetes and Cloud-specific tools for disaster recovery

It’s impossible to utilize Kubernetes at full scale without the thoughtful work of a dev team. Team leads and architects have to understand the main concepts, architecture, and extension points of Kubernetes to efficiently utilize it other than an old-fashioned hosting platform. Putting aside a requirement for real-world experience, they have to understand the underlying processes, like scheduling, mutations, and validations. Developers have to properly estimate the usage and performance of their applications in order to have reliable and efficient scaling. They have to get used to debug, search and troubleshoot Kubernetes processes, as well as proper ways of handling stateful applications and storage management.

Throughout the countless projects we’ve been through, we identified the main pitfalls and stopping points that are common to all the projects regardless of the application architecture and business requirements. This is a paradox, but usually, the main problem consists of both under-utilization of Kubernetes capabilities and a full-scale belief in its borderless functionality. Kubernetes is a powerful tool and it has to be properly used to get the maximum out of it, and at the same time, it is just a tool and not a panacea. 

Another pitfall that we’ve been constantly facing is a problem in a paradigm shift. After long years of classic hosting using forever-living servers, engineers got used to the fact they can log in to a server, search through it, check the logs, add debuggers and modify a code in-place to find a problem or get visibility of a process. This is completely different in Kubernetes world, where everything is ephemeral, everything is temporary. Logs have to be shipped to a persistent storage, code is immutable, and there’s no statefulness by default. In order to work with it, it is necessary to completely change the approach and adapt to new realities.