Technology is becoming fascinating each day and the hype growing around concepts like container orchestration tools (e.g Kubernetes ☸️) keeps growing 📈. On one hand, these technologies are indeed amazing and companies are using them to better meet the needs of their users.
However, because of the hype around these technologies, a lot of companies both new and old are beginning to over-engineer their solutions, increasing the complexity of their products and focusing on how they have implemented these technologies instead of meeting the basic needs of their users 🤧 which can be done with simpler solutions.
This scenario can be likened to using an 🪓 axe to kill an 🐜 ant, which is totally not necessary. You can just step on it with your feet😂 (p.s. Don't kill ants, save the planet🌚)
This over-engineering can cause organizations to loose a lot of money, it can even deviate their attention from building solutions to setting up systems and overall, it will needlessly increase the complexity of the project.
One of such concepts that is continually being used recently to over-engineer solutions is container orchestration😕. In this article, we would look at what container orchestration is, and a brief history of how it came about🕰️. Then, we will then look at the benefits of using a container orchestration system, and finally when it can become an overkill.
What is Container Orchestration☸️?
Container orchestration automates the provisioning, deployment, networking, scaling, availability, and lifecycle management of containers. Some popular container orchestration tools are: Apache Mesos, Docker Swarm, and Kubernetes.
Application development in recent times has moved from a monolithic approach 💧 to using microservice 💦. Microservices are individual units of software that provide all of the functions required to run an application when combined together. Typically, each microservice handles a discrete type of functionality. An application can have separate services for image recognition🔴, authentication🟡, database🔵 and the UI⚪. Each of these would communicate using lightweight mechanisms like HTTP resource APIs to be interfaced as one application 🔴🟡🔵⚪.
Using containers📦, the architectural paradigm of using microservices can easily be implemented. Containers can be used to host the individual microservices that form an application. This means that a containerized application can translate into operating hundreds or thousands of containers, especially when building and operating large scale systems.
The complexity of this application increases if these containers are to be managed manually. However, with container orchestration, the complexity of managing containers is reduced as orchestration provides a declarative way of automating most of the work 🔁.
Benefits of Orchestration
Security:🔒 Container orchestration automated approach can help reduce the chance of human error, hence, keeping containerized applications secure. Also, because containers run in isolated environments, container orchestration tools can share only specific resources between users, reducing the risk of data breaches and other traditional security vulnerabilities.
Improved development:🏂 Orchestration allows teams to easily roll out and roll back versions or features with ease. This makes user needs to be met faster as the process of developement, testing, and delivering of software has become faster, repeatable and more efficient.
Cost Saving:💰 Container orchestration systems require less human effort enabling companies to save money by requiring less staff to build and manage systems. Also, orchestration systems maintains optimal usage of processing and memory resources, removing unnecessary overhead expenses.
When is Orchestration an Overkill?
overkill ( noun )
meaning: excessive use, treatment, or action.
example: "animators now face a dilemma of technology overkill"
For Small Startups 🤏
Setting up a container orchestration system might be too complex🤹♀️ and time-consuming⏱️ for these kind of teams. Setting up orchestration systems is a major project that might end up disrupting existing workflows.
For example, in the case of Kubernetes, worker nodes need to be configured with memory, disk speed, storage capacity and much more. Also, you would need to set up access control management and security for the kubernetes clusters and also configure the control plane. After completing the steps for setting up the kubernetes environment, they need to be regularly managed, maintained and monitored. This increases the complexity of the project and might deviate the team to concentrate on managing infrastructure instead of solving user problems.
Having Minimal Scalability Needs ⚖️
Orchestration might introduce unnecessary overhead for applications which have consistently low traffic or whose resource demands are predictable. When using orchestration tools for applications with low or predictable traffic, overheads can be incurred in terms of architectural decision and design when taking scalability into account.
Also, a part of the scalability planning phase is capacity planning which involves gathering data, performing calculations and making projections based on the data. The scalability of the system would then need to be tested and validated by building test setups, generating data for the test and performing analysis on the test results.
All of these steps would just end up lengthening the development time planning for scales that would not be met in a very long run.
Cost 💸
Container orchestration systems require more infrastructure, including servers, storage and networking. There is also additional cost incurred in managing and maintenance of these systems which includes time and resources needed to train the team and also salaries of skilled employees.
Although Kubernetes provides a way to ensure reliability and scalability of applications, it doesn't explicitly provide a way to measure and manage cost. Because of the dynamic nature of containers in the kubernetes environment it can become more complex to implement cost optimization as understanding the interplay between various components, configurations, and resource utilization patterns is needed.
Also, kubernetes operates at the infrastructure level making allocating cost to specific applications or workloads even more complex. Organisations would need to setup 3rd party applications in order to accomplish this.
Lastly, using a managed Kubernetes service such as Amazon's EKS, Azure Kubernetes Service or Google's Kubernetes Engin can come with with additional cost such as cluster management fees, control plane charges and other fees depending on the services provided by the cloud provider. These services are not really necessary for simple solutions like; a single-page application which has a database and cache. This types of applications can simply be deployed on a VPS. Container orchestration is best suited for applications running multiple microservices that need to communicate with one another.
Conclusion
As we have seen, there are benefits to using a container orchestration system. However, before deciding to use one, carefully consider if it is absolutely necessary. Do you really need it, or would it just be adding needless complexity and cost to your current workflow? Perhaps you can make you of a simpler solution.
Always remember that whatever you build is to satisfy the user first before considering how amazing you might feel from using popular tools 😂. I wish you the best in your development journey ❤️
Additional Resources
- Benefits of Container Orchestration
- Overview of Microservices
- Kubernetes Isn't Always the Right Choice
Thank you for reading through till the end😊. I hope it helped you in one way or the other to understand and use a particular concept. If you enjoyed reading this, do leave a like ❤️ and a comment stating how I can improve 💡
Top comments (0)