8 ms·

I love Kubernetes, but this documentary makes me sad. The story of PaaS is absolutely worthy of a documentary, but to imply that Google is the protagonist is ju

by tombh 5y ago

I love Kubernetes, but this documentary makes me sad. The story of PaaS is absolutely worthy of a documentary, but to imply that Google is the protagonist is just pandering to the "rich kid" who brought little more to the table than money and influence. Here's a better sketch for the story. It starts with Ruby, itself a game-changing language, that inspired a new culture of developer-centric best practices like Rspec's TDD and Bundler's lockfiles. Ruby made the first PaaS possible, Heroku (a YC startup), which itself inspired a whole new way of thinking about software. I don't think enough people realise just how influential Heroku's 12 Factor App manifesto[1] was, in fact I'd argue it's the real hero in this whole story. The 12 Factors are just text, it's not even software or hard and fast requirements, they're merely best practices for the entire experience of writing, collaborating, testing, deploying, scaling and maintaining software. The 12 Factors aren't just about pushing your app on Kubernetes or whatever, they're just as much, if not more so, ideas that make _you_ a better engineer. Heroku made money for sure, but they did something beyond money, they upped the level of our craft as a whole. The central concept in Heroku is the dyno. If you follow the 12 Factors, then you magically get almost infinitely scalable dynos. It plays right into the heart of the new gold rush world of startups, where anybody can have an app idea and leverage the global marketplace with the abstractions of datacentres and the cloud. Docker is the open source dyno. So many PaaS projects apart from Kubernetes have risen and fallen around Docker. Deis, Flynn, Dokku, Swarm, to name but a few. So many of the core concepts of Kubernetes were innovated and explored, and arguably mastered, before Kubernetes came on the scene. Kubernetes is a success not because of its innovation, but because it's backed by The Rich Kid. The world was already heading in this direction, Google just threw big numbers at it to make sure they took the biggest piece of the pie. 1. https://12factor.net https://12factor.net

xcambar 5y ago
I've been involved in multiple migrations to public cloud infrastructure (some were unnecessary, but such are the trends...), and without failure, the 12 factors manifesto shows up in the very first days of the discussions as the first target to reach before anything else is doable. I very much enjoy it and I'm glad whether I see someone mention it or I can spread and teach its wisdom.
cbb330 5y ago
This is an interesting story but it’s nothing more than fan fiction. Please provide some reason for your assertions. While the entire comment could be contradicted, a quick example is that google’s SRE book details much more developer strategies, including from a massive scale and enterprise perspective, than 12 factor web app. This book was assembled but industry experts with experience from Borg, with borg emerging from the global work queue — decades before heroku existed.
- tombh 5y ago
  > google’s SRE book details much more developer strategies [...] than 12 factor web app I would argue that's precisely the problem. Google are clearly capable of doing complex things, but inspiring and nurturing an entire cultural shift is a different category of "complexity", which in the story of Paas, Google did not achieve, they merely exploited it.
  - joshuamorton 5y ago
    You seem to be arguing against yourself here though. Kubernetes is successful, and it doesn't precisely fit the mold of the 12 factor app. It fits an overlapping but distinct, google style, development model. They successfully achieved that shift. I think you're arguing that that's a bad thing. But it's a thing that very much did happen, because kubernetes is successful.
    - tombh 5y ago
      My thesis isn't that Kubernetes isn't good, nor that it isn't successful (I use it, recommend it and am deeply grateful for it). Rather I'm disappointed that the documentary doesn't pay respects to the milieu that primed the world for Kubernetes, which to me makes it seem like Google also inspired the mindset and demand for something like Kubernetes, which I personally believe is inaccurate and more importantly unfair on the many innovative projects upon whose shoulders Kubernetes stands.
      - andrewmutz 5y ago
democracy 5y ago
I think GAE (Google App Engine) was in production before Heroku got anything out there...
- tombh 5y ago
  Yes they were. But like I say, I think the 12 Factors were more important. And Heroku in general just understood hacker culture better.
- fomine3 5y ago
  GAE was also a hero, but too early for non-Googler.
