Do I really need Kubernetes?
If you follow tech news, Kubernetes seems to be everywhere. It has become very popular. In fact, without Kubernetes, developers and DevOps teams may feel that their application development pipelines are outdated.
Kubernetes is an orchestration tool for containerized applications. Starting with Docker containers, Kubernetes can control resource allocation and traffic management for cloud applications and microservices.
In this way, Kubernetes simplifies many aspects of service-oriented application infrastructure. In addition to continuous integration and continuous deployment (CI/CD), Kubernetes provides the infrastructure to scale these applications without a lot of work.
There is a lot of excitement about using Kubernetes to manage cloud and hybrid cloud environments. But many teams often chase hot spots and migrate to Kubernetes prematurely, often resulting in a lot of wasted time, money, and developer frustration.
In this article, we'll try and help you answer the following questions: Do I really need Kubernetes?
【Do I really need Kubernetes】Kubernetes do?
Kubernetes is an orchestration tool for containerized applications. It is responsible for:
•Deploy images and containers
•Manage container and cluster scaling
•Resource management for containers and clusters
•Service traffic management
Kubernetes does bring a lot of benefits when your application consists of multiple services running in different containers. For monolithic apps with static user bases, this may be more than necessary.
The tasks of building, testing and delivering applications to container repositories are not part of Kubernetes, these use CI/CD tools to get the job done. In addition to CI/CD pipelines, Kubernetes can help you deploy applications into production without service downtime.
【Do I really need Kubernetes】Improve monolithic applications
Most applications start out as a monolith -- having the entire application in one place where changes can be made and deployed quickly and easily. However, if your application grows, you need to find a way to scale quickly.
Does this mean it's time for Kubernetes? maybe not.
Often, extensions are more about the internals of the application than high-level architecture and tooling. For example, you can scale the ensemble by deploying multiple instances with a load balancer that supports affinity tags.
The first step to consider when scaling an application is Test Driven Development (TDD), which ensures software quality and prevents problems as the application grows. Although smaller modules or services are easier to test, modularity also means an increased need for mocking and additional tooling for configuration and maintenance. Good testing allows you to build and scale applications with ease and confidence.
Configuration management tools like Chef and Ansible come in handy when you start scaling the monolith . You can use them to automatically configure new servers to ensure they are ready to run your application. You can even go a step further and use a tool like Terraform to help provision new server VMs so you don't have to create them manually.
You can also scale other parts of the application when they become the bottleneck (such as the database). For example, if the database becomes the bottleneck, frequently accessed data can be moved to a high-performance in-memory data store such as Redis to reduce the load on the database.
No matter which configuration management and configuration tool you use, a good CI/CD pipeline is a must. You may have copied the zip file to the server via FTP the first time you deployed your application, but this approach doesn't scale. Simplified CI/CD pipelines ensure that your applications are automatically built, tested and deployed without any additional work from you or your team.
You can even use cloud services like AWS Elastic Beanstalk, Google App Engine or Azure App Service to automatically scale your monolithic application. All of these bring less administrative overhead compared to Kubernetes, and they all work well with CI/CD tools.
When developing a new app, focus on developing the best app possible. Sophisticated tools like Kubernetes may be the right solution for managing application infrastructure.
【Do I really need Kubernetes】Enhanced Monolithic Applications
As your application grows, you may eventually be unable to keep adding functionality to the monolith. This is usually because the application is nearing the limit of what a single development team can do.
At this point, many teams choose to split the monolith and migrate entirely to microservices. While this is a welcome decision, it is neither a required decision nor a panacea. Organizations, consider starting by adding functional services to the monolith rather than replacing the monolith as a whole. Some of these supporting services may actually be microservices - so you can benefit from using small services where it makes sense, while still taking advantage of the benefits of a monolith.
Even with the introduction of microservices, you probably don't need or want to start with Kubernetes. Kubernetes excels at running and scaling Pods of related services and microservice containers. However, some aspects of Kubernetes adoption are easily overlooked, for example, Kubernetes does not have robust built-in tools for securing Pods, nodes, and clusters, and deploying Kubernetes clusters in a multi-cloud environment adds a lot of complexity.
Starting with a single cloud platform like Azure Service Fabric and AWS Fargate makes it easier to start and scale services without forcing you to manage Kubernetes clusters.
Another option is to avoid services with maintenance overhead altogether and opt for Functions as a Service ( FaaS ) such as AWS Lambda or Azure Functions. FaaS is a great way to minimize potential infrastructure overhead when adding services to an application. Additionally, if you eventually need a cluster orchestrated with Kubernetes, you can enhance it with FaaS capabilities.
No more monolithic applications
Now imagine that your monolith has grown so fast that you can't take the monolith approach and start moving to a microservices architecture.
Slowly, you have a wide variety of services, many of which need to communicate with each other. You need to ensure that interdependent services are always up and visible to each other.
Also, you sometimes need to consider running across multiple Availability Zones (possibly even across multiple cloud providers).
At this point, you may need an orchestrator like Kubernetes. It allows you to easily define modules (Pods) of related services, and can automatically scale application instances and load balance between services.
For Kubernetes to work, organizations need to:
•Operate several or dozens of virtual machines
•Allocate personnel for Kubernetes-specific configuration and maintenance
•Automate deployment of most of the same services
•Cloud (or hosting) provider agnostic
Additionally, Kubernetes has built-in support for high availability (Amazon RDS Multi-AZ) deployments, which makes it easier to improve the reliability and availability of applications.
Of course, this does come with overhead: it takes time and engineering resources to create and manage clusters, define pods, and create containerized applications suitable for deployment to Kubernetes. However, if your application is large enough to benefit from Kubernetes, the management overhead is worth it.
Kubernetes is powerful, but that doesn't mean it's the right choice for every team and every application. Like any technology, it can solve certain problems. If you don't have the problem that Kubernetes is trying to solve, you're in a lot of trouble.
First, it is recommended to use simple and available tools to quickly publish applications. When your application reaches the point where its deployment and scaling becomes part of its own operations, it becomes necessary to start thinking about orchestration, and Kubernetes as an orchestration tool comes naturally.
Copyright statement: The content of this article is contributed by Alibaba Cloud's real-name registered users. The copyright belongs to the original author. The Alibaba Cloud developer community does not own the copyright and does not assume the corresponding legal responsibility. For specific rules, please refer to the " Alibaba Cloud Developer Community User Service Agreement " and " Alibaba Cloud Developer Community Intellectual Property Protection Guidelines ". If you find any content suspected of plagiarism in this community, fill out the infringement complaint form to report it. Once verified, this community will delete the allegedly infringing content immediately.
Knowledge Base Team
Knowledge Base Team
Knowledge Base Team
Knowledge Base Team
Explore More Special Offers
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00