Hacker News Reader

>Particularly when they she said that they want to run containers reliably in production, how do they think they are going to do this?

As I understand it, they keep doing what they have been doing all along, including everything that currently makes their system reliable, and gradually add some of the desirable features of containers in a way they can fully understand.

That doesn't sound like the worst idea ever to me. The danger of ending up with too much of a homegrown snowflake is of course real. You're not wrong about that. But she described the risks of the alternative approaches pretty well I think.

I don't get what the issue is with the migration plan to Docker either. You have a big system with many components. The best way to start is build a Hello world app on Docker and orchestrate it with whatever framework you think suits best your requirements, let's say Kubernetes. Then run that hello world stuff for a while to get a POC and make yourself familiar with the sytem. After that start converting 1 of the many services to a dockerized service and run it side by side in your new infrastructure. Maybe even load balance some of the traffic progressively over to the new stuff until you are confident enough to run 100% load on that migrated servcie. By then you should be pretty experienced with the most part and have a great recipe to migrate the rest slowly over. I don't see a reason why you would want to start with a homegrown solution at any point in this process.

The whole "vertical change vs horizontal change" section of the article is literally all about this exact subject.

Yeah and I don't see how that is any good. Making small changes across your entire infrastructure means that everything will move extremely slowly. I cannot imagine that the entire infrastructure even deserves to be moved. What's wrong by just leaving some really old, solid working, but less critical stuff just on the old infrastructure until it gets phased out one day? It feels like a waste of time and resources to force a horizontal move across everything. Also technologies like containers and Docker are extremely fast moving at the moment. It might very well be that some parts cannot be moved immediately today, but in 6-12 months time they can and if you follow their migration plan then meanwhile a whole lot of other stuff which could really benefit from the new infrastructure will have to miss out. Also if you discover an issue very late then you ended up with moving a lot of things back and fourth, even if it is just a small step.

> but they don't want to use Docker, at least not immediately, because it requires to learn a few Docker commands

That's not what the blog post says. They don't want to use docker because it does a lot of things. They use rkt because it does fewer things. It's not about learning commands, it's about complexity of software. They selected rkt because it does less stuff, not because it's easier to learn.

article is really low on details. they use naked lxc? what does it mean just launch containers in docker and rkt? wishy washy it sounds to me. I want details.