phildougherty

There are various reasons, but here are a few of the big ones:

1. Getting ahead of your costs before they start to shoot up as you grow. Check out this pricing calculator for an idea of what I mean: http://containership.io/#pricing

2. Cloud portability: Heroku runs in 2 AWS regions (us-east-1, eu-west-1). What happens if you want to host in a specific country, a completely different provider (maybe you have some free credits?) or even your own data center eventually? Not gonna happen with heroku.

3. More flexibility to run the types of databases, queues, or other open source software that isn't possible to run on Heroku.

4. With CaaS you have root access to the servers powering your software, where Heroku is more of a black box. Remember what happened with (rap)Genius? http://techcrunch.com/2013/02/14/heroku-admits-to-performanc...

Yes, Containers as a Service :)

Point taken! Added.

This looks pretty complicated/heavy based on http://oneops.github.io/admin/key-concepts/

Has anyone seen anything talking about resource requirements for deploying this? The fact that Cassandra, ElasticSearch, PostgreSQL are all involved plus much more makes me think the requirements must be quite high.

Edit: nevermind http://oneops.github.io/admin/prerequisites/

Check out https://containership.io - Also open source and works in any data center.

Edit: Full disclosure, I am the founder of ContainerShip.

This is a great team with an awesome product! Happy to see fellow Pittsburgh locals getting the attention they deserve.

Also check out https://containership.io as a scheduler. The core of the system is open source, has built in service discovery, dns, and load balancing.

Founders here if there are any questions!

I haven't checked out last backend in a while. From a quick look at their site I can say the following:

- ContainerShip is open source / Last Backend is not. The "brains" of the Last Backend system are managed by Last Backend and run on their servers. With ContainerShip all the critical components run on your own servers so if the centralized ContainerShip Cloud management system goes down, your systems keep working.. Not sure the same can be said for LB.

- ContainerShip already has a fully functional REST API & Command Line Interface for deploying/scaling/managing apps.

- ContainerShip Cloud allows you to do point in time snapshots of an entire cluster which you can then move between clouds/clone/etc.

There is probably more but I would need to dig further into their documentation.

I can assure you that this actually exists and works! :)

"containership" is made up of a handful of other repos.

More details here: https://docs.containership.io/docs/architectural-overview

If you're looking for some meat, check out the repos linked from the above docs page, including: https://github.com/containership/legiond https://github.com/containership/praetor

Thanks!

containership has two modes it can run in: leader & follower

You'll need at least one leader host for the cluster to function, and a minimum of 3 for true high availability.

Follower hosts are where your containers will actually be placed and will run. The specs on these servers should be great enough to fit all of the containers/applications you plan to run.

For a small test deployment with under 10 followers, you can get away with running your leaders on the smallest DigitalOcean droplets without any problems. Once you get up into larger number of follower hosts the hardware requirements of the leaders will change, but not significantly.

Thank you! We will update ASAP!

There are core ContainerShip features that function similarly to how Kubernetes does. Both provide a cluster scheduler that places and manages containers across a group of servers. They ensures jobs are restarted if they fail, let you scale the number of containers for an app up or down, and make it so you can stop thinking about individual servers.

That feature set alone is awesome but it won't take you to the finish line, you'll end up needing to tack other projects on to get a fully working system when you use something like Kubernetes (and some other popular choices).

With ContainerShip we wanted to make it easy for people to get up and running without having to learn and glue together many different projects. We are trying to provide everything needed to run and scale your infrastructure anywhere in one package.

ContainerShip Cloud makes it easy to stand clusters up on various providers, backup your data, and easily migrate somewhere else.

Comparing to a self-hosted PaaS is fair for the open source containership project.

It has built in high availability, automatic clustering of nodes, loadbalancing, service discovery, persistent data management, internal DNS, and support for easily extending the core of the system with plugins (plus more).

Of your examples I would say it is most like Openshift Origin. Dokku being mainly aimed at people running a single standalone server.

ContainerShip Cloud (https://cloud.containership.io) is a hosted service that lets you launch and scale ContainerShip clusters with a click across multiple providers. You can backup clusters, share them, and move them between clouds.

I wrote a getting started post that shows step by step how to use ContainerShip on DigitalOcean that may be of interest: https://medium.com/containership-articles/getting-started-gu...

Co-Founder present if anyone has questions!

Thanks! We have experience with ECS as well and have found tags and constraints to make life a lot easier when you are trying to containerize everything.

I think what they were going for was:

/etc is where your config files go on your server etcd is where your config goes for the distributed system

Wow. That was hilarious! So much truth in that.

Check out https://containership.io, it supports moving persistent data between servers in a cluster via https://github.com/containership/codexd, and also allows you to backup/restore/migrate entire clustered databases between hosting providers. Currently there is support for Crate.io and Apache Cassandra, with more on the way.

Co-Founder here. I'm happy to answer any questions!

There are various important use cases. One of them is that people want to use the same workflow when deploying their databases that they get when deploying their apps. It is possible to use our Tags system to force your database containers to live on systems with a special hardware configuration. Additionally you could configure the database application in ContainerShip to utilize all of the available resources on a given follower host or hosts, forcing them to run single tenant.

So today it is single data center in the case of everything but AWS. We allow you to automatically launch a ContainerShip cluster in AWS using https://cloud.containership.io. During setup you select a VPC ID, Subnet IDs, Security Groups, and AZs to launch into. In the near future we are going to fulfill your desires as we are working on features that let you easily span multiple providers or migrate between them.

There is ongoing management and maintenance of the ContainerShip cluster itself, but not for the Cassandra cluster per se. You can push out a new version of the docker image for your applications or roll them back if you need to upgrade. You can easily scale the cluster up or down as necessary. Is there a particular management feature you'd really like to see?

Edit: typo

ContainerShip co-founder here. Happy to answer any questions. We're working on producing Docker images for every major database that provide the same simple scaling and management.

To be fair, TC needs it's post titles to make sense to a general tech audience. I think going into the difference between containers and VMs in the title would be a bit of a challenge. What should it have said?

You can also use collectd nginx module along with nginx stub-status module to gather some useful metrics.

CloudFlare is build on top of OpenResty which is basically stock nginx with ngx_lua and a bunch of other modules built in. I would argue that if you want it to be, nginx can be much better at DDoS mitigation. You can use the modules limit_conn and limit_req to control how many connection individual IPs can make to your server for basic control.

That's true. I guess what I prefer about doing it in Grafana is that the interface for managing complex graphs with overlays of different metrics, and ones using wildcards to match groups of metrics is just way easier.

Nginx has supported http loadbalancing basically forever using the upstream directive along with proxy_pass. It supports leastconn, round-robin, and ip-hash (sticky). It is far from unproven. I have personally used it successfully in some huge projects. This new announcement simply makes the existing functionality work with tcp backends.