Why Databases Are Not for Docker Containers • Hacker News Board

Re: Why Databases Are Not for Docker Containers

#181

Post by mstump » Mon, Feb 13, 2017, 11:10 PM UTC

user5994461 wrote: post #168

mstump wrote: post #163

Earlier quoted context omitted.

It's a mix. I'm a consultant that specializes in large scale distributed systems. I have some customers that have >100k production database nodes. I manage probably >50PB of data. I have designed large distributed systems for more than 100 customers.

consultant = charge > £600 a day to bring Docker to the company. Yet doesn't care when shit hits the fan 3 months later because he's already gone. In fact, he will never known about it. By the way, How to have 100 customers => leave right after the design phase every single time. Clients add up quickly.

I do a mix of pure consulting but also managed services. I typically have a 12 hour SLA for issues, and 1 hour SLA for some customers. 24/7 support for mission critical, revenue generating systems. So no, I'm not just a talking head. It's usually me in the NOC on the hook in case things go wrong. I'm the world expert in this field, if you want things to work at scale people call me.

Re: Why Databases Are Not for Docker Containers

#182

Post by mstump » Mon, Feb 13, 2017, 11:13 PM UTC

carterehsmith wrote: post #177

mstump wrote: post #163

Earlier quoted context omitted.

It's a mix. I'm a consultant that specializes in large scale distributed systems. I have some customers that have >100k production database nodes. I manage probably >50PB of data. I have designed large distributed systems for more than 100 customers.

Nice. 100K database nodes! Is that like, Facebook or Twitter? I hope you write about that somewhere.

Very large companies, mostly banks, retailers and telecom. Some industrial IoT and a couple governments.

Re: Why Databases Are Not for Docker Containers

#183

Post by mstump » Mon, Feb 13, 2017, 11:16 PM UTC

user5994461 wrote: post #168

mstump wrote: post #163

Earlier quoted context omitted.

It's a mix. I'm a consultant that specializes in large scale distributed systems. I have some customers that have >100k production database nodes. I manage probably >50PB of data. I have designed large distributed systems for more than 100 customers.

consultant = charge > £600 a day to bring Docker to the company. Yet doesn't care when shit hits the fan 3 months later because he's already gone. In fact, he will never known about it. By the way, How to have 100 customers => leave right after the design phase every single time. Clients add up quickly.

Individually I charge several orders of magnitude greater than what you're quoting. I'll advise and design, do deep troubleshooting etc.. Consultants that work for me (I'm the CEO) or a large SI will do the implementation.

Re: Why Databases Are Not for Docker Containers

#184

Post by mstump » Mon, Feb 13, 2017, 11:21 PM UTC

tayo42 wrote: post #131

mstump wrote: post #7

Earlier quoted context omitted.

I've been running a couple of petabytes in production with Docker and Cassandra for a couple years (around 2k nodes). I've rarely seen FS corruption, however I must qualify that this is on bare metal. They could be running into issues with the interaction with EBS? This is more of a screed than an argument backed by specific details and facts.

How do you handle making updates to configuration with all your nodes in containers? Do you blue green deploy the cluster or something? Run config management in the container?

Configuration comes from the environment. We store the configuration per cluster in a centralized store (C*, etcd, SimpleDB). We bake images that contain everything else.

Depending on the customer and the tech involved we'll do blue-green by doing a controlled rolling push of the config or image after it makes it through the dev/test cycle. Also depending on the type of tech we'll store actual data on network or host volumes.