8 ms·

Why would you need Kubernetes with a startup instead of in the case of AWS just using some EC2 instances, a load balancer and an autoscaling group and a monolit

Why would you need Kubernetes with a startup instead of in the case of AWS just using some EC2 instances, a load balancer and an autoscaling group and a monolithic application? For your backend just use a hosted version of MySql/Postgres/ElasticSearch ? It’s simple, no “cloud locki in” (which is really over exaggerated). The only reason to use K8s is for resume driven development. Which honestly is not a bad idea in an of itself because your startup is going to statistically fail and you might as well use the experience to get another job.

dangus 1y ago
I would still personally prefer to containerize early because I think a new company should avoid the infrastructure dependency and deployment pitfalls that come with using plain traditional EC2. I’d say aim to avoid using tech like Chef, Ansible, Packer, etc, which will be an inevitable need for someone putting applications on EC2 instances. If these need to be used they should be used for extremely limited/basic things like if there’s stuff you need to install in the base OS for management that can’t be done in a different way. Of course this doesn’t mean use k8s for your applications, I think ideally you’re looking at ECS leveraging either EC2 or Fargate or another cloud’s equivalent.
- JustExAWS 1y ago
  That’s actually a good point. It’s been 6 years since I have deployed to EC2. I have been doing Lambda or ECS/Fargate. But when I did it was either: 1. Azure DevOps with agents on EC2 2. Octopus Deploy with agents (not my choice) 3. CodeDeploy with agents All of those are horrible choices. On the other hand, my Fargate deployments have all been: 1. Create Docker container 2. Push to ECR 3. Deploy a parameterized CloudFormation template to update an ECS cluster. I’ve used a modified version of this template for 7 years. I’m not the author. https://github.com/1Strategy/fargate-cloudformation-example/blob/master/fargate.yaml https://github.com/1Strategy/fargate-cloudformation-example/...
  - dangus 1y ago
    Exactly, I think any solution that is just like “build docker container, push docker container” is very much what you want as a startup. “Avoid k8s” shouldn’t mean “avoid containers” because they have major velocity and reliability benefits for small teams with no ops engineers. I totally agree with you that CodeDeploy in particular is miserable. I’d much rather overpay for compute using Fargate than be saddled with that.

dangus 1y ago

I would still personally prefer to containerize early because I think a new company should avoid the infrastructure dependency and deployment pitfalls that come with using plain traditional EC2. I’d say aim to avoid using tech like Chef, Ansible, Packer, etc, which will be an inevitable need for someone putting applications on EC2 instances. If these need to be used they should be used for extremely limited/basic things like if there’s stuff you need to install in the base OS for management that can’t be done in a different way. Of course this doesn’t mean use k8s for your applications, I think ideally you’re looking at ECS leveraging either EC2 or Fargate or another cloud’s equivalent.

JustExAWS 1y ago
That’s actually a good point. It’s been 6 years since I have deployed to EC2. I have been doing Lambda or ECS/Fargate. But when I did it was either: 1. Azure DevOps with agents on EC2 2. Octopus Deploy with agents (not my choice) 3. CodeDeploy with agents All of those are horrible choices. On the other hand, my Fargate deployments have all been: 1. Create Docker container 2. Push to ECR 3. Deploy a parameterized CloudFormation template to update an ECS cluster. I’ve used a modified version of this template for 7 years. I’m not the author. https://github.com/1Strategy/fargate-cloudformation-example/blob/master/fargate.yaml https://github.com/1Strategy/fargate-cloudformation-example/...
- dangus 1y ago
  Exactly, I think any solution that is just like “build docker container, push docker container” is very much what you want as a startup. “Avoid k8s” shouldn’t mean “avoid containers” because they have major velocity and reliability benefits for small teams with no ops engineers. I totally agree with you that CodeDeploy in particular is miserable. I’d much rather overpay for compute using Fargate than be saddled with that.