throwaway894345 5y ago
I think you're very deeply immersed in the Ruby/Heroku world and projecting that onto Kubernetes and everything else. Kubernetes' derives from Google's lengthy experience with Borg, which almost certainly predates Heroku. I doubt very much that Google was steeped in Heroku/Ruby culture. Yes, Heroku dynos are similar to linux containers, but containerization (the idea of binning multiple applications onto a single operating system instance) predates heroku by at least 6 years and the idea of binning multiple applications onto a single hardware instance goes back much further. Moreover, Kubernetes and Heroku aren't even in the same class of tools. Kubernetes is an orchestrator for containers, which obviously can be used as the foundation for a PaaS, but Kubernetes isn't itself a PaaS even when you consider the various managed Kubernetes offerings which include some higher level abstractions built atop Kubernetes primitives. Further still, it's not like Google marketed Kubernetes to any significant degree prior to its own adoption of Kubernetes as its official container orchestration offering for its cloud (which was after the writing had been on the wall for a while that Kubernetes would become the de facto container orchestrator). TL;DR: Just because other tools and technologies predated Kubernetes didn't imply that it was significantly impacted by them.
- tombh 5y ago
  I haven't written Ruby nor used Heroku in many years. I think it's more relevant to say I'm very deeply immersed in Open Source. I contributed to OpenRuko[1], Deis, Flynn and even wrote my own PaaS, Peas[2] that got on the front page of HN. I've seen first hand the journey that PaaS has taken. Maybe we're getting hung up on the strict definition of PaaS here. Let's just say the thing that lets us easily scale a startup idea, like Uber, Airbnb etc. Sure the dyno/docker is the core component, but we inevitably have to deal with state, Redis, Postgres etc as well. In that sense Kubernetes is very much the Open Source version of Heroku. I think it's fairer to say that Google _repurposed_ Borg, in order not to be left out of the changing landscape. Borg may be the technical predecessor to Kubernetes, but my point is that Borg is very much not the spiritual ancestor of the new containerised paradigm. 1. https://github.com/openruko https://github.com/openruko 2. https://github.com/tombh/peas https://github.com/tombh/peas
  - 5y ago
p_l 5y ago
Except k8s is really, really not a PaaS. It can be used to build a PaaS in style of Heroku, but it's not one. It's lineage spans all the way back to IBM ASP in 1967, arguably even to 7094/7044 directly-coupled system (but that didn't have multiple worker nodes), hitting various systems on the way (TOPS-20 Galaxy, VMScluster, HPC scheduling systems for MPP supercomputers and probably many more I can't recall). It's about efficient use of multiple machines, or as Google & ex-Google employees called it in a book released at similar time as Heroku went from private beta to GA, "Datacenter as a Computer". 12 factors were important, but they just as well can apply to noncontainerised software (arguably, they are just as valid in the ~2000 world of EJB java servers, except replace "environment variables" and the like with JNDI). That said, Rails exploding in popularity around the same time as EC2 became an option heavily helped push the generic case out of the hell of PHP with occasional CGI (ASP usually meant you had more resources than shared hosting from hell)
- tombh 5y ago
  I think you're missing my point. We're on HN right, where we often discuss the difference between technical merit and market fit. There's a time and a place for technically correct solutions, which Google excel at, but a successful business needs more than that, it needs to capture a zeitgeist, which Google sometimes fail to do, see Google Plus for example. Of course the technical lineage of Kubernetes is Borg and parents (which I admit I've never heard of), but I put it to HN that Kubernetes' lineage is not what created the market fit. In fact I think it's disingenuous of the documentary to imply that (in fairness it does give time to Docker), hence why I'm so keen to give my version of events. Your point about how The 12 Factors apply just as well to non-containerised software is exactly the beauty of them! The 12 Factors don't come from management, they're not an attempt (at least directly) to capture profit from a market. They are somehow fundamental axioms about writing software in this current era, they're maybe even self-evident, universal truths. It turns out that there is a fundamental connection between the ability for a piece of software to be efficiently scaled and for that piece of software to be collaborated on. 2 or more developer machines share essential characteristics with 2 or more scaled containers, which share requirements with 2 or more CI instances ― reproducibility, behaviour guaranteed by tests, ease of downloading, security, configurability through ENV. You see how we felt like Heroku understood us the humble developer, it made us DevOps, all whilst helping us satisfy the bottom line of managers? Kubernetes is truly an extraordinary piece of software, but it hasn't, nor do I believe it ever will, achieve anything of The 12 Factors' lasting legacy.
