4 ms·

> When people understand that they can easily make the choice to swap out the container runtime, and the knowledge is out there and easily and readily available

by zmmmmm 8y ago

> When people understand that they can easily make the choice to swap out the container runtime, and the knowledge is out there and easily and readily available, I do not think there is any reason for us to user docker any more and therefore Docker as a technology and as a company will slowly vanish How about MySQL as a counter argument? It's always been feature-weak compared to PostgresQL, with a less business friendly license and now owned by one of the most despised software companies by technologists. But it's probably still the default relational database people pick up. Habit, defaults and massive installed base can go a long, long way.

kikoreis 8y ago
You are right, but it is hard to see how for profit Docker Inc benefits from that. MySQL had a business model that was similarly challenging, which lead to where it is today.
- user5994461 8y ago
  MySQL has a strong ecosystem model and it's a pain to switch databases. Young developers used to get a LAMP stack, Linux Apache MySql Php and that comes with MySQL. There are many products, one could say even languages, that require MySQL. The database is the hardest component to switch and even if the company were to disappear today, it would take decades to migrate off. Docker has none of this. It only happened a few years ago, it will be gone as quickly. It doesn't even have a strong brand name, people want kubernetes not docker, docker is merely a dependency that can be replaced.
  - kikoreis 8y ago
    Yeah, I agree. MySQL was in a more robust position, and even then the outcome was disappointing. Open source business is tough.
imhoguy 8y ago
Container engine is just a wrapper around couple of Linux APIs mainly cgroups & namespaces & iptables/BPF - there is most of hard work done. A good example how trivially it can be implemented is this: https://news.ycombinator.com/item?id=9925896 https://news.ycombinator.com/item?id=9925896 Now, implementing DBMS with even basic SQL query language, is not a trivial job.
- cpuguy83 8y ago
  That's funny because getting these things right (without security issues) is quite difficult.
  - 013a 8y ago
    Its very likely that most of the challenging security stuff will continue to move down into the kernel itself. Its important to remember that the entire concept of a container wasn't really a single unified concept in the Kernel until very recently as they've gained popularity; instead, they were a amalgamation of a few different capabilities in the kernel.
    - fatherlinnux 8y ago
      Perhaps, you caught news of something I haven't seen, but AFAIK, "container" is still defined in user space. Talking to Eric Biederman, that's what the kennel team wants - people to experiment in user space, remixing kernel tech together...
      - cpuguy83 8y ago
        There's a new-ish (from Feb) LWN article about container's as an object in the kernel: https://lwn.net/Articles/780364/ https://lwn.net/Articles/780364/ Reception still doesn't seem great.
xorcist 8y ago
> It's always been feature-weak compared to PostgresQL, That's not really a meaningful statement to make. A singular "better" seldom exists outside children's discussions. MySQL for a long time had a more compelling multi-master situation, for example, and was simpler to operate as there was no need to schedule vacuums and fewer reasons to stop the database during normal operation. But none of that is really relevant for choosing a database. It's an enabler technology, just like an operating system. You seldom set out to use a certain database, you set out to use a certain application and then choose a database and an operating system that fits the application's use case. None of that is true for containerization technology. Any requirements come instead from the infrastructure layer, and the application is made to fit those instead of the other way around. Other than that, you are free to choose whatever has the least complex operational requirements. If I was an investor in Docker Inc. I'd carefully consider what that means.
ericb 8y ago
> It's always been feature-weak compared to PostgresQL For many years MySQL had a much clearer multi-master replication story than PostgresQL. For most use cases, other features are secondary to replication.
- CWuestefeld 8y ago
  For most use cases, other features are secondary to replication. I'd say the opposite - for most use cases, replication doesn't even figure into it. I guess we both need to find more solid evidence than our own opinions.
  - ericb 8y ago
    I suppose if you reason from some other criteria than avoiding downtime and data loss, a different conclusion was possible at the time. To each their own.
    - CWuestefeld 8y ago
      Replication is not the best way to avoid data loss. And it's not the only way to avoid downtime (e.g., the AWS Aurora PostgreSQL servers I run don't use the normal pg replication). And there are a lot of systems for which downtime really is acceptable, at least for the amount of time it takes to restore a backup. Not everything is a front-end, mission critical system. I manage plenty of systems that are only used in a back-end batch context. So I think it's crazy to suggest that how well a db engine's replication work outweighs all other factors. Depending on your situation it may well be the most important thing, but there's a lot of room for others to have well-architected systems that have different priorities.
