3 ms·

If I don't want vendor lock-in, or a minimal amount, how should I run containers on AWS?

bkanber 5y ago
Docker or kubernetes or any other orchestration software of your choice on EC2
atomland 5y ago
Well, to begin with, I think people worry too much about vendor lock-in. Use the tools your cloud vendor provides to make your life easier. Isn’t that one of the reasons you chose them? That said, moving containers to another container orchestrator isn’t terribly difficult, so I don’t personally worry about vendor lock-in for containerized workloads. If your workloads have dependencies on other vendor-specific services, that’s a different story, but basically a container is easy to move elsewhere.
- speedgoose 5y ago
  My current company has a cluster on Amazon, one on Azure, and used to have one on a local hosting company. So it's very important to not be stuck too much with one cloud providers locks. We also chose our current cloud providers because the alternatives were worse.
- jayar95 5y ago
  Vendor lock-in can be a real issue as you scale. I work at a company going through a hypergrowth phase, and we're more or less locked into Azure, which has been objectively awful for us
glenjamin 5y ago
If the containerized app you’re deploying follows 12 factor principles it’s very unlikely that you’ll be locked in due to specific functionality The cost to move your operations expertise to another platform and learn all of its new quirks might be significant though.
- speedgoose 5y ago
  Yes it's significant, that's why I don't like vendor lock-in. It's very simple to use VMs on various cloud providers but as soon as you use their more integrated products, it can be a disaster.
InTheArena 5y ago
EKS + Fargate. It’s that simple. If you need extensions into the AWS infrastructure, check out their CRD extensions that allow you to provision all of the infrastructure using K8s.

Docker or kubernetes or any other orchestration software of your choice on EC2

Well, to begin with, I think people worry too much about vendor lock-in. Use the tools your cloud vendor provides to make your life easier. Isn’t that one of the reasons you chose them? That said, moving containers to another container orchestrator isn’t terribly difficult, so I don’t personally worry about vendor lock-in for containerized workloads. If your workloads have dependencies on other vendor-specific services, that’s a different story, but basically a container is easy to move elsewhere.

speedgoose 5y ago
My current company has a cluster on Amazon, one on Azure, and used to have one on a local hosting company. So it's very important to not be stuck too much with one cloud providers locks. We also chose our current cloud providers because the alternatives were worse.
jayar95 5y ago
Vendor lock-in can be a real issue as you scale. I work at a company going through a hypergrowth phase, and we're more or less locked into Azure, which has been objectively awful for us

glenjamin 5y ago

If the containerized app you’re deploying follows 12 factor principles it’s very unlikely that you’ll be locked in due to specific functionality The cost to move your operations expertise to another platform and learn all of its new quirks might be significant though.

speedgoose 5y ago
Yes it's significant, that's why I don't like vendor lock-in. It's very simple to use VMs on various cloud providers but as soon as you use their more integrated products, it can be a disaster.

InTheArena 5y ago

EKS + Fargate. It’s that simple. If you need extensions into the AWS infrastructure, check out their CRD extensions that allow you to provision all of the infrastructure using K8s.