Aterio 5y ago
I was never really aware of heroku. I knew app engine and other things for much longer. I would not subscribe to your interpretation.
sien 5y ago
Scale - How Cloud Computing took over the World. (This is describing a book that would be interesting to read). Chapter 1 - Cobol on the Mainframe A description of how the world's financial infrastructure ran on mainframes from the 1970s onward. Chapter 2 - The rise of the Internet A quick description of the take off the internet and how companies would scale on the internet. Ops teams of hundreds and Solaris machines in data centers. Chapter 3 - Containerization, Virtualisation and Separation of process/progams The technological routes of virtualisation and containerisation, from the Mainframe to jails to containers. Chapter 4 - Scaling by the majors A description of Google, Microsoft, Yahoo and others scaled their own operations in the early 2000s. Chapter 5 - Selling Scale Heroku and then the birth of AWS. Chapter 6 - Everyone in the Cloud The growth of Cloud Computing with AWS, Azure, GCP, OCP, Hetzner, Digital Ocean etc, etc.
nickjj 5y ago
> The 12 Factors aren't just about pushing your app on Kubernetes or whatever, they're just as much, if not more so, ideas that make _you_ a better engineer. This is absolutely true, you can build a well factored app with intent to run it on 1 server. I would say it's very much worth it because adhering to these best practices will not only make maintenance of your app easier but it'll make things SO much easier to move from 1 server to multiple servers later on if you need to where "servers" in this case could be a Kubernetes cluster, Heroku or anything in between. If anyone is curious I recently put out a 90 minute ad-free video going over how to create a 12 factor app with a Dockerized app at https://nickjanetakis.com/blog/creating-a-twelve-factor-app-with-docker-that-also-works-on-kubernetes https://nickjanetakis.com/blog/creating-a-twelve-factor-app-.... It goes over the whole original 12 factor guide from start to finish and applies it to a code base. Even now 10+ years after the 12 factor guide was originally released it still very much applies today because the guidelines transcend technology. I remember reading this guide so many years ago and thinking "yep, this is it, they nailed it". So much goodness has come out of the Ruby community, especially around the idea of creating high quality services and tools built from really successful applications. In this case, the 12 factor guide is an extraction of best practices after running hundreds of thousands of apps on Heroku and Rails is an extraction of building Basecamp.
jbeda 5y ago
FWIW — we never viewed Kubernetes as a PaaS. We were informed by both Borg and GAE (and Heroku and PCF). The pattern that you see often with PaaS is that they work great until they don’t. When you want to do something that doesn’t fit the patterns that the PaaS was built for you are out of luck and pretty much have to drop down to VMs. We aimed to have k8s be something that was in the middle. Generic enough to work with a large number of workloads while providing significant advantages above raw VMs (and a level of consistency across infra providers). The tradeoff is that it is more complicated than the typical PaaS. That is the tradeoff. The goal then was to build kubernetes to be built upon. We never claimed to be solving the whole problem in one system. This is similar, in some ways, to the design of Mesos. But to do something new with Mesos requires an entirely different “framework” that exposes its own API. You see this with things like Marathon or Aurora or Chronos. While the underlying scheduler was shared across these there was no common API and so it was difficult for users to mix/match across these. By focusing on a consistent IaaS-ish API for k8s (and eventually, with CRDs, building extension mechanisms) we aimed to create an ecosystem of things building on k8s. Whereas PaaS are often a framework where you put your code in and a lot of decisions were made for you, I always viewed k8s as a toolkit where you get a lot of powertools that you can use in various ways. It is a very different philosophy. 12 factor and Docker obviously play a big part of this. And those built on experience and systems that came before them. We are all standing on the shoulders of those that came before us. For me, this API design experience was informed by my time at Microsoft. Things like VB and IE/web were very much, at that time a framework (the web is turning into a toolkit over time now). I saw, multiple times, how those things were super useful but were limited. Things like the CLR and the C# ecosystem evolved the VB model to be much more of a toolkit. We see this also in the Java world. I’m not an expert there, but the move from app servers to things like Spring Boot also show the shift from framework to toolkit. AWS itself is a toolkit. And IMO, the difference between something like lambda/faas and a PaaS is that lambda/faas only works when it is in context of the larger toolkit that is IaaS cloud. (I’m one of the founders of k8s and ended up with quite a bit of screen time in the documentary. My only regret is that more people that were so important in the k8s community couldn’t be featured!)
- tombh 5y ago
  Thanks for responding to my soap boxy opinions! I actually wrote my own complete PaaS from scratch once[1], and contributed to a number of other PaaS projects. I totally agree that PaaS projects work great until they don't. The reality is that a PaaS has to also be a Iaas, and yes Kubernetes really hits that middle ground. Thank you so much for your part in that. 1. https://github.com/tombh/peas https://github.com/tombh/peas
