4 ms·

They have top notch tech, yes, but it’s massively overkill for literally every company that’s not at google’s scale. If you’re not careful you may hire someone

They have top notch tech, yes, but it’s massively overkill for literally every company that’s not at google’s scale. If you’re not careful you may hire someone who will try to replicate everything google does, when you may need only 1% of the complexity. This is the experience I’ve generally had with xooglers… they lament that they don’t have the same tools/tech stack they had at google, and so their first act is to try to move everything to the closest open source equivalents, even if they’re not a good fit. There’s good things and bad things to take away from experience at google… you have to be careful to ignore things that won’t actually help you.

scarface_74 2y ago
I agree. I haven’t run into a “hard problem” in my career By hard problem I mean technically at the top 5% of a problems in the industry that can’t be solved by throwing money at a SaaS or using a cloud provider.
- everfrustrated 2y ago
  Most companies are really just crud apps. Very few are doing anything technically innovative. And that's just fine. I wonder how much of the early Google technical innovation was more a product of open source tech/distributed systems being a lot more immature (I'm particularly thinking databases) 25 years ago. Ultimately all companies get bloated and loose their way. It shouldn't be a suprise this has happened to Google - 25 years on they are mega corp and idling. Probably for the best as it allows innovators a chance to compete.
deepsun 2y ago
I've been the "you're not google" person for several years, but now softened my position. The thing is -- it depends. Sometimes when everyone knows some complex system well -- it becomes easy. One example comes to mind -- Kubernetes. 90% of teams don't need all its complexity. And I've been "you don't need it" person for some time. But now I see that when everyone knows it -- it's actually much easier to deploy even simple websites on it, because it's a common lingo and you don't spend time explaining how it's deployed. It's not like civic engineers, when an over-engineered bridge would cost a lot more in materials.
- scarface_74 2y ago
  If you have a simple website , you can containerize your backend and use much simpler services from AWS and serve your static assets on S3. Kubernetes is rarely the right answer for simple things even if Docker is.
  - mschuster91 2y ago
    > much simpler services from AWS Like what, Lambda? I've seen so much horrible hacks and shit done with it (and other AWS services cough API gateway cough), these days I rather prefer a set of Kubernetes descriptors and Dockerfiles. At least that combination all but enforces people doing Infrastructure-as-a-code and there's (almost) no possibility at all for "had to do live hack XYZ in the console and forgot to document it or apply it back in Terraform" .
    - scarface_74 2y ago
      AWS App Runner https://aws.amazon.com/blogs/containers/introducing-aws-app-runner/ https://aws.amazon.com/blogs/containers/introducing-aws-app-... Google has something similar.
      - icedchai 2y ago
        GCP has Cloud Run, which looks similar. App Runner is basically a wrapper on top of Fargate, right?
        scarface_74 2y ago
        Yep. Every “serverless” compute service is just a wrapper on top of Firecracker including Lambda and Fargate.
    - icedchai 2y ago
      In my experience, you are better off with ECS/Fargate than Lambda for serving an API. You get much more flexibility. Also, I've witnessed people editing Lambda code through the console instead of doing a real deploy. what a mess...
VirusNewbie 2y ago
> but it’s massively overkill for literally every company that’s not at google’s scale. Before I worked at Google I was at a small telecom company that was running into limits of what some of the Dataflow/Apache Beam product could do, so we had to rewrite it (and commit it back to Beam). There are companies that have massive scaling issues even if they're not planet scale cloud providers or something. You can replicate a lot of Google tech now by....just using the OSS they release and/or jumping on a modern cloud provider (GCP or AWS). It's not 2012. You can use a good database and not have to reinvent it.

scarface_74 2y ago

I agree. I haven’t run into a “hard problem” in my career By hard problem I mean technically at the top 5% of a problems in the industry that can’t be solved by throwing money at a SaaS or using a cloud provider.

everfrustrated 2y ago
Most companies are really just crud apps. Very few are doing anything technically innovative. And that's just fine. I wonder how much of the early Google technical innovation was more a product of open source tech/distributed systems being a lot more immature (I'm particularly thinking databases) 25 years ago. Ultimately all companies get bloated and loose their way. It shouldn't be a suprise this has happened to Google - 25 years on they are mega corp and idling. Probably for the best as it allows innovators a chance to compete.

deepsun 2y ago

I've been the "you're not google" person for several years, but now softened my position. The thing is -- it depends. Sometimes when everyone knows some complex system well -- it becomes easy. One example comes to mind -- Kubernetes. 90% of teams don't need all its complexity. And I've been "you don't need it" person for some time. But now I see that when everyone knows it -- it's actually much easier to deploy even simple websites on it, because it's a common lingo and you don't spend time explaining how it's deployed. It's not like civic engineers, when an over-engineered bridge would cost a lot more in materials.

scarface_74 2y ago
If you have a simple website , you can containerize your backend and use much simpler services from AWS and serve your static assets on S3. Kubernetes is rarely the right answer for simple things even if Docker is.
- mschuster91 2y ago
  > much simpler services from AWS Like what, Lambda? I've seen so much horrible hacks and shit done with it (and other AWS services cough API gateway cough), these days I rather prefer a set of Kubernetes descriptors and Dockerfiles. At least that combination all but enforces people doing Infrastructure-as-a-code and there's (almost) no possibility at all for "had to do live hack XYZ in the console and forgot to document it or apply it back in Terraform" .
  - scarface_74 2y ago
    AWS App Runner https://aws.amazon.com/blogs/containers/introducing-aws-app-runner/ https://aws.amazon.com/blogs/containers/introducing-aws-app-... Google has something similar.
    - icedchai 2y ago
      GCP has Cloud Run, which looks similar. App Runner is basically a wrapper on top of Fargate, right?
      - scarface_74 2y ago
        Yep. Every “serverless” compute service is just a wrapper on top of Firecracker including Lambda and Fargate.
  - icedchai 2y ago
    In my experience, you are better off with ECS/Fargate than Lambda for serving an API. You get much more flexibility. Also, I've witnessed people editing Lambda code through the console instead of doing a real deploy. what a mess...

VirusNewbie 2y ago

> but it’s massively overkill for literally every company that’s not at google’s scale. Before I worked at Google I was at a small telecom company that was running into limits of what some of the Dataflow/Apache Beam product could do, so we had to rewrite it (and commit it back to Beam). There are companies that have massive scaling issues even if they're not planet scale cloud providers or something. You can replicate a lot of Google tech now by....just using the OSS they release and/or jumping on a modern cloud provider (GCP or AWS). It's not 2012. You can use a good database and not have to reinvent it.