4 ms·

Kubernetes is a great piece of software and it definitely has it's advantages and use-cases. That said, this post strikes me on several fronts. The writer star

Kubernetes is a great piece of software and it definitely has it's advantages and use-cases. That said, this post strikes me on several fronts. The writer starts by saying that servers were treated as pets, which inherently means difficulty (as the author clears out). I assume that, at some point, their services got reworked to a shape where they could be deployed in servers treated as cattle. This is a work the author had to pay no matter if the final goal was Kubernetes, Autoscale Groups or any other solution. Then the author explains how they got to the conclusion that they need to containerise their service(s) in order to be able to use K8s, which would then, in turn, allow them to scale properly (adding on top the Go rewrite that is mentioned at some point in the post). The author also explains that Autoscale Groups were discarded because of their complexity. It's not clear to me that K8s was the actual thing that helped them scale, but rather the work they put into reworking their services. In my experience, once your service(s) are ready to be deployed in servers that can be managed as cattle, the benefits show up independently of the deployment solution that is used to deploy the service(s) (K8s, Autoscale Groups, etc...). Just to add on my point, wouldn't the result (in terms of performance / resources usage) be the same if instead of "containers" the author had chosen "AMIs" and instead of "Kubernetes" the author had opted for "Autoscale Groups"? If that were the case (which I believe it might have), the other thing to consider would be the difficulty of managing a K8s cluster vs the difficulty of managing an Autoscale Group. I've seen quite some horror stories about K8s[1] and I'd rather choose ASG over K8s. [1]: https://k8s.af https://k8s.af

vp8989 5y ago
If you are a Director of DevOps, what is easier to say to the CTO: "I need X million USD in engineering spend this year because we need to be on Kubernetes". "I need X million USD in engineering spend this year to fix half a decade of awful technical execution and decision making (that all happened under your watch, BTW)".
- edoceo 5y ago
  > awful technical execution Leave that out. Many right decisions look stupid later. It will happen to you to. Time makes fools of us all.
  - deleted 5y ago
    [deleted]
  - milesvp 5y ago
    This. It’s always important to assume the decisions made before you were correct, or at least a good approximation to correct given the conditions or knowledge at the time. It’s sort of a generalization of chesterson’s fence. If you don’t know why a decision might have been smart at the time, you will likely make another mistake trying to correct it. It may not always be true but thinking this way can at least keep you honest.
  - leucineleprec0n 5y ago
    The question was one in rhetorical jest, no? Clearly the former statement is "correct"
- yawaramin 5y ago
  Neither: "I need X million USD in engineering spend this year because we need to practice DevOps and SRE."
  - qw 5y ago
    "I need X million USD in engineering spend this year because it would improve my CV"
    - rualca 5y ago
      The author of this blog post states quite clearly that his company already used EKS elsewhere. If all he wanted to do was add a fancy line to his CV, why would he bother with something he already had? Also, it's silly to just assume that continuing to treat pampered EC2 instances that had to be manually deployed ande cared for is something that benefits a projectsl, specially if the company already shed those bad practices elsewhere.
  - belatw 5y ago
    This reads to me as: ‘I need X million in USD in engineering spend this year so I can add “I managed a large SRE/DevOps team” on my resume.’
- ransom1538 5y ago
  "Hey! I have the code wrapped in k8s! it is now serving an endpoint - let's start giving it a small amount of traffic!"
- rualca 5y ago
  > "I need X million USD in engineering spend this year to fix half a decade of awful technical execution and decision making (that all happened under your watch, BTW)". I don't know what is there in the IT/dev industry that compels some characters to quickly whip out blanket accusations of gross incompetence to anyone who isn't them. This mindset is particularly egregious given that the whole industry has enthusiastically adopted as a best practice just agilying big balls of mud through sequences of quickly delivered stopgap solutions while refactoring and paying off technical debt is seen as wasted effort. The author of this blog post clearly described refactoring a legacy system that worked reliably in hopes to improve their operations. Yet, here you are accusing someone investing their time and effort to improve their stuff as something that could only be explained as incompetence?
  - vp8989 5y ago
    For the purpose of my joke, it doesn't really matter if it's incompetence or intentional under-engineering. It was a satirical observation (based on my experience) that "the business" tends to scoff at unsexy foundational rework of existing tech. The trendiness of Kubernetes is used effectively to "trojan horse" that kind of work in. I am jokingly suggesting that at this stage maybe that's the real value of Kubernetes.