bytelines 5y ago
> Google just threw big numbers at it to make sure they took the biggest piece of the pie. And, ya know, invented cgroups and everything.
- tombh 5y ago
  If they were so innovative then why didn't they take the next step and make something like Docker?
  - bytelines 5y ago
    Because Docker is also innovative? What is your argument here? If Google doesn't innovate everything, it can't be innovative? This is nonsense.
    - tombh 5y ago
      I was put off by your sarcastic dismissive "Ya know". I may have a controversial opinion, but I don't think it warrants that kind of flippancy.
      - bytelines 5y ago
        I'm sorry - I'll try to be kinder. To explain myself, I too was put off by your dismissiveness of Googles own key contributions. But that doesn't mean I can't say that kindly. For whatever it's worth, you have a very cogent way of making your point.
        tombh 5y ago
        Thanks. I must admit I've learnt a lot about Google's contributions from this thread, so it's been productive overall.

by tombh 5y ago

xcambar 5y ago

I've been involved in multiple migrations to public cloud infrastructure (some were unnecessary, but such are the trends...), and without failure, the 12 factors manifesto shows up in the very first days of the discussions as the first target to reach before anything else is doable. I very much enjoy it and I'm glad whether I see someone mention it or I can spread and teach its wisdom.

cbb330 5y ago

This is an interesting story but it’s nothing more than fan fiction. Please provide some reason for your assertions. While the entire comment could be contradicted, a quick example is that google’s SRE book details much more developer strategies, including from a massive scale and enterprise perspective, than 12 factor web app. This book was assembled but industry experts with experience from Borg, with borg emerging from the global work queue — decades before heroku existed.

tombh 5y ago
> google’s SRE book details much more developer strategies [...] than 12 factor web app I would argue that's precisely the problem. Google are clearly capable of doing complex things, but inspiring and nurturing an entire cultural shift is a different category of "complexity", which in the story of Paas, Google did not achieve, they merely exploited it.
- joshuamorton 5y ago
  You seem to be arguing against yourself here though. Kubernetes is successful, and it doesn't precisely fit the mold of the 12 factor app. It fits an overlapping but distinct, google style, development model. They successfully achieved that shift. I think you're arguing that that's a bad thing. But it's a thing that very much did happen, because kubernetes is successful.
  - tombh 5y ago
    My thesis isn't that Kubernetes isn't good, nor that it isn't successful (I use it, recommend it and am deeply grateful for it). Rather I'm disappointed that the documentary doesn't pay respects to the milieu that primed the world for Kubernetes, which to me makes it seem like Google also inspired the mindset and demand for something like Kubernetes, which I personally believe is inaccurate and more importantly unfair on the many innovative projects upon whose shoulders Kubernetes stands.
    - andrewmutz 5y ago

democracy 5y ago

I think GAE (Google App Engine) was in production before Heroku got anything out there...

tombh 5y ago
Yes they were. But like I say, I think the 12 Factors were more important. And Heroku in general just understood hacker culture better.
fomine3 5y ago
GAE was also a hero, but too early for non-Googler.

throwaway894345 5y ago

I think you're very deeply immersed in the Ruby/Heroku world and projecting that onto Kubernetes and everything else. Kubernetes' derives from Google's lengthy experience with Borg, which almost certainly predates Heroku. I doubt very much that Google was steeped in Heroku/Ruby culture. Yes, Heroku dynos are similar to linux containers, but containerization (the idea of binning multiple applications onto a single operating system instance) predates heroku by at least 6 years and the idea of binning multiple applications onto a single hardware instance goes back much further. Moreover, Kubernetes and Heroku aren't even in the same class of tools. Kubernetes is an orchestrator for containers, which obviously can be used as the foundation for a PaaS, but Kubernetes isn't itself a PaaS even when you consider the various managed Kubernetes offerings which include some higher level abstractions built atop Kubernetes primitives. Further still, it's not like Google marketed Kubernetes to any significant degree prior to its own adoption of Kubernetes as its official container orchestration offering for its cloud (which was after the writing had been on the wall for a while that Kubernetes would become the de facto container orchestrator). TL;DR: Just because other tools and technologies predated Kubernetes didn't imply that it was significantly impacted by them.

