Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Want to Run Stateful Containers, Too

techcrunch.com

Post reply on HN
Print view View original

21–30 of 102 posts

Re: I Want to Run Stateful Containers, Too

#21

Post by cpitman »

rco8786 wrote: post #12
ownagefool wrote: post #8

The author is correct. We should be running stateful containers, but until the the software is ready the default advice quite rightly should be not to unless you understand the implications. For example we run ceph and use it in kubernetes. We obviously only run replica sets (the kubernetes feature, for those uninitiated) of 1 for these services. There's also some rough edges with locking for dead nodes, but it's def…

Does kubernetes not have a mechanism for defining host/rack diversity constraints?

I know that OpenShift 3, built on kubernetes, supports both affinity and anti-affinity policies (https://access.redhat.com/documentation/en/openshift-enterpr...). I don't know if these are part of kubernetes or part of the extensions custom to OpenShift.

Re: I Want to Run Stateful Containers, Too

#22

Post by kordless »

> Back to my point (I think I have one).

Customers rarely understand the feature set and deliverables they need for a given use case when there is a major shift in the way the system delivers that use case. I've been working with a very large company's operation team on containerized PoC of a specific developer's team use case which builds and tests their SaaS software stack. The ops team can't wrap their heads around how the software needs to be changed to enable their move to a containerized solution. They just thought they could "containerize" it for the developers and move on. Guess we should have been talking to the devs instead.

One point here about all this is that operations teams and developer teams must work closely together on objectives but their end goals are in direct conflict when it comes to providing infrastructure for software. Ops doesn't want the infrastructure to change much because it becomes difficult to scale and prevents reliable, repeatable root cause analysis when things break. Nobody wants to wake up in the night and troubleshoot stuff one doesn't understand when there are bears at the door.

Developers want the infrastructure to be flexible and support doing crazy shit with their software so they can satisfy customer's demands with use cases and requirements, and do it faster than the competitor does. The desire for sales and growth drives the need for it to remain extraordinarily reliable and scalable.

Immutability of the infrastructure provides a means by which both devs and ops folks can come together and achieve common goals, while keeping their objectives meet with moving fast (devs) and keeping things reliable (ops).

Wanting stateful containers as a feature is simply a misunderstanding of what is needed from the infrastructure based on the developer's standpoint of needing "reliability" from both ops and devs. Reliability of the underlying infrastructure is brought about by making the container's deployments immutable. Reliability of the software is brought about by keeping state for a given configuration once it has been proven to work through many iterations of a given use-case.

Re: I Want to Run Stateful Containers, Too

#23

Post by ownagefool »

rco8786 wrote: post #12
ownagefool wrote: post #8

The author is correct. We should be running stateful containers, but until the the software is ready the default advice quite rightly should be not to unless you understand the implications. For example we run ceph and use it in kubernetes. We obviously only run replica sets (the kubernetes feature, for those uninitiated) of 1 for these services. There's also some rough edges with locking for dead nodes, but it's def…

Does kubernetes not have a mechanism for defining host/rack diversity constraints?

The scheduler is just best effort at the moment there's some ways around it.

You could indeed create seperate replication-controllers against labels, such as your aws-zone, and run them seperatly. This flies in the face of having replication-controllers and sucks in my opinion.

The other option is a single replication-controller and have your containers use a resouce that can't be reused, thus ensuring you're scheduled elsewhere. This is hacky.

I suspect it'll be another year before kubernetes is all singing and dancing, but I do like using it.

Re: I Want to Run Stateful Containers, Too

#24

Post by perlgeek »

Much of the distributed system management tooling seems to be in its infancy.

For exapmle, if I have one host, I can manage dependencies by adding them to my debian/control files, and apt-get/dpkg will figure them out for me. If the services are installed on separate hosts, I'm on my own. I haven't found a proper solution for managing service dependencies distributed on several hosts. (Compare https://news.ycombinator.com/item?id=10487126).

So when even the most basic managment tasks are solved for distributed systems, why does it surprise anybody that more advanced state management is still in the "you're on your own" stage?

I'm sorry, but I can't help my cynicism here.

Re: I Want to Run Stateful Containers, Too

#25

Post by josephjacks »

ownagefool wrote: post #8

The author is correct. We should be running stateful containers, but until the the software is ready the default advice quite rightly should be not to unless you understand the implications. For example we run ceph and use it in kubernetes. We obviously only run replica sets (the kubernetes feature, for those uninitiated) of 1 for these services. There's also some rough edges with locking for dead nodes, but it's def…

Take a look at the new DaemonSet abstraction Kubernetes. Great for running things like HDFS and other distributed data workloads/frameworks: https://github.com/kubernetes/kubernetes/blob/release-1.1/do...

Re: I Want to Run Stateful Containers, Too

#26

Post by josephjacks »

ownagefool wrote: post #8

The author is correct. We should be running stateful containers, but until the the software is ready the default advice quite rightly should be not to unless you understand the implications. For example we run ceph and use it in kubernetes. We obviously only run replica sets (the kubernetes feature, for those uninitiated) of 1 for these services. There's also some rough edges with locking for dead nodes, but it's def…

Take a look at the new DaemonSet abstraction Kubernetes. Great for running things like HDFS and other distributed data workloads/frameworks: https://github.com/kubernetes/kubernetes/blob/release-1.1/do...

Re: I Want to Run Stateful Containers, Too

#27

Post by jacques_chester »

FooBarWidget wrote: post #9
jacques_chester wrote: post #7

I agree with the author that writing your own snowflake PaaS is a mistake. I work at Pivotal on the fringes of CloudFoundry; OpenShift Origin is a competing system. Either way, you should be using a full PaaS instead of rolling your own. But this is the bit that surprises me: They get you hooked for free and the next level is $1,496 per month… wtf! MongoLabs is little better. $1500 per month, versus weeks of engineer…

> $1500 per month, versus weeks of engineering time spent tinkering with and upgrading and bug-fixing and trouble-shooting and security-patching a hand-made solution is a fantastic bargain. That's only true if you look at it from the point of view of an enterprise, a startup with VC funding, or generally a "rich" company. If you're a cash-strapped startup/small business with only a few thousand dollars profit per mon…

Engineering time isn't free, even for cash-strapped startups.

For a startup, your hyperfocus has to be on creating a product that is attractive to users. Everything else is entirely secondary.

Re: I Want to Run Stateful Containers, Too

#29

Post by jacques_chester »

vidarh wrote: post #18
jacques_chester wrote: post #7

I agree with the author that writing your own snowflake PaaS is a mistake. I work at Pivotal on the fringes of CloudFoundry; OpenShift Origin is a competing system. Either way, you should be using a full PaaS instead of rolling your own. But this is the bit that surprises me: They get you hooked for free and the next level is $1,496 per month… wtf! MongoLabs is little better. $1500 per month, versus weeks of engineer…

> And so it is with PaaSes. The marker was passed years ago. We don't need to go on these spiritual quests any more. The CloudFoundry installation instructions alone makes me run away screaming. Same with OpenStack. There's no "spiritual quest" involved, but a lack of willingness to add unnecessary complexity. Of course it looks different when you've already eaten the cost of getting it up and running and/or has read…

> The CloudFoundry installation instructions alone makes me run away screaming.

BOSH is getting some much-needed love right now for this reason. Incidentally, for long-running stateful services, BOSH is the right tool for the job. We use it for Cloud Foundry, MySQL and a bunch of others I don't recall right now.

Anyhow. If you just want to see quickly if CF fits your needs, the place to go is Lattice[1], explicitly designed to be installable on a laptop.

In the meantime, you can let Pivotal host you on Pivotal Web Services[2].

That plucky startup from Armonk, IBM, are the second-largest donor of engineering effort to Cloud Foundry. Their public installation is BlueMix[3].

Other hosted installations of Cloud Foundry are CenturyLink AppFog[4], anynines[5] and Swisscom Application Cloud[6].

When you decide you want something in-house, you can buy Pivotal Cloud Foundry with all the support bells and whistles. Or you can just use the standard cf-release repo and deploy it to you own OpenStack or vSphere environment. Or on AWS. Or on Azure. Or some mixture of the above.

[1] http://lattice.cf

[2] https://run.pivotal.io

[3] https://console.ng.bluemix.net/

[4] https://www.ctl.io/appfog/

[5] http://www.anynines.com/

[6] https://www.swisscom.ch/en/business/enterprise/offer/cloud-d...

Edit: I'd be interested in hearing why people object to this comment.

Post reply on HN