takeda 8y ago
Until few years ago PostgreSQL was dramatically slower than MySQL. As for features it depends how you look for it. From what it can do in terms of queries it was more powerful than MySQL, because MySQL just stopped on SQL-92. PostgreSQL also lacked in operational functionality. For example in older version it was your responsibility to take care of shopping WAL files to standby nodes. The PostgreSQL unlike MySQL has a rule that is they implement a feature they want to do it right. It is better to not have the feature than have it and it could cause data corruption. MySQL on the other hand starts with MVP so they can put a check mark and then later work on improving it and fixing bugs. In past year, PostgreSQL not only caught up but also surpassed MySQL in terms of performance (I think MySQL might still be faster if you mostly read the data, but I'm not sure) and operational features, so at this point not only you have as fast (and actually faster for writing workload) but also have more features and much much better reliability. So it is no brainier to use it right now, but earlier you had to choose what was more important to you.
GordonS 8y ago
MySQL always had a really good, free GUI, Postgres didn't. There is pgAdmin now, but a lot of people really don't like it (I've had lots of problems with it myself). MySQL also had (relatively) straightforward replication features since way back, something that is much newer to Postgres. For info, I used MySQL for over a decade, and am a relatively recent convert to Postgres - and I love it!

by zmmmmm 8y ago

kikoreis 8y ago

You are right, but it is hard to see how for profit Docker Inc benefits from that. MySQL had a business model that was similarly challenging, which lead to where it is today.

user5994461 8y ago
MySQL has a strong ecosystem model and it's a pain to switch databases. Young developers used to get a LAMP stack, Linux Apache MySql Php and that comes with MySQL. There are many products, one could say even languages, that require MySQL. The database is the hardest component to switch and even if the company were to disappear today, it would take decades to migrate off. Docker has none of this. It only happened a few years ago, it will be gone as quickly. It doesn't even have a strong brand name, people want kubernetes not docker, docker is merely a dependency that can be replaced.
- kikoreis 8y ago
  Yeah, I agree. MySQL was in a more robust position, and even then the outcome was disappointing. Open source business is tough.

imhoguy 8y ago

Container engine is just a wrapper around couple of Linux APIs mainly cgroups & namespaces & iptables/BPF - there is most of hard work done. A good example how trivially it can be implemented is this: https://news.ycombinator.com/item?id=9925896 https://news.ycombinator.com/item?id=9925896 Now, implementing DBMS with even basic SQL query language, is not a trivial job.

cpuguy83 8y ago
That's funny because getting these things right (without security issues) is quite difficult.
- 013a 8y ago
  Its very likely that most of the challenging security stuff will continue to move down into the kernel itself. Its important to remember that the entire concept of a container wasn't really a single unified concept in the Kernel until very recently as they've gained popularity; instead, they were a amalgamation of a few different capabilities in the kernel.
  - fatherlinnux 8y ago
    Perhaps, you caught news of something I haven't seen, but AFAIK, "container" is still defined in user space. Talking to Eric Biederman, that's what the kennel team wants - people to experiment in user space, remixing kernel tech together...
    - cpuguy83 8y ago
      There's a new-ish (from Feb) LWN article about container's as an object in the kernel: https://lwn.net/Articles/780364/ https://lwn.net/Articles/780364/ Reception still doesn't seem great.

xorcist 8y ago

> It's always been feature-weak compared to PostgresQL, That's not really a meaningful statement to make. A singular "better" seldom exists outside children's discussions. MySQL for a long time had a more compelling multi-master situation, for example, and was simpler to operate as there was no need to schedule vacuums and fewer reasons to stop the database during normal operation. But none of that is really relevant for choosing a database. It's an enabler technology, just like an operating system. You seldom set out to use a certain database, you set out to use a certain application and then choose a database and an operating system that fits the application's use case. None of that is true for containerization technology. Any requirements come instead from the infrastructure layer, and the application is made to fit those instead of the other way around. Other than that, you are free to choose whatever has the least complex operational requirements. If I was an investor in Docker Inc. I'd carefully consider what that means.

ericb 8y ago

> It's always been feature-weak compared to PostgresQL For many years MySQL had a much clearer multi-master replication story than PostgresQL. For most use cases, other features are secondary to replication.

CWuestefeld 8y ago
For most use cases, other features are secondary to replication. I'd say the opposite - for most use cases, replication doesn't even figure into it. I guess we both need to find more solid evidence than our own opinions.
- ericb 8y ago
  I suppose if you reason from some other criteria than avoiding downtime and data loss, a different conclusion was possible at the time. To each their own.
  - CWuestefeld 8y ago
    Replication is not the best way to avoid data loss. And it's not the only way to avoid downtime (e.g., the AWS Aurora PostgreSQL servers I run don't use the normal pg replication). And there are a lot of systems for which downtime really is acceptable, at least for the amount of time it takes to restore a backup. Not everything is a front-end, mission critical system. I manage plenty of systems that are only used in a back-end batch context. So I think it's crazy to suggest that how well a db engine's replication work outweighs all other factors. Depending on your situation it may well be the most important thing, but there's a lot of room for others to have well-architected systems that have different priorities.

takeda 8y ago

Until few years ago PostgreSQL was dramatically slower than MySQL. As for features it depends how you look for it. From what it can do in terms of queries it was more powerful than MySQL, because MySQL just stopped on SQL-92. PostgreSQL also lacked in operational functionality. For example in older version it was your responsibility to take care of shopping WAL files to standby nodes. The PostgreSQL unlike MySQL has a rule that is they implement a feature they want to do it right. It is better to not have the feature than have it and it could cause data corruption. MySQL on the other hand starts with MVP so they can put a check mark and then later work on improving it and fixing bugs. In past year, PostgreSQL not only caught up but also surpassed MySQL in terms of performance (I think MySQL might still be faster if you mostly read the data, but I'm not sure) and operational features, so at this point not only you have as fast (and actually faster for writing workload) but also have more features and much much better reliability. So it is no brainier to use it right now, but earlier you had to choose what was more important to you.

GordonS 8y ago

MySQL always had a really good, free GUI, Postgres didn't. There is pgAdmin now, but a lot of people really don't like it (I've had lots of problems with it myself). MySQL also had (relatively) straightforward replication features since way back, something that is much newer to Postgres. For info, I used MySQL for over a decade, and am a relatively recent convert to Postgres - and I love it!