tombh 5y ago
I haven't written Ruby nor used Heroku in many years. I think it's more relevant to say I'm very deeply immersed in Open Source. I contributed to OpenRuko[1], Deis, Flynn and even wrote my own PaaS, Peas[2] that got on the front page of HN. I've seen first hand the journey that PaaS has taken. Maybe we're getting hung up on the strict definition of PaaS here. Let's just say the thing that lets us easily scale a startup idea, like Uber, Airbnb etc. Sure the dyno/docker is the core component, but we inevitably have to deal with state, Redis, Postgres etc as well. In that sense Kubernetes is very much the Open Source version of Heroku. I think it's fairer to say that Google _repurposed_ Borg, in order not to be left out of the changing landscape. Borg may be the technical predecessor to Kubernetes, but my point is that Borg is very much not the spiritual ancestor of the new containerised paradigm. 1. https://github.com/openruko https://github.com/openruko 2. https://github.com/tombh/peas https://github.com/tombh/peas
- 5y ago

p_l 5y ago

Except k8s is really, really not a PaaS. It can be used to build a PaaS in style of Heroku, but it's not one. It's lineage spans all the way back to IBM ASP in 1967, arguably even to 7094/7044 directly-coupled system (but that didn't have multiple worker nodes), hitting various systems on the way (TOPS-20 Galaxy, VMScluster, HPC scheduling systems for MPP supercomputers and probably many more I can't recall). It's about efficient use of multiple machines, or as Google & ex-Google employees called it in a book released at similar time as Heroku went from private beta to GA, "Datacenter as a Computer". 12 factors were important, but they just as well can apply to noncontainerised software (arguably, they are just as valid in the ~2000 world of EJB java servers, except replace "environment variables" and the like with JNDI). That said, Rails exploding in popularity around the same time as EC2 became an option heavily helped push the generic case out of the hell of PHP with occasional CGI (ASP usually meant you had more resources than shared hosting from hell)

tombh 5y ago
I think you're missing my point. We're on HN right, where we often discuss the difference between technical merit and market fit. There's a time and a place for technically correct solutions, which Google excel at, but a successful business needs more than that, it needs to capture a zeitgeist, which Google sometimes fail to do, see Google Plus for example. Of course the technical lineage of Kubernetes is Borg and parents (which I admit I've never heard of), but I put it to HN that Kubernetes' lineage is not what created the market fit. In fact I think it's disingenuous of the documentary to imply that (in fairness it does give time to Docker), hence why I'm so keen to give my version of events. Your point about how The 12 Factors apply just as well to non-containerised software is exactly the beauty of them! The 12 Factors don't come from management, they're not an attempt (at least directly) to capture profit from a market. They are somehow fundamental axioms about writing software in this current era, they're maybe even self-evident, universal truths. It turns out that there is a fundamental connection between the ability for a piece of software to be efficiently scaled and for that piece of software to be collaborated on. 2 or more developer machines share essential characteristics with 2 or more scaled containers, which share requirements with 2 or more CI instances ― reproducibility, behaviour guaranteed by tests, ease of downloading, security, configurability through ENV. You see how we felt like Heroku understood us the humble developer, it made us DevOps, all whilst helping us satisfy the bottom line of managers? Kubernetes is truly an extraordinary piece of software, but it hasn't, nor do I believe it ever will, achieve anything of The 12 Factors' lasting legacy.

Aterio 5y ago

I was never really aware of heroku. I knew app engine and other things for much longer. I would not subscribe to your interpretation.

sien 5y ago

Scale - How Cloud Computing took over the World. (This is describing a book that would be interesting to read). Chapter 1 - Cobol on the Mainframe A description of how the world's financial infrastructure ran on mainframes from the 1970s onward. Chapter 2 - The rise of the Internet A quick description of the take off the internet and how companies would scale on the internet. Ops teams of hundreds and Solaris machines in data centers. Chapter 3 - Containerization, Virtualisation and Separation of process/progams The technological routes of virtualisation and containerisation, from the Mainframe to jails to containers. Chapter 4 - Scaling by the majors A description of Google, Microsoft, Yahoo and others scaled their own operations in the early 2000s. Chapter 5 - Selling Scale Heroku and then the birth of AWS. Chapter 6 - Everyone in the Cloud The growth of Cloud Computing with AWS, Azure, GCP, OCP, Hetzner, Digital Ocean etc, etc.

nickjj 5y ago

