4 ms·

I don't get the author. So to sum it up, they like what Docker did with containers, but they don't want to use Docker, at least not immediately, because it requ

I don't get the author. So to sum it up, they like what Docker did with containers, but they don't want to use Docker, at least not immediately, because it requires to learn a few Docker commands and a bit other stuff and therefore they decided to build their own hybrid shit, which will take them probably more time to build than to learn Docker and then on top of that still need to train their employees on that as well, instead of using a well working, vibrant, healthy eco system, build by someone else, for free? I cannot help myself but that sounds like the worst idea ever and totally backwards. Particularly when they she said that they want to run containers reliably in production, how do they think they are going to do this? The reason why Docker is a "little" bit more than just `Docker run` is so you can run containers reliably and in case of a fail over recover quickly. So how are they planning to run containers reliably in production without adopting an existing, well tested, well working framework?

fauigerzigerk 10y ago
>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.
- dustinmoris 10y ago
  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.
  - lmm 10y ago
    The whole "vertical change vs horizontal change" section of the article is literally all about this exact subject.
    - dustinmoris 10y ago
      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.
pandog 10y ago
> 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.
perlpimp 10y ago
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.

fauigerzigerk 10y ago

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

dustinmoris 10y ago
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.
- lmm 10y ago
  The whole "vertical change vs horizontal change" section of the article is literally all about this exact subject.
  - dustinmoris 10y ago
    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.

pandog 10y ago

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

perlpimp 10y ago

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.