"Ways to run containers" is as generic a problem statement as "ways to run servers" or "ways to run code". Of course they offer many different solutions for it, considering there are a hundred different use cases as well. Going through the list, I don't really see any duplication and very little overlap in functionality. For example Lambda, EC2 and EKS aren't similar in any way whatsoever.
Clearly Corey has a Lambda function parsing links to his website from external sources to see who is talking about him (and that if we ask him to open source he will say no because "it's ugly code"). :-)
This has been a popular twitter shorthand to dunk on AWS, but it's a really stupid list. Yes, there is more than one (there are six [0]) - targeted at different skill levels (e.g. someone coming from Kubernetes is going to have different expectations than someone starting with no prior knowledge).
But...
#1 isn't a way to run containers it's a way to organize best practices of your container images across your organization. That's closer to a container registry than a way to run containers.
#4/5 aren't "ways to run containers" - they are explicitly ways NOT to run containers. Like yes, you can CHOOSE to bring a container to a native EC2 instance, but it's not really a way to run containers any more than an empty lot a "Way to build a house"
#9 isn't a way to run containers, it's a service that you can instead run in a container to test it locally. Basically the opposite of the indication.
#10 admits it's misusing a service. You can provide a container definition to build your services via CodeBuild. Hardly what people think about when they talk about running a container in the cloud.
#11/12 are exactly the same semantics as with the root services - just running in your local datacenter instead of AWS. Counting those as separate is like counting EC2 as different services for every instance types.
#13 Fargate isn't a different way to run a container - Fargate is still ECS. It's just ECS where instead of managing the EC2 instances underneath you let AWS do it for you. The container interactions are identical.
#14 is a CLI tool to help with building container images that then run on ECS
#15 is a CLI to interact with the existing services
#16 predates containers
People take Corey Quinn way too fucking seriously. He shitposts. He makes jokes. He speaks truth to power. Sure. But he's got his tongue firmly planted in his cheek the whole time but people then parrot the stuff he posts as if it's a genuine well-thought out criticism.
[0]
* ECS (The default container service)
* EKS (For Kubernetes customers)
* Lambda (Cloud Functions that you can model as containers)
* Lightsail (AWS's VPS offering)
* AppRunner (AWS's CloudRun)
* ROSA (Redhat OpenShift)
I think the main idea is that you can run anything you want inside them, not just containers. AWS doesn't care or necessarily provide many conveniences for this use case, you have to roll your own.
This list is used to make fun of AWS for having *too many* options, so it's completely silly to criticize them for offering general purpose computing and then turning around and saying: "You're making our lives complicated! I can run containers that way! It's too confusing!".
For my use cases, Lightsail containers are far over-priced when compared to the smallest virtual server (which can run multiple small containers). $3.5/month for 1vCPU virtual server or $7 per container for 0.5 vCPU.
There is certainly value in the service offered, but 4x/vCPU worth? That I am not sure of.
lightsail seems to be aimed at smaller deployments, so measuring the cost difference as a ratio probably isn't as relevant as the absolute difference - this is probably worth $7-14/mo for the user who's only running a couple of small containers.
I'm using Lightsail hosts (not containers) to host some of my personal websites. For $5/mo it's a great deal, and you can manage everything in one place - I don't have to go mess with ELB separately to configure all the DNS & static IPs.
Seems almost exactly like Google Cloud Run [0], which has been available in production since 2019. Is there anything novel in this offering that I've missed?
The original Lightsail VPS product is hot garbage. If you actually try to use it, it throttles itself into oblivion. For me, that Lightsail name is forever tainted, so I won't even click the linked story.
I've been poking at Lightsail Containers a little and have been comparing it to DigitalOcean (DO) App Platform. This is what the experience has been so far:
Off the top, I can tell you that Laightsail is not receiving a lot of AWS attention. There are no roadmaps that I could find and updates are not regular. If you look for information about this service on the Internet currently there is no abundance of blogs and articles which probably suggests not many users are using it.
DO App Platform on the hand seems to under active development and changes/updates are regular: https://docs.digitalocean.com/release-notes/app-platform/. I feel this service is also not used that often but in its current form it's easier to understand than Lightsail and I can see how DO can push a lot of its customers towards this offering.
The Story around Lightsail Contaioner logs is a real mess. The only way I know to centralise logs is to install your app, something like Filebeat plus Supervisor to run the both in your Docker container. So that's 3 processes inside a single Docker container which is not ideal and makes for poor separation of concerns.
Lightsail UI is old and clunky. There really are no deploy logs and inspecting what's happening has to happen via this weird and hard to use log viewer UI.
DO App Platform UI may no be the best or for everyone but just like the rest of their products it is coherant. Following deploy progress is easy and so is viewing the logs.
The one thing that I have to give to AWS is pricing. Lightsail Containers let you deploy up to 10 separate images on a single Lightsail Container starting from $5 a month. Yeah the basic container size may be limited but if you are looking at Lightsail for anything, you are probably doing so to avoid server provisioning to spend that time on solving a business problem on the cheap. I really think for what it give you the price isn't so bad. Heck, you could put Nginx or Caddy in front of up to 9 other Docker containers using a single Lightsail Container and reverse proxy 9 websites.
DO App Platform on the other hand charges per running process (let's say per running Docker image to simplify). So if you intend to run multiple Docker images, App Platform will quickly get expensive when, depending on what you're doing, Lightsail may not. DO also supports routing which is let's you direct traffic to specific Docker container. This is something that Lightsail does not support and you have to deal with manually with something like Nginx or Caddy.
I guess being on AWS is also a plus. If you think your business will grow in the future and you may need access to more of AWS services, Lightsail could be a great place to start on the cheap to try out an idea. If you are making money then do consider alternative ways to host containers on AWS for more Flexibility but if Lightsail is good enough then that's that.
Conclusion: AWS Lightsail Container UI sucks and there are some missing features like better log management which makes Lightsail look less appealing compared to other services like DO or Heroku but overall I feel there is a place in the market for a service like Lightsail for budget projects and really hope AWS will continue to improve this service.
Digital Ocean isn't accessible in China. Lightsail and AWS are. GCP also works. We hosted in Japan and HK on Lightsail for production projects for use in mainland China. We did run into the performance cap, so eventually switched from Lightsail to AWS proper.
25 comments
[ 3.2 ms ] story [ 45.3 ms ] threadhttps://www.lastweekinaws.com/blog/the-17-ways-to-run-contai...
https://www.lastweekinaws.com/blog/17-more-ways-to-run-conta...
But...
#1 isn't a way to run containers it's a way to organize best practices of your container images across your organization. That's closer to a container registry than a way to run containers.
#4/5 aren't "ways to run containers" - they are explicitly ways NOT to run containers. Like yes, you can CHOOSE to bring a container to a native EC2 instance, but it's not really a way to run containers any more than an empty lot a "Way to build a house"
#9 isn't a way to run containers, it's a service that you can instead run in a container to test it locally. Basically the opposite of the indication.
#10 admits it's misusing a service. You can provide a container definition to build your services via CodeBuild. Hardly what people think about when they talk about running a container in the cloud.
#11/12 are exactly the same semantics as with the root services - just running in your local datacenter instead of AWS. Counting those as separate is like counting EC2 as different services for every instance types.
#13 Fargate isn't a different way to run a container - Fargate is still ECS. It's just ECS where instead of managing the EC2 instances underneath you let AWS do it for you. The container interactions are identical.
#14 is a CLI tool to help with building container images that then run on ECS
#15 is a CLI to interact with the existing services
#16 predates containers
People take Corey Quinn way too fucking seriously. He shitposts. He makes jokes. He speaks truth to power. Sure. But he's got his tongue firmly planted in his cheek the whole time but people then parrot the stuff he posts as if it's a genuine well-thought out criticism.
[0] * ECS (The default container service) * EKS (For Kubernetes customers) * Lambda (Cloud Functions that you can model as containers) * Lightsail (AWS's VPS offering) * AppRunner (AWS's CloudRun) * ROSA (Redhat OpenShift)
So it's now illegal to rent VM and run containers inside in 2021?
This list is used to make fun of AWS for having *too many* options, so it's completely silly to criticize them for offering general purpose computing and then turning around and saying: "You're making our lives complicated! I can run containers that way! It's too confusing!".
There is certainly value in the service offered, but 4x/vCPU worth? That I am not sure of.
It would be nice to have a scale to zero ability.
[0] https://cloud.google.com/run
1. https://aws.amazon.com/apprunner/
Off the top, I can tell you that Laightsail is not receiving a lot of AWS attention. There are no roadmaps that I could find and updates are not regular. If you look for information about this service on the Internet currently there is no abundance of blogs and articles which probably suggests not many users are using it.
DO App Platform on the hand seems to under active development and changes/updates are regular: https://docs.digitalocean.com/release-notes/app-platform/. I feel this service is also not used that often but in its current form it's easier to understand than Lightsail and I can see how DO can push a lot of its customers towards this offering.
The Story around Lightsail Contaioner logs is a real mess. The only way I know to centralise logs is to install your app, something like Filebeat plus Supervisor to run the both in your Docker container. So that's 3 processes inside a single Docker container which is not ideal and makes for poor separation of concerns.
DO App Platform support log forwarding https://docs.digitalocean.com/products/app-platform/how-to/e...
Lightsail UI is old and clunky. There really are no deploy logs and inspecting what's happening has to happen via this weird and hard to use log viewer UI.
DO App Platform UI may no be the best or for everyone but just like the rest of their products it is coherant. Following deploy progress is easy and so is viewing the logs.
The one thing that I have to give to AWS is pricing. Lightsail Containers let you deploy up to 10 separate images on a single Lightsail Container starting from $5 a month. Yeah the basic container size may be limited but if you are looking at Lightsail for anything, you are probably doing so to avoid server provisioning to spend that time on solving a business problem on the cheap. I really think for what it give you the price isn't so bad. Heck, you could put Nginx or Caddy in front of up to 9 other Docker containers using a single Lightsail Container and reverse proxy 9 websites.
DO App Platform on the other hand charges per running process (let's say per running Docker image to simplify). So if you intend to run multiple Docker images, App Platform will quickly get expensive when, depending on what you're doing, Lightsail may not. DO also supports routing which is let's you direct traffic to specific Docker container. This is something that Lightsail does not support and you have to deal with manually with something like Nginx or Caddy.
I guess being on AWS is also a plus. If you think your business will grow in the future and you may need access to more of AWS services, Lightsail could be a great place to start on the cheap to try out an idea. If you are making money then do consider alternative ways to host containers on AWS for more Flexibility but if Lightsail is good enough then that's that.
Conclusion: AWS Lightsail Container UI sucks and there are some missing features like better log management which makes Lightsail look less appealing compared to other services like DO or Heroku but overall I feel there is a place in the market for a service like Lightsail for budget projects and really hope AWS will continue to improve this service.