Managed Kubernetes on AWS
iTMethods deploys and manages the Amazon Elastic Container Service for Kubernetes (Amazon EKS) making it easy for you to run Kubernetes on AWS without needing to install and operate your own Kubernetes clusters. We offer a Continous Deliver as a Service platform that integrates your DevOps and Cloud delivery for your application teams.
(Currently in Preview. Proof of Concept (POC) Engagements Available – Email us at email@example.com)
Container Use Cases
Distributed Applications and Microservices
You can use containers to create distributed applications by breaking apart your application into independent tasks or processes (e.g., microservices). For example, you can have separate containers for your webserver, application server, message queue, and backend workers. Containers are ideal for running single tasks or processes, so you can use containers as the base unit for a task when scaling up and scaling down. Each component of your application can be made from different container images. Docker containers provide process isolation allowing you to run and scale different components side by side regardless of the programming language or libraries running in each container.
You can use containers for batch and ETL jobs by packaging the job into a container and deploying it into a shared cluster. You can run different versions of the same job or multiple jobs on the same cluster or even the same instance since containers are isolated. You can also share the cluster capacity with other processes such as applications and take advantage of fluctuations in the cluster load. You can start jobs quickly and grow jobs dynamically in response to demand, improving resource utilization.
Continuous Integration and Continuous Deployment
You can use containers for continuous integration and deployment because Docker provides a system for image versioning. You can setup your build process to pull your code from a repository, build it, package it into a Docker image, and push the newly created image into an image repository. You can then have your deployment process pull the new image from your repository, test the application, and deploy to your production servers. You can avoid having an application that works on your development environment but fails in production because the Docker daemon is the same across your development, staging, and production machines.