4 ms·

I know it’s a joke but if you did a post-mortem the reason for failure would probably be: > Many at the company thought it's a good chance to upgrade software

I know it’s a joke but if you did a post-mortem the reason for failure would probably be: > Many at the company thought it's a good chance to upgrade software dependencies and libraries as well. A large part of a PostgreSQL database running on a single machine could as well be transformed into a distributed KV storage, leveraging the tremendous power of flexibility of AWS. Stick to the scope.

nailer 3y ago
Stick to the company’s scope too. If your business isn’t selling cloud infrastructure, use an off the shelf cloud provider. Especially don’t use k8s if you’re already paying for a cloud provider.
- weinzierl 3y ago
  This sounds so trivial and common sense but is more often violated than not.
- threeseed 3y ago
  This is bad advice. 1) Be clear about your requirements, understand your target platform and take the time to estimate costs. Blindly picking an off the shelf cloud provider can ruin you if you suddenly get hit with unexpected costs e.g. ingress/egress. 2) Kubernetes is often the sensible way to go so long as you're using a managed platform e.g EKS. As it allows you to build out your platform in a scalable, highly-available and geo-distributed way without needlessly tying yourself to any one cloud.
  - fragmede 3y ago
    > needlessly tying yourself to any one cloud. Because aaaany day now, AWS is going to turn around and jack up prices on EC2 instances because they can. Humans are terrible at risk analysis. There are good reasons to arbitrage between clouds, but business continuity isn't one of them.
    - threeseed 3y ago
      Only fools jump into using cloud providers without proper cost estimation. EC2 instance prices are nothing compared to the many hidden costs e.g. ingress, VPC, NAT.
      - gbear605 3y ago
        You say that, but I can look at actual costs spent by my company over the last two years and it’s mostly in ECS/EC2 and RDS.
      - jen20 3y ago
        I somewhat agree with you, but an important detail is wrong: ingress is almost always free, egress is where you get hit.
        jrs235 3y ago
        “You can check in, but you can't check out.” talking about the roach motel ROBERT ENGLUND - Freddy Krueger
        jen20 3y ago
        I guess “Hotel Ashburn” doesn’t have the same ring to it.
  - raverbashing 3y ago
    I think your number 2 is exactly what he means Don't use (self-managed) k8s when you can use the managed k8s provided by your cloud provider.
    - nailer 3y ago
      Yes, you read my post correctly - using an off the shelf cloud provider for their managed Kubernetes service counts as using an off the shelf cloud provider. But besides EKS, also consider ECS, EC2, etc. and whatever Microsoft has going.
  - nailer 3y ago
    > Kubernetes is often the sensible way to go Oh god the mid level infrastructure engineers are on HN now. No, running your own Kubernetes installation is absolutely not often the sensible way to go. Yes you should measure costs, well done, but be realistic and include at additional annual salaries for the people whose full time jobs are now managing Kubernetes and productivity loss due to failures of your unnecessary installation of massively complex software. If you haven’t noticed from posts like this, Kubernetes is an industry meme for wasted engineering effort and has a reputation of being something added to companies by young engineers practicing resume-driven development. Why not make your own monitors? Computer displays have enormous markups and monitor providers could increase prices at any moment. Finally: EKS also falls under the definition of using an off the shelf cloud provider as the other commenter has already pointed out.
phh 3y ago
Well, that's kinda the point of the point of the joke. There are many people out there more focused on the technology they are using rather than being focused the product they are making. Being focused on the product implies that yes you know your scope, and don't over-engineer it too soon. The joke concentrates on Kubernetes (if I wanted to be kind, it's probably because a joke is better with an actual examples, but I actually think it's because the author is in that engineering world, and doesn't know the other places where the same applies), but you could do the same with server-side rendering, with AI, with $modernFrontendLib, $modernLanguage

nailer 3y ago

Stick to the company’s scope too. If your business isn’t selling cloud infrastructure, use an off the shelf cloud provider. Especially don’t use k8s if you’re already paying for a cloud provider.

weinzierl 3y ago
This sounds so trivial and common sense but is more often violated than not.
threeseed 3y ago
This is bad advice. 1) Be clear about your requirements, understand your target platform and take the time to estimate costs. Blindly picking an off the shelf cloud provider can ruin you if you suddenly get hit with unexpected costs e.g. ingress/egress. 2) Kubernetes is often the sensible way to go so long as you're using a managed platform e.g EKS. As it allows you to build out your platform in a scalable, highly-available and geo-distributed way without needlessly tying yourself to any one cloud.
- fragmede 3y ago
  > needlessly tying yourself to any one cloud. Because aaaany day now, AWS is going to turn around and jack up prices on EC2 instances because they can. Humans are terrible at risk analysis. There are good reasons to arbitrage between clouds, but business continuity isn't one of them.
  - threeseed 3y ago
    Only fools jump into using cloud providers without proper cost estimation. EC2 instance prices are nothing compared to the many hidden costs e.g. ingress, VPC, NAT.
    - gbear605 3y ago
      You say that, but I can look at actual costs spent by my company over the last two years and it’s mostly in ECS/EC2 and RDS.
    - jen20 3y ago
      I somewhat agree with you, but an important detail is wrong: ingress is almost always free, egress is where you get hit.
      - jrs235 3y ago
        “You can check in, but you can't check out.” talking about the roach motel ROBERT ENGLUND - Freddy Krueger
        jen20 3y ago
        I guess “Hotel Ashburn” doesn’t have the same ring to it.
- raverbashing 3y ago
  I think your number 2 is exactly what he means Don't use (self-managed) k8s when you can use the managed k8s provided by your cloud provider.
  - nailer 3y ago
    Yes, you read my post correctly - using an off the shelf cloud provider for their managed Kubernetes service counts as using an off the shelf cloud provider. But besides EKS, also consider ECS, EC2, etc. and whatever Microsoft has going.
- nailer 3y ago
  > Kubernetes is often the sensible way to go Oh god the mid level infrastructure engineers are on HN now. No, running your own Kubernetes installation is absolutely not often the sensible way to go. Yes you should measure costs, well done, but be realistic and include at additional annual salaries for the people whose full time jobs are now managing Kubernetes and productivity loss due to failures of your unnecessary installation of massively complex software. If you haven’t noticed from posts like this, Kubernetes is an industry meme for wasted engineering effort and has a reputation of being something added to companies by young engineers practicing resume-driven development. Why not make your own monitors? Computer displays have enormous markups and monitor providers could increase prices at any moment. Finally: EKS also falls under the definition of using an off the shelf cloud provider as the other commenter has already pointed out.

phh 3y ago

Well, that's kinda the point of the point of the joke. There are many people out there more focused on the technology they are using rather than being focused the product they are making. Being focused on the product implies that yes you know your scope, and don't over-engineer it too soon. The joke concentrates on Kubernetes (if I wanted to be kind, it's probably because a joke is better with an actual examples, but I actually think it's because the author is in that engineering world, and doesn't know the other places where the same applies), but you could do the same with server-side rendering, with AI, with $modernFrontendLib, $modernLanguage