edoceo 5y ago
Yea. I'm a VM type of admin. One time I got a whole lecture from a Docker Zealot about how I need to not treat my servers as pets. As if docker was the only path to that end. Never even bothered to talk about the existing infra that was managed like cattle - and that it was more a function of App-Architecture than Docker vs X. Its nice to love your tools. Don't start thinking they are the one true path.
- tisFine 5y ago
  Agreed. Software is not hardware. Behavioral patterns for a user are not tethered to one ephemeral implementation. I ran a huge VMWare cluster in 3 data centers across the globe, not so different from an AWS/EKS pipeline. Yes, I had to treat the hardware like pets to an extent. But the developers had no problem pivoting between VMWare and what we ran in AWS because the software tooling we provided looked the same. Some folks believe memorizing YouTube videos = expertise.
- ransom1538 5y ago
  "One time I got a whole lecture from a Docker Zealot about how I need to not treat my servers as pets." You can always point out that pods are ran on nodes. Nodes use the standard built in GCP Auto-scaler (instance groups + load balancer). So its a great wrapper! But, it's a wrapper. GCP also! has a way to use a docker image as your VM.
  - edoceo 5y ago
    Agree and understood. You sound reasonable. IME zealots trade reason for enthusiasm and they focus too much on the method, not the concept. This individual was shocked to learn I thought you could treat the iron-born servers as cattle too. (But, my first clusters were in the late 90s, so got to the cattle concept quite some time ago)
- rualca 5y ago
  > Never even bothered to talk about the existing infra that was managed like cattle I don't see the point of your counterargument. For starters, there are plenty of managed containerized solutions that just run your containers without you ever having to bother with them. Secondly, it seems you got it entirely wrong: the point of pets vs cattle are the services, not the servers. You want to take your services down and put them up without surprises. Unless you're planning on rebooting your infrastructure just for shits and giggles, it makes no sense to talk about treating "servers" as pets, specially as you already get those as managed services just like you get VMs.
rualca 5y ago
> It's not clear to me that K8s was the actual thing that helped them scale, but rather the work they put into reworking their services. It seems you're missing the forest for the trees. They put in the work to refactorize their services so that they could be treated as cattle and also autoscale, and the author stated that after doing his homework he determined that for his company Kubernetes offered the most benefits. There isn't much to read from this. > Just to add on my point, wouldn't the result (in terms of performance / resources usage) be the same if instead of "containers" the author had chosen "AMIs" and instead of "Kubernetes" the author had opted for "Autoscale Groups"? The author explains that he considered using EC2 instances but after analising the tradeoffs the company decided to just jump to EKS. If you'd like to debate containers vs VMs then it's perfectly fine, but the author of this blog post just documented his learning path and pointed out what worked for him. Sometimes you need to call a shot, and the tradeoffs you need to consider are so minor and irrelevant that a coin flip will do.

vp8989 5y ago

If you are a Director of DevOps, what is easier to say to the CTO: "I need X million USD in engineering spend this year because we need to be on Kubernetes". "I need X million USD in engineering spend this year to fix half a decade of awful technical execution and decision making (that all happened under your watch, BTW)".

edoceo 5y ago
> awful technical execution Leave that out. Many right decisions look stupid later. It will happen to you to. Time makes fools of us all.
- deleted 5y ago
  [deleted]
- milesvp 5y ago
  This. It’s always important to assume the decisions made before you were correct, or at least a good approximation to correct given the conditions or knowledge at the time. It’s sort of a generalization of chesterson’s fence. If you don’t know why a decision might have been smart at the time, you will likely make another mistake trying to correct it. It may not always be true but thinking this way can at least keep you honest.
- leucineleprec0n 5y ago
  The question was one in rhetorical jest, no? Clearly the former statement is "correct"
yawaramin 5y ago
Neither: "I need X million USD in engineering spend this year because we need to practice DevOps and SRE."
- qw 5y ago
  "I need X million USD in engineering spend this year because it would improve my CV"
  - rualca 5y ago
    The author of this blog post states quite clearly that his company already used EKS elsewhere. If all he wanted to do was add a fancy line to his CV, why would he bother with something he already had? Also, it's silly to just assume that continuing to treat pampered EC2 instances that had to be manually deployed ande cared for is something that benefits a projectsl, specially if the company already shed those bad practices elsewhere.
