Live data from Hacker News

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

engineering.remind.com

21–30 of 80 posts

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

#21
post #5

personally i use dokku ( https://github.com/progrium/dokku ). i would be happy to see one standard "heroku-like" paass since i feel too many people trying to tackle the same problem.

http://www.openshift.org/ or http://cloudfoundry.org/index.html , both used in production by f500 companies

Cloud Foundry requires a ton of (compute) overhead to get set up. It's very much intended for large projects. Hell, you need a separate VM just to install it.

For anyone looking at a Dokku alternative, Cloud Foundry isn't one.

Openshift is nice though.

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

#22
This work has plenty about it that was interesting. The best part to me was their answer to "why not feature X?" They said they prefer to build upon the most mature and stable technologies along with naming a few. Too many teams end up losing competitiveness by wasting precious hours debugging the latest and greatest thing that isn't quite reliable yet. Their choice is wiser and might get attention of more risk-conscious users.

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

#23
post #18

Earlier quoted context omitted.

KONG definitely looks interesting, and I'd love to know more about it. However, there's definitely not a lot written about it yet. For example: I've gone searching through the blog posts, github readme, and KONG documentation, but I still have no idea _why_ it needs Cassandra. What does it store in there?

Kong uses Cassandra for storing config. This makes it easy to run a Kong cluster. Just add more instances that share the same Cassandra cluster.

Is rate limiting state stored in Cassandra?

One of the main graphics on the KONG docs shows a Caching plugin (http://getkong.org/assets/images/homepage/diagram-right.png), but the list of available plugins doesn't include such an entry. Is that because caching is built in? Is the cache state stored in Cassandra? Or is the plugin yet to be built?

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

#24
post #18

Earlier quoted context omitted.

KONG definitely looks interesting, and I'd love to know more about it. However, there's definitely not a lot written about it yet. For example: I've gone searching through the blog posts, github readme, and KONG documentation, but I still have no idea _why_ it needs Cassandra. What does it store in there?

Kong uses Cassandra for storing config. This makes it easy to run a Kong cluster. Just add more instances that share the same Cassandra cluster.

Worth mentioning KongDB, to easily provision a cloud Cassandra instance for free: http://kongdb.org

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

#25
post #6

Does this really classify as "self hosted" if it's heavily dependent on AWS?

I don't think so. It's their hardware, infrastructure, and engineers hosting it. They control those things. You get the rest. Sounds like an AWS-hosted solution with some advertised advantages over other solutions. Definitely not self-hosted. Note: I think the only 3rd party thing I'd call self-hosted is colocation where I delivered the server, they plugged it in, and the most they do is reboot it for me.

From the point of view of software, I generally consider something self-host{ed,able} if I can run it on a machine I choose, without enforced network/environment requirements.

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

#26
post #23

Earlier quoted context omitted.

Kong uses Cassandra for storing config. This makes it easy to run a Kong cluster. Just add more instances that share the same Cassandra cluster.

Is rate limiting state stored in Cassandra? One of the main graphics on the KONG docs shows a Caching plugin ( http://getkong.org/assets/images/homepage/diagram-right.png ), but the list of available plugins doesn't include such an entry. Is that because caching is built in? Is the cache state stored in Cassandra? Or is the plugin yet to be built?

All the data that Kong stores (including rate-limiting data, consumers, etc) is being saved into Cassandra.

nginx has a simple in-memory cache, but it can only be shared across workers on the same instance, so in order to scale Kong horizontally by adding more servers there must be a third-party datastore (in this case Cassandra) that stores and serves the data to the cluster.

Kong supports a simple caching mechanism that's basically the one that nginx supports. We are planning to add a more complex Caching plugin that will store data into Cassandra as well, and will make the cached items available across the cluster.

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

#27
post #21

Earlier quoted context omitted.

http://www.openshift.org/ or http://cloudfoundry.org/index.html , both used in production by f500 companies

Cloud Foundry requires a ton of (compute) overhead to get set up. It's very much intended for large projects. Hell, you need a separate VM just to install it. For anyone looking at a Dokku alternative, Cloud Foundry isn't one. Openshift is nice though.

> Hell, you need a separate VM just to install it.

I'm not sure why that's a problem. If you want something that's actually like heroku like in terms of uptime and what not, you need something that can manage the health of the cluster. Dokku's cool, but it doesn't make sense for anything you actually need to depend on. If it doesn't make sense to pay for the overhead of running your own paas, just use Heroku instead.

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

#28
post #2

This looks great: simple yet powerful. I'm working a lot with Kubernetes, and you don't actually need to run an overlay network on AWS (or GCE). On AWS, there's some VPC magic that surprised me when I first saw it! But I believe that's beside the point; it's not about ECS vs Kubernetes, it is about what we can build on top. In particular, I think the idea of embedding a Procfile in a Docker image is really clever; it…

Exactly! One of our goals was to also make the scheduling backend pluggable, so we're hoping that the community will implement a Kubernetes backend in the future. There's a lot of similar concepts between both, but we ultimately chose ECS for it's ease of operation and the integration with existing AWS services like ELB.

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

#29

Earlier quoted context omitted.

I don't think so. It's their hardware, infrastructure, and engineers hosting it. They control those things. You get the rest. Sounds like an AWS-hosted solution with some advertised advantages over other solutions. Definitely not self-hosted. Note: I think the only 3rd party thing I'd call self-hosted is colocation where I delivered the server, they plugged it in, and the most they do is reboot it for me.

From the point of view of software, I generally consider something self-host{ed,able} if I can run it on a machine I choose, without enforced network/environment requirements.

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.

Post reply on HN