Live data from Hacker News

I Want to Run Stateful Containers, Too

techcrunch.com

31–40 of 102 posts

Re: I Want to Run Stateful Containers, Too

#31

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…

This is especially true when you consider what that same $1500/mo will buy you using something like DynamoDB or Aurora. Both those solutions will give you more storage, are managed for you and will mostly scale up with you, meaning you don't have to start anywhere near $1500/mo.

I know the article said tying yourself to Amazon feels wrong. But focusing your time and energy on managing infrastructure that could be managed by Amazon instead of focusing your time and energy on your product feels more wrong to me. There are exactly zero startups that have succeeded because they had a more reliable and performant MongoDB installation.

Re: I Want to Run Stateful Containers, Too

#32
post #3

I think the author is implicitly describing the paradigm shift from software and hardware abstractions to service abstractions. We used to make computers by soldering electronics together, then by assembling cases and components, then buying premade servers, then renting cloud capacity, and now we're starting to rent everything as services. The cloud is about going from capex to opex and the "capex" now is the initia…

How does OpenStack stack up in this regard? A step in the right direction? https://en.wikipedia.org/wiki/OpenStack

If you want to run your own infrastructure from the ground up, maybe. Ironic (bare metal deploys) + Magnum (container deploys with Kubernetes) is exciting in that area, but as someone who wrote and ran an OpenStack cloud, I wouldn't recommend it. For most people, something like ECS/GKE/bare Kubernetes on a cloud provider is a decent step in that direction.

Re: I Want to Run Stateful Containers, Too

#33
While I agree with the author of this article from the perspective of the engineer who likes to tinker with things and roll my own stuff I must disagree from the business perspective.

From the business perspective a PaaS solution costs one dollar amount and a custom, hand rolled, stateful solution built and maintained by engineers costs another dollar amount.

With offerings from AWS the former will almost always beat the later. It's not until you reach Facebook or Google level scale that the monthly savings from the latter can outweigh the benefits of just using an AWS solution like DynamoDB or ECS, etc.

Re: I Want to Run Stateful Containers, Too

#34

How much of this could be avoided if the application didn't use mongo? Needing to run a three-nice cluster out of the gate seems like a big part of the problem. Sure, you want backups and redundancy for any database, but there are situations where a MySQL or pg slave that can be switched on makes more sense financially, especially if load doesn't require a three-node cluster.

That was my first thought, too. If the author didn't insist on using mongo, he could have opted for an inexpensive RDS setup.

Re: I Want to Run Stateful Containers, Too

#35
post #3

I think the author is implicitly describing the paradigm shift from software and hardware abstractions to service abstractions. We used to make computers by soldering electronics together, then by assembling cases and components, then buying premade servers, then renting cloud capacity, and now we're starting to rent everything as services. The cloud is about going from capex to opex and the "capex" now is the initia…

>The cloud is about going from capex to opex and the "capex" now is the initial work needed to define your own architectures and stacks for every project (before you get to work on the actual project, i.e. the differentiating part). Amazon is eliminating most of this by offering building block services that fit together with little hassle.

Maybe they are eliminating it for themselves, but if they are eliminating most of that for you, then that contradicts your prior thesis. You aren't defining your own architecture then, you are just conceding to becoming a part of Amazon's architecture. Amazon will lock you into their ecosystem as much as possible. As Amazon's ecosystem fills up with services, there will be little to differentiate your service from any other Amazon hosted/run service.

A much better idea would be to have architectures that don't depend on any specific vendor or company, which are deployable everywhere.

Re: I Want to Run Stateful Containers, Too

#36

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...

Looks like Kubernetes is improving. Hadn't seen this yet.

Sometimes it gets hard to follow everything in the Docker ecosystem.

Re: I Want to Run Stateful Containers, Too

#37

While I agree with the author of this article from the perspective of the engineer who likes to tinker with things and roll my own stuff I must disagree from the business perspective. From the business perspective a PaaS solution costs one dollar amount and a custom, hand rolled, stateful solution built and maintained by engineers costs another dollar amount. With offerings from AWS the former will almost always beat…

I agree about this right now.

But I think enough open source code will be made to fill this space.

It's just a matter of time.

Re: I Want to Run Stateful Containers, Too

#38

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...

Thanks, I wasn't aware of that.

Re: I Want to Run Stateful Containers, Too

#39
I believe part of what the author is looking for is currently being pushed by the Deis guys with Helm[1]. Think of it as a package manager for creating Kubernetes configurations. I think we'll see some stable and reusable templates for both stateful and stateless services there.

[1] https://helm.sh/

Re: I Want to Run Stateful Containers, Too

#40
If you're using AWS you can use a pre-task (i.e fleet unit file) to run something like https://github.com/leg100/docker-ebs-attach to attach an volume before running your container. You can also do this with Flocker(https://docs.clusterhq.com/en/1.7.2/config/aws-configuration...) if you want something fancier.

Still rather have AWS manage the data. Unless you're a really biggie sized company RDS/Elasticache are really good ideas. Managing data and databases are headaches I'll gladly outsource.

Post reply on HN