- belatw 5y ago
  This reads to me as: ‘I need X million in USD in engineering spend this year so I can add “I managed a large SRE/DevOps team” on my resume.’
ransom1538 5y ago
"Hey! I have the code wrapped in k8s! it is now serving an endpoint - let's start giving it a small amount of traffic!"
rualca 5y ago
> "I need X million USD in engineering spend this year to fix half a decade of awful technical execution and decision making (that all happened under your watch, BTW)". I don't know what is there in the IT/dev industry that compels some characters to quickly whip out blanket accusations of gross incompetence to anyone who isn't them. This mindset is particularly egregious given that the whole industry has enthusiastically adopted as a best practice just agilying big balls of mud through sequences of quickly delivered stopgap solutions while refactoring and paying off technical debt is seen as wasted effort. The author of this blog post clearly described refactoring a legacy system that worked reliably in hopes to improve their operations. Yet, here you are accusing someone investing their time and effort to improve their stuff as something that could only be explained as incompetence?
- vp8989 5y ago
  For the purpose of my joke, it doesn't really matter if it's incompetence or intentional under-engineering. It was a satirical observation (based on my experience) that "the business" tends to scoff at unsexy foundational rework of existing tech. The trendiness of Kubernetes is used effectively to "trojan horse" that kind of work in. I am jokingly suggesting that at this stage maybe that's the real value of Kubernetes.

edoceo 5y ago

Yea. I'm a VM type of admin. One time I got a whole lecture from a Docker Zealot about how I need to not treat my servers as pets. As if docker was the only path to that end. Never even bothered to talk about the existing infra that was managed like cattle - and that it was more a function of App-Architecture than Docker vs X. Its nice to love your tools. Don't start thinking they are the one true path.

tisFine 5y ago
Agreed. Software is not hardware. Behavioral patterns for a user are not tethered to one ephemeral implementation. I ran a huge VMWare cluster in 3 data centers across the globe, not so different from an AWS/EKS pipeline. Yes, I had to treat the hardware like pets to an extent. But the developers had no problem pivoting between VMWare and what we ran in AWS because the software tooling we provided looked the same. Some folks believe memorizing YouTube videos = expertise.
ransom1538 5y ago
"One time I got a whole lecture from a Docker Zealot about how I need to not treat my servers as pets." You can always point out that pods are ran on nodes. Nodes use the standard built in GCP Auto-scaler (instance groups + load balancer). So its a great wrapper! But, it's a wrapper. GCP also! has a way to use a docker image as your VM.
- edoceo 5y ago
  Agree and understood. You sound reasonable. IME zealots trade reason for enthusiasm and they focus too much on the method, not the concept. This individual was shocked to learn I thought you could treat the iron-born servers as cattle too. (But, my first clusters were in the late 90s, so got to the cattle concept quite some time ago)
rualca 5y ago
> Never even bothered to talk about the existing infra that was managed like cattle I don't see the point of your counterargument. For starters, there are plenty of managed containerized solutions that just run your containers without you ever having to bother with them. Secondly, it seems you got it entirely wrong: the point of pets vs cattle are the services, not the servers. You want to take your services down and put them up without surprises. Unless you're planning on rebooting your infrastructure just for shits and giggles, it makes no sense to talk about treating "servers" as pets, specially as you already get those as managed services just like you get VMs.

rualca 5y ago

> It's not clear to me that K8s was the actual thing that helped them scale, but rather the work they put into reworking their services. It seems you're missing the forest for the trees. They put in the work to refactorize their services so that they could be treated as cattle and also autoscale, and the author stated that after doing his homework he determined that for his company Kubernetes offered the most benefits. There isn't much to read from this. > Just to add on my point, wouldn't the result (in terms of performance / resources usage) be the same if instead of "containers" the author had chosen "AMIs" and instead of "Kubernetes" the author had opted for "Autoscale Groups"? The author explains that he considered using EC2 instances but after analising the tradeoffs the company decided to just jump to EKS. If you'd like to debate containers vs VMs then it's perfectly fine, but the author of this blog post just documented his learning path and pointed out what worked for him. Sometimes you need to call a shot, and the tradeoffs you need to consider are so minor and irrelevant that a coin flip will do.