6 ms·

> Kubernetes is a component...while Docker is a platform which integrates many components...So Docker and Kubernetes are not directly competitive I wonder whet

by curun1r 10y ago

> Kubernetes is a component...while Docker is a platform which integrates many components...So Docker and Kubernetes are not directly competitive I wonder whether this is a distinction that exists in your mind, as someone intimately involved in the development of the docker tool and the Docker, Inc business model more so than in the minds of Docker users. You have a vested interest in making Docker encompass all that Docker, Inc produces. For many of us, this is actually against our interests. A lot of us want Docker to just be the base containerization layer with other offerings (like k8s, swarm, etc) built on top of it and branded separately. Continually adding more to the docker base layer adds confusion in the minds of people who don't follow Docker closely, makes it harder to get it approved for use in our organizations and increases the security footprint that needs to be audited. I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else rather than trying to stuff everything into one tool with one name. You have no idea how hard some of us have had to fight inside our organizations to simply deploy builds inside containers. Increasing the scope of what Docker means is just giving ammunition to our internal opponents. I understand why you're doing what you're doing...there's no money in developing that base layer unless you can parlay it into selling the other parts of your platform, but just understand that what you're doing isn't really user-friendly and many users won't pliantly go along with whatever marketing decisions you make. Like it or not, Docker is an ecosystem, not a platform. It has a life of its own that you're only partially able to shape. You have the advantage of being able to shape the roadmap for the underlying containerization layer and the goodwill that comes from putting in the work to have created initially and maintain that layer on an ongoing basis. That should be enough without leveraging it further.

shykes 10y ago
> I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else We are doing exactly that. The base containerization layer is containerd, and it is now available standalone separate from Docker. I covered this topic in more detail in another comment: https://news.ycombinator.com/item?id=13775677 https://news.ycombinator.com/item?id=13775677 I hope this helps.
- curun1r 10y ago
  Again, that's a relatively-recent branding decision on your part. It's pretty meaningless to people that have spent more than a year trying to explain to people what Docker is and why we should use it. Trying to go back to those people now to switch terminology is, at best a massive headache and, at worst, going to get containerization efforts canceled.
  - shykes 10y ago
    I'm not sure I understand the problem. Whatever containerization project you were building on top of Docker, it is just as viable today as yesterday. No option has been removed - if anything there are now more options available to you. All new versions of Docker remain backwards-compatible with previous versions. And components of Docker which were previously not available standalone, now are. What exactly would you like Docker to do, that we're not currently doing?
    - curun1r 10y ago
      What you're missing is the ecosystem vs platform distinction. A platform is yours to control and an ecosystem has a life of its own. You're right that everything that was possible still is. But docker, as a term, developed in ways not controlled by you. It took on a meaning that's probably more limited than you'd like. And it developed momentum that can't be stopped or diverted by a marketing strategy and a press release from Docker, Inc. You're not the first company that's had to deal with this. To me, it's similar to Google's failed attempts to keep people from using their name as a verb. You're both companies that has a wildly successful initial product that got associated with your company's name and that hindered attempts to branch out from that initial offering. But the more you try to repurpose the term to refer to your broader offering rather than the narrower base layer that it started out as, the more you create problems for those of us that have spent a lot of time and effort selling your approach within our organizations. Not everyone is sold on containerization and we (your advocates) have people that will pounce on any confusion as a way to push back. Decision-makers in organizations are often surprisingly non-technical. Imagine if there were a company behind email. And that company wanted to make money selling add-on services like encryption and mailing list management. So it decided to call the base email layer libsmtpd and repurpose the term email to mean the broader platform offering. Now imagine you've got to explain this change to your elderly mother who's just gotten over the hump and gotten comfortable with sending email and referring to email correctly. That's kinda the position you're putting us in.

by curun1r 10y ago

shykes 10y ago

> I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else We are doing exactly that. The base containerization layer is containerd, and it is now available standalone separate from Docker. I covered this topic in more detail in another comment: https://news.ycombinator.com/item?id=13775677 https://news.ycombinator.com/item?id=13775677 I hope this helps.

curun1r 10y ago
Again, that's a relatively-recent branding decision on your part. It's pretty meaningless to people that have spent more than a year trying to explain to people what Docker is and why we should use it. Trying to go back to those people now to switch terminology is, at best a massive headache and, at worst, going to get containerization efforts canceled.
- shykes 10y ago
  I'm not sure I understand the problem. Whatever containerization project you were building on top of Docker, it is just as viable today as yesterday. No option has been removed - if anything there are now more options available to you. All new versions of Docker remain backwards-compatible with previous versions. And components of Docker which were previously not available standalone, now are. What exactly would you like Docker to do, that we're not currently doing?
  - curun1r 10y ago
    What you're missing is the ecosystem vs platform distinction. A platform is yours to control and an ecosystem has a life of its own. You're right that everything that was possible still is. But docker, as a term, developed in ways not controlled by you. It took on a meaning that's probably more limited than you'd like. And it developed momentum that can't be stopped or diverted by a marketing strategy and a press release from Docker, Inc. You're not the first company that's had to deal with this. To me, it's similar to Google's failed attempts to keep people from using their name as a verb. You're both companies that has a wildly successful initial product that got associated with your company's name and that hindered attempts to branch out from that initial offering. But the more you try to repurpose the term to refer to your broader offering rather than the narrower base layer that it started out as, the more you create problems for those of us that have spent a lot of time and effort selling your approach within our organizations. Not everyone is sold on containerization and we (your advocates) have people that will pounce on any confusion as a way to push back. Decision-makers in organizations are often surprisingly non-technical. Imagine if there were a company behind email. And that company wanted to make money selling add-on services like encryption and mailing list management. So it decided to call the base email layer libsmtpd and repurpose the term email to mean the broader platform offering. Now imagine you've got to explain this change to your elderly mother who's just gotten over the hump and gotten comfortable with sending email and referring to email correctly. That's kinda the position you're putting us in.