> The 12 Factors aren't just about pushing your app on Kubernetes or whatever, they're just as much, if not more so, ideas that make _you_ a better engineer. This is absolutely true, you can build a well factored app with intent to run it on 1 server. I would say it's very much worth it because adhering to these best practices will not only make maintenance of your app easier but it'll make things SO much easier to move from 1 server to multiple servers later on if you need to where "servers" in this case could be a Kubernetes cluster, Heroku or anything in between. If anyone is curious I recently put out a 90 minute ad-free video going over how to create a 12 factor app with a Dockerized app at https://nickjanetakis.com/blog/creating-a-twelve-factor-app-with-docker-that-also-works-on-kubernetes https://nickjanetakis.com/blog/creating-a-twelve-factor-app-.... It goes over the whole original 12 factor guide from start to finish and applies it to a code base. Even now 10+ years after the 12 factor guide was originally released it still very much applies today because the guidelines transcend technology. I remember reading this guide so many years ago and thinking "yep, this is it, they nailed it". So much goodness has come out of the Ruby community, especially around the idea of creating high quality services and tools built from really successful applications. In this case, the 12 factor guide is an extraction of best practices after running hundreds of thousands of apps on Heroku and Rails is an extraction of building Basecamp.

jbeda 5y ago

FWIW — we never viewed Kubernetes as a PaaS. We were informed by both Borg and GAE (and Heroku and PCF). The pattern that you see often with PaaS is that they work great until they don’t. When you want to do something that doesn’t fit the patterns that the PaaS was built for you are out of luck and pretty much have to drop down to VMs. We aimed to have k8s be something that was in the middle. Generic enough to work with a large number of workloads while providing significant advantages above raw VMs (and a level of consistency across infra providers). The tradeoff is that it is more complicated than the typical PaaS. That is the tradeoff. The goal then was to build kubernetes to be built upon. We never claimed to be solving the whole problem in one system. This is similar, in some ways, to the design of Mesos. But to do something new with Mesos requires an entirely different “framework” that exposes its own API. You see this with things like Marathon or Aurora or Chronos. While the underlying scheduler was shared across these there was no common API and so it was difficult for users to mix/match across these. By focusing on a consistent IaaS-ish API for k8s (and eventually, with CRDs, building extension mechanisms) we aimed to create an ecosystem of things building on k8s. Whereas PaaS are often a framework where you put your code in and a lot of decisions were made for you, I always viewed k8s as a toolkit where you get a lot of powertools that you can use in various ways. It is a very different philosophy. 12 factor and Docker obviously play a big part of this. And those built on experience and systems that came before them. We are all standing on the shoulders of those that came before us. For me, this API design experience was informed by my time at Microsoft. Things like VB and IE/web were very much, at that time a framework (the web is turning into a toolkit over time now). I saw, multiple times, how those things were super useful but were limited. Things like the CLR and the C# ecosystem evolved the VB model to be much more of a toolkit. We see this also in the Java world. I’m not an expert there, but the move from app servers to things like Spring Boot also show the shift from framework to toolkit. AWS itself is a toolkit. And IMO, the difference between something like lambda/faas and a PaaS is that lambda/faas only works when it is in context of the larger toolkit that is IaaS cloud. (I’m one of the founders of k8s and ended up with quite a bit of screen time in the documentary. My only regret is that more people that were so important in the k8s community couldn’t be featured!)

tombh 5y ago
Thanks for responding to my soap boxy opinions! I actually wrote my own complete PaaS from scratch once[1], and contributed to a number of other PaaS projects. I totally agree that PaaS projects work great until they don't. The reality is that a PaaS has to also be a Iaas, and yes Kubernetes really hits that middle ground. Thank you so much for your part in that. 1. https://github.com/tombh/peas https://github.com/tombh/peas

bytelines 5y ago

> Google just threw big numbers at it to make sure they took the biggest piece of the pie. And, ya know, invented cgroups and everything.

tombh 5y ago
If they were so innovative then why didn't they take the next step and make something like Docker?
- bytelines 5y ago
  Because Docker is also innovative? What is your argument here? If Google doesn't innovate everything, it can't be innovative? This is nonsense.
  - tombh 5y ago
    I was put off by your sarcastic dismissive "Ya know". I may have a controversial opinion, but I don't think it warrants that kind of flippancy.
    - bytelines 5y ago
      I'm sorry - I'll try to be kinder. To explain myself, I too was put off by your dismissiveness of Googles own key contributions. But that doesn't mean I can't say that kindly. For whatever it's worth, you have a very cogent way of making your point.
      - tombh 5y ago
        Thanks. I must admit I've learnt a lot about Google's contributions from this thread, so it's been productive overall.