> You'll pay more than the price difference for someone to implement all of that from scratch.
This is a common trap for startups. AWS has been around long enough that everyone has a 1st-hand or 2nd-hand horror story about someone with a $5000/month AWS bill for a basic website. This creates a false narrative that AWS is bad and or dangerously expensive. Or worse, that clever devops engineers can simply roll their own solutions with open source tools for half the cost.
The reality is that if a startup truly needs $5K/month of AWS services, they’re getting a bargain by buying it from Amazon instead of building it out themselves. $5K/month won’t even begin to buy you another qualified devops engineer to build and maintain custom infrastructure. The first rule of startup engineering is to use every tool available at your disposal to get to market as fast as possible. Cost reduction can come later, but you can never get back wasted time spent rolling your own solutions when an off the shelf vendor could have solved your problem in days rather than months.
However, the other trap is when inexperienced or overeager engineers see the long list of AWS product offerings and think the goal is to use as many of them as possible. There are some misaligned incentives for engineers who want to gain as much AWS experience as possible on their employer’s dime, regardless of whether or not it’s the right business decision. Worst case, mid-level engineers use as many AWS services as possible so they can pad their resumes, then use the experience to pivot into a higher paying job elsewhere and leave the startup with a mess of half-implemented, unnecessary AWS infrastructure and no one to maintain it. Unfortunately, it happens frequently in the startup world where companies are more likely to hire junior engineers who are eager to tinker with AWS and build their resumes.
The brute force way to avoid this problem is to simply constrain the engineering team to a less powerful platform like OVH or DO. If you don’t need any features of the bigger clouds, this works. However, as soon as you do need the big-cloud features you’re going to waste huge amounts of money building them out yourself. It won’t show up on the monthly provider bills, but rather be hidden in the much higher engineering costs and longer project timelines.
The real solution is to hire experienced engineering leadership who will keep complexity in check, then use AWS or other big cloud providers responsibly.
Can you share a story about how AWS helped to remove or redeuce spend on devops? In my experience with AWS you would get $5000/month for a basic website and also would be paying devops to manage AWS.
This is a common trap for startups. AWS has been around long enough that everyone has a 1st-hand or 2nd-hand horror story about someone with a $5000/month AWS bill for a basic website. This creates a false narrative that AWS is bad and or dangerously expensive. Or worse, that clever devops engineers can simply roll their own solutions with open source tools for half the cost.
The reality is that if a startup truly needs $5K/month of AWS services, they’re getting a bargain by buying it from Amazon instead of building it out themselves. $5K/month won’t even begin to buy you another qualified devops engineer to build and maintain custom infrastructure. The first rule of startup engineering is to use every tool available at your disposal to get to market as fast as possible. Cost reduction can come later, but you can never get back wasted time spent rolling your own solutions when an off the shelf vendor could have solved your problem in days rather than months.
However, the other trap is when inexperienced or overeager engineers see the long list of AWS product offerings and think the goal is to use as many of them as possible. There are some misaligned incentives for engineers who want to gain as much AWS experience as possible on their employer’s dime, regardless of whether or not it’s the right business decision. Worst case, mid-level engineers use as many AWS services as possible so they can pad their resumes, then use the experience to pivot into a higher paying job elsewhere and leave the startup with a mess of half-implemented, unnecessary AWS infrastructure and no one to maintain it. Unfortunately, it happens frequently in the startup world where companies are more likely to hire junior engineers who are eager to tinker with AWS and build their resumes.
The brute force way to avoid this problem is to simply constrain the engineering team to a less powerful platform like OVH or DO. If you don’t need any features of the bigger clouds, this works. However, as soon as you do need the big-cloud features you’re going to waste huge amounts of money building them out yourself. It won’t show up on the monthly provider bills, but rather be hidden in the much higher engineering costs and longer project timelines.
The real solution is to hire experienced engineering leadership who will keep complexity in check, then use AWS or other big cloud providers responsibly.