Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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/...


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: