No, it's way more than that. 10 years ago, I worked at a fairly well known tech company with 500+ employees.
1. We had an in house production engineering team, manage our own BGP and PoP points.
2. As we started to scale, we required active-active replication across multiple datacenters with high SLA requirements, which spawned a year-long project with multiple engineers to build in-house.
3. As the team grew, we required some sort of pub/sub system to enable cross-service communication — which spawned a year long project with a handful of engineers to build in-house.
4. We had to deploy our own load balancers in our datacenters and ensure that they scaled as we grew.
Today, my tiny little team has access to tooling that enables pretty much everything I described above for a low monthly price. Elastic load balancer gave us (4) right out of the box, RDS (or Dynamo) gave us (2) right out of the box, SQS + SNS gives us (3) right out of the box. Within the AWS VPC in us-east-1, we hardly ever think about (1). Today, we just had a need to do OCR (optical character recognition) of receipts because it was becoming untenable to have humans read every single on of them. Once upon a time, that would have been its own big engineering workstream. Instead, we had an intern integrate with AWS Textract (https://aws.amazon.com/textract/) and called it a day.
These anecdotes just scratch the surface; if you go on https://aws.amazon.com/, every single one of those products were once months-to-years-long multi-engineer projects that had to happen in-house at every tech company as recently as 2012. The sheer breadth of what AWS allows startups with limited resources to do just can't be understated, and as a startup employee myself, I appreciate that first-hand.
1. We had an in house production engineering team, manage our own BGP and PoP points.
2. As we started to scale, we required active-active replication across multiple datacenters with high SLA requirements, which spawned a year-long project with multiple engineers to build in-house.
3. As the team grew, we required some sort of pub/sub system to enable cross-service communication — which spawned a year long project with a handful of engineers to build in-house.
4. We had to deploy our own load balancers in our datacenters and ensure that they scaled as we grew.
Today, my tiny little team has access to tooling that enables pretty much everything I described above for a low monthly price. Elastic load balancer gave us (4) right out of the box, RDS (or Dynamo) gave us (2) right out of the box, SQS + SNS gives us (3) right out of the box. Within the AWS VPC in us-east-1, we hardly ever think about (1). Today, we just had a need to do OCR (optical character recognition) of receipts because it was becoming untenable to have humans read every single on of them. Once upon a time, that would have been its own big engineering workstream. Instead, we had an intern integrate with AWS Textract (https://aws.amazon.com/textract/) and called it a day.
These anecdotes just scratch the surface; if you go on https://aws.amazon.com/, every single one of those products were once months-to-years-long multi-engineer projects that had to happen in-house at every tech company as recently as 2012. The sheer breadth of what AWS allows startups with limited resources to do just can't be understated, and as a startup employee myself, I appreciate that first-hand.