We have a requirement of deploying Redis as an External Load Balancer Service on AWS-EKS (Elastic Kubernetes Service). As Redis will be a statefulset which of the following combination will be the best fit with EKS -
EKS with Self-managed nodes
EKS with Managed Node Groups
EKS with AWS Fargate
Although, I have studied that AWS Fargate should be used for deploying stateless applications.
Fargate, thus far, has been ideal for running stateless containerized workloads in a secure and cost-effective manner. Secure because Fargate runs each pod in a VM-isolated environment and patches nodes automatically. Cost-effective because, in Fargate, you only pay for the compute resources you have configured for your pod.
I didn't understand how stateless applications will be cost-effective. Kindly verify the below statement. It would be quite helpful.
In the stateless applications, the container will be in the running state, when there will be requests and otherwise no. of instances will be 0 just as in GCP Cloud Run.
Whereas in the stateful ones, the container will be running every time. And for this reason, we should use, EC2 instances for stateful applications
Related
I have a cluster with a mixture of services running on EC2 and Fargate, all being used internally. I am looking to deploy a new Fargate Service which is going to be publicly available over the Internet and will get around 5000 requests per minutes.
What factors do I need to consider so that I can choose if a new cluster should be created or if I can reuse the existing one? Would sharing of clusters also lead to security issues?
If your deployment is purely using Fargate, not EC2, then there's really no technical reason to split it into a separate ECS cluster, but there's also no reason to keep it in the same cluster. There's no added cost to create a new Fargate cluster, and logically separating your services into separate ECS clusters can help you monitor them separately in CloudWatch.
I am building an app that has no traffic, or very small traffic, and I am using Golang Docker with several micro services.
I also use AWS / EC2, but I am considering AWS Fargate to run my container.
If I have no traffic, should I pay for a running container or should I pay only when there is traffic ?
Using Fargate just means that you do not have to manage the underlying Container Host. The containers themselves are still managed by ECS.
For a more serverless approach, the Lambda service would be more applicable for most use cases.
Fargate can be used in conjunction with Lambda to run tasks that are too long running to be appropriate for Lambda.
I understand that ECS has EC2 and Fargate launch types that differ in the control they offer over the underlying environment configuration.
Before Fargate, ECS was used to provide detailed control over the container environment, while Elastic Beanstalk was used to abstract those details and just run the containers.
In the FAQ section of AWS ECS it says:
For Beanstalk, You simply specify which container images are to be deployed, the CPU and memory requirements, the port mappings, and the container links. You can work with Amazon ECS directly if you want more fine-grained control for custom application architectures.
Now with Fargate, it seems that the offered functionality is quite similar. So what are the differences between Fargate and docker on Elastic Beanstalk?
Multi Container Elastic Beanstalk, actually uses ECS to provision your cluster, which make it operate as a Platform-As-A-Service (PaaS) model, as then you can run your images on the cluster it sets up.
Fargate runs on a fully managed server so you dont worry about the cluster or server as you would in Elastic beanstalk. You just manage the Docker container making it more of a Software-As-A-Service (SaaS) model.
I'm planning to use Docker, and associate 1 EC2 instance with 1 Microservice.
Why do I want to deploy Docker in AWS ECS vs. ElasticBeanstalk?
It is said that AWS ECS has a native support to Docker. Is that it?
It would be great if you could be elaborate the pros and cons of running docker on AWS ECS vs. ElasticBeanstalk.
Elastic Beanstalk (multi-container) is an abstraction layer on top of ECS (Elastic Container Service) with some bootstrapped features and some limitations:
Automatically interacts with ECS and ELB
Cluster health and metrics are readily available and displayed without any extra effort
Load balancer must terminate HTTPS and all backend connections are HTTP
Easily adjustable autoscaling and instance sizing
Container logs are all collected in one place, but still segmented by instance – so in a cluster environment finding which instance served a request that logged some important data is a challenge.
Can only set hard memory limits in container definitions
All cluster instances must run the same set of containers
As of ECS IT is Amazon’s answer to container orchestration. It’s a bit rough around the edges and definitely a leap from Elastic Beanstalk, but it does have the advantage of significantly more flexibility including the ability to even define a custom scheduler.
All of the limitations imposed by Elastic Beanstalk are lifted.
Refer these for more info :
Elastic Beanstalk vs. ECS vs. Kubernetes
Amazon EC2 Container Serivce
Amazon Elasticbeanstalk
Have been running Docker with Elastic Beanstalk to deploy a relatively simple app, and it has been working great. Now with ECS on the horizon, I am interested to know what the differences are between the two services, and why one might use one over the other?
Amazon's documentation says the following:
Q: How is Amazon ECS different from AWS Elastic Beanstalk?
AWS Elastic Beanstalk is an application management platform that helps customers easily deploy and scale web applications and services. It keeps the provisioning of building blocks (e.g., EC2, RDS, Elastic Load Balancing, Auto Scaling, CloudWatch), deployment of applications, and health monitoring abstracted from the user so they can just focus on writing code. You simply specify which container images are to be deployed, the CPU and memory requirements, the port mappings, and the container links. Elastic Beanstalk will automatically handle all the details such as provisioning an Amazon ECS cluster, balancing load, auto-scaling, monitoring, and placing your containers across your cluster.
Elastic Beanstalk is ideal if you want to leverage the benefits of containers but just want the simplicity of deploying applications from development to production by uploading a container image. You can work with Amazon ECS directly if you want more fine-grained control for custom application architectures.