Containerization is a software deployment model to package your application code, its dependencies, configurations as a self-contained modular package to make it run on any infrastructure, be it your development laptop or in cloud infrastructure. This is a shift from traditional deployment model where you used to install the dependencies in advance before your application gets deployed. Now a days with containerization software developer’s don’t have to worry about the infrastructure installations during deployment time. Instead they could figure out all dependencies during application development itself, add a docker file to containerize it and hand over to any platforms which has container runtime. Typically an enterprise application consists of many modular containerized applications connected to each other through network (Rest API / gRPC) or through some form of cloud -native integrations. To manage or orchestrate multiple containers , enterprises use an orchestrator like Kubernetes or Cloud Kubernetes version like Amazon Elastic Kubernetes service or Amazon Container Service.
Once an application has been containerized, developers use different forms of containerization technologies to test and deploy it. On the local development system they could use either Docker Desktop / Podman / Rancher to test and run it. For applications that require scale and using kubernetes , MiniKube provides a local development setup for simulate Kubenenetes running on a single cluster on a local system.
Containerization use cases
The Cloud Native Foundation has standardized the implementations using OCI image specification standards and many container runtime vendors are already adopted it, so now a days to containerize an application means , its just a matter of adding a docker file provided if your modular application that you want to containerize has characteristics of microservice architecture. Your application should have ideal microservice characteristics like Modularity, Independent DataStore, Independent Deployability and your service accurately represent a part of business domain. Microservice architecture focus on a particular business domain and practices like EventStorming discussions can help to arrive a domain that you can plan to implement as a microservice or convert your existing monolith to a microservice. You could also consider containers for cases like cloud migration, deploying across IoT or custom devices , or for serverless integrations , event driven-scenarios etc. There are no hard and fast rules like where to use containers and most enterprises are considering containerizing as a part of cloud migration strategy to lift and shift their application to cloud provider to achieve scalability and reduce maintenance overhead, but its most suitable for microservice architecture. Serverless is another model similar to containerization.
Benefits of Containerization
From the above we could understand through containerization better organisation and modularization is what happening. Traditionally monolith applications were splitted based on technology domain as layered architectures/n-tier architecture , however maintanance was still a hurdle. In a layered architecture to make a simple change multiple team co-ordinations are required. Microservice made a change where monolith is split based on business domain and each team own a microservice has end to end visiblity over the microservice they own facilitating implementation hiding. This means they can use their own data store , its own technology suitable for the service, can containerize it and deploy to container platforms, which leads to portability, Better ownership and reduced team dependencies. Scalable services like Kubernetes could scale it and scale down with better isolation than hosting it on a Virtual Machine like (EC2), thus getting better cost effectiveness with better scalability . Fault tolerance increases as modular servies are more resilent to failtures and doesnt affect other services.
How to start and challenges to be aware of ?
For newer application analyse whether a microservice/containerized architecture is feasible. Simple containerized application , as in lift-and shift cloud migration cases, offers portability, easy maintainability and better scalability. For applications that has scope to evolve and scalability spliting business domains and make more modular services connected via network interaces are a great choices. You could take advantage of kubernetes platform in cloud to orchestrate multi-container applications.
If you planning to migrate your existing application, Analyse your existing application. A monolith application with a huge code base, is an ideal candidate for a evolving into a microservice architecture. You gets the benefits of Independent deployability, better maitanability and scalability however the potential side effects like additional complexity in forming a proper microservice architecture and the cost associated with it. Microservice is a form of distrubuted computing so operational logging and debugging will be a challenge , unless you consider cloud metrics like Cloud Trail/ Cloud Watch. There are other challenges as well associated with Distrubuted computing which you can refer here https://aws.amazon.com/builders-library/challenges-with-distributed-systems/
Which service to use ?
Kubernetes / Cloud Kubernetes Service like Elastic Kubernetes Service / Redhat Openshift services
Ideal for scenarios where you have multi-containers which require scaling /orchestration/logging. You can also schedule to run batch container jobs and event triggeed jobs with Keda. Pricing will be high compared to other approaches as Cloud Providers charge a fixed price for Control Plan and a Variable Cost for Worker Nodes and Services.
Serverless Containers like AWS Fargate
Ideal for container scenarios without managing servers. In this case you have to run/trigger this services from some other integrated services like AWS Lamda, or EKS . Benefit you gets are zero server management and inbuilt scalability and fault tolerance with consumption model. Most of this model provides runtime to run containers from a container registry or container image
Containers with Server Level Control
Amazon Elastic Cloud Instances(EC2) allow to create windows/linux instances and run container instances. This offers great flexibility at the cost of operational overhead.
Onpremise Scenarios
For on-premise scenarios Amazon EKS Anywhere offers onpremises kubernetes services at the cost of ownpremise cluster management.
Top comments (1)
Greetings
I could not contain my excitement seeing you are new here. I have to give you a benefit of being a new member. Nothing personal just business.
Welcome 🙏