Live data from Hacker News

Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

engineering.remind.com

61–70 of 80 posts

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#61

aws is silly expensive. Why didnt you build this on top of digitalocean? Digitalocean is so awesome right now. They dont even charge for bandwidth overages.

Digitalocean is silly expensive. Why don't you look at Atlantic.net they are so awesome and charge way less than overpriced digitalocean. Why not run it on your laptop which you've already paid for, that would be even cheaper than overpriced atlantic.net!

Unless I am missing something Atlantic.net is 1-10 cents cheaper then digitalocean?

https://www.vultr.com/pricing/ is 20% cheaper right now at least.

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#62
post #57

> We tried Deis briefly but ultimately decided that it was more complicated than we felt it needed to be. That kind of reminds me of https://xkcd.com/927/ Sorry if that's not the case. I've also played briefly with Flynn and Deis and I haven't found anything that complicated that would need a whole rewrite and changing the entire approach. Moreover with Deis I can easily change providers (DO, AWS, Azure, etc.) and wi…

IMHO, it's best to see Empire/Deis/Dokku/etc. as a mean to an end, not the end itself.

While Empire itself may be tied to AWS, your app is still a portable, 12-factor, Heroku-compatible app. You can run it elsewhere.

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#63
post #32

Earlier quoted context omitted.

Not exactly sure what you mean by its meant for just 1 service? Do you mean just one box? I run multiple services/apps on my dokku instance

He means multiple instances - for scaling horizontally when traffic increases.

http://progrium.viewdocs.io/dokku/process-management

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#64

Earlier quoted context omitted.

Digitalocean is silly expensive. Why don't you look at Atlantic.net they are so awesome and charge way less than overpriced digitalocean. Why not run it on your laptop which you've already paid for, that would be even cheaper than overpriced atlantic.net!

Unless I am missing something Atlantic.net is 1-10 cents cheaper then digitalocean? https://www.vultr.com/pricing/ is 20% cheaper right now at least.

My old laptop offers much better price/performance, especially when I use free wifi in coffee shops for bandwidth. The laptop is already paid for so I only pay for the electricity (on days when I don't plug it into the wall at a friend's place to save even more). Those prices are just too expensive. There's always a place willing to do a job cheaper...

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#65

Earlier quoted context omitted.

He means multiple instances - for scaling horizontally when traffic increases.

http://progrium.viewdocs.io/dokku/process-management

That's still all on one machine; Dokku can't automatically schedule & distribute containers/processes across a cluster of hosts like Empire & others can. If you're doing anything non trivial you're going to outgrow one machine pretty soon :)

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#66

Earlier quoted context omitted.

It's a fair viewpoint. I guess my critical point is control: control over the hardware, its software, legal rights to it, and so on. If they're in control, it's theirs. How can it be myself if outsiders control or own it? I guess a combo of philosophical and legal.

I understand your point about control completely! My highest priority for businesses making these choices is usually slightly more pragmatic, and focuses on avoiding provider lockin - something that you can install and run on your own local hardware, you can also (in most cases) install and run on co-located hardware, on rented hardware, on traditional rented virtual hardware (i.e. VPS) or on "flexible" rented virtua…

That's a very pragmatic philosophy. I'm especially impressed at your unusual focus on vendor neutrality as a lack of it costs many companies millions in long run (see IBM & COBOL). Since I mostly avoid clouds, I'm not up to date on that end. I'd like to attempt your style of things as an experiment in the future, though.

Do you have a resource or resources for what components, strategies, or platforms are best for the deployment you describe? Something useful for production apps, reliable, and easy to move from dedicated hardware all the way to AWS (or back if necessary). I'm sure there's other readers on my end of things that might be interested as well.

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#67

I'm interested in hearing more about how you use this in terms of development lifecycle. Does a container image get created for every release of your app? I've always wondered about the more correct approach to this. This is how I currently use Docker: 1) Custom base image with all the things my company needs like supervisord, libpq, etc.. 2) Custom per-service base images like ones with Java for our Clojure services…

We have a setup that has been working out well for us:

1. We build docker images on every commit, in CI, and tag it with the git commit sha and branch (we don't actually use the branch tag anywhere, but we still tag it). This is essentially our "build" phase in the 12factor build/release/run. Every git commit has an associated docker image.

2. Our tooling for deploying is heavily based around the GitHub Deployments API. We have a project called Tugboat (https://github.com/remind101/tugboat) that receives deployment requests and fulfills them using the "/deploys" API of Empire. Tugboat simply deploys a docker image matching the GitHub repo, tagged with the git commit sha that is being requested for deployment (e.g. "remind101/acme-inc:").

We originally started maintaining our own base images based on alpine, but it ended up not being worth the effort. Now, we just use the official base images for each language we use (Mostly Go, Ruby and Node here). We only run a single process inside each container. We treat our docker images much like portable Go binaries.

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#68
post #37

Really cool stuff. Seems like you found a good way to hand off most of the hard stuff to AWS and only do a few key things yourselves to make the experience better. As such I think Empire has the potential to be a viable option for many companies, which is something I rarely say about a PaaS project :)

Thanks Blake! I think somebody mentioned that we were standing on the shoulders of giants. I think most of your contributions around this domain qualify for that :)

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#69

Congrats, not everyone can create a simple elegant platform and write about it in such an accessible manner. I suppose you're standing on the shoulders of giants, but still. This is the level of engineering/communication I always shoot for, and which (somewhat disappointingly) is rare where I've worked.

Thanks for the kind words. As a shameless plug, we are hiring: https://www.remind.com/careers :)

Re: Introducing Empire: A Self-Hosted PaaS Built on Docker and Amazon ECS

#70
post #57

> We tried Deis briefly but ultimately decided that it was more complicated than we felt it needed to be. That kind of reminds me of https://xkcd.com/927/ Sorry if that's not the case. I've also played briefly with Flynn and Deis and I haven't found anything that complicated that would need a whole rewrite and changing the entire approach. Moreover with Deis I can easily change providers (DO, AWS, Azure, etc.) and wi…

Our approach was to re-use as much existing technology as possible, which is not the case for most others. That's the "complication" I'm referring to here. Empire grew from the need for a production grade platform that was going to be stable.

Empire doesn't actually lock you into ECS. The scheduling backend is pluggable and could support Kubernetes/Swarm in the future.

Post reply on HN