5 ms·
I have to say: before I began to read through, I was already convinced the author's idea was not a good one. But by the time I finished, she convinced me that i
by apeace 10y ago
I have to say: before I began to read through, I was already convinced the author's idea was not a good one. But by the time I finished, she convinced me that it was a good plan in her situation.
There are lots of great tools in the Docker/container ecosystem these days, but I can see the argument that a major infrastructure migration should be done in incremental steps. Using containers as simply a Puppet replacement strikes me as a really good idea! You want your application to be _ready_ for containerization, before you try to introduce an orchestration system.
Although, when she mentioned that her team is meant to be "Heroku for the rest of the company", I couldn't help but think of Convox [0]. It's a great tool, it's open-source, and using it is really just like having your own Heroku. We used Convox at my last company, had amazing success with it, and I've been recommending it ever since.
[0] https://jvns.ca/blog/2016/10/26/running-container-without-docker/ https://jvns.ca/blog/2016/10/26/running-container-without-do...
- daeken 10y agoFYI, your link is pointing to the OP. I think you meant https://convox.com/ https://convox.com/
- apeace 10y agoThank you! Caught this too late to edit.
- nzoschke 10y agoConvox founder here. Thanks for the shout out! We are indeed building a private Heroku like platform so you don't have to. It's a simple of layer around AWS so it doesn't add extra craziness some other approaches do. As for the OP, her approach is spot on! Containerizing your app is the first step in future proofing it. Doing so correctly will remove layers and therefore simplify things. You now are looking at a package that can run on a laptop and run on a server with traditional techniques (upstart, systemd, etc). You may take this to the next step and enter the orchestration world. Or not! Patience is a virtue, wait 6 more months and all the orchestration tools will be that much better. It's all about simplifying. Adopt Dockerfile and shed Homebrew and Chef. Run containers on a "dumb" box with systemd and shed Packer. Run containers on ECS and shed custom AMIs and userdata and nagios and...
- Naomarik 10y agoI think you dozed off there...
- vacri 10y agoI hate nagios as much as the next op, but what is so magical about containers that your services will no longer require an outage alerting mechanism?
- seabrookmx 10y ago> run containers on ECS Presumably ECS has its own alerting mechanisms similar to CloudFormation and ElasticBeanstalk (I've only used the latter two, not the former).
- vacri 10y agoIn my experience, AWS alerting only sends one alert once per issue. If you're asleep when the single SMS comes through, tough. Nagios will nag you until you do something about it... Maybe ECS is different. I haven't played with it, but I imagine it's "make an SNS topic" like everything else.
- pdx6 10y agoSend the AWS alarms to opsgenie or pager duty and they will nag you based on a single event, including escalations.
- vacri 10y agoNagios or a SaaS, we're still back to something else other than containers to manage the alerts, though.
- nzoschke 10y agoYou can integrate CloudWatch Alarms to PagerDuty with an SNS webhook. PagerDuty keeps nagging until the CloudWatch Alarm auto-resolves.