[blobbers]

This is because reliability, ease of setup, and support are actually just as important as what is being run.

If you're not using AWS you're not fully leveraging your software team, because that means you've got people spending time building and supporting these sorts of internal systems. That should only be done when you reach large scale, at which point people have leveraged other AWS synergies making it harder to exit the platform.

[bryanrasmussen]

>That should only be done when you reach large scale, at which point people have leveraged other AWS synergies making it harder to exit the platform.

And then you're bleeding money!

[pbz]

And drowning in a sea of complexity...

[barumi]

I really doubt you have any real world experience with AWS if you try to sell it as a less complex alternative to anything,really. AWS is perhaps the most complex and arcane service provider ever, and is progressively getting worse by the way the service keeps growing and changing.

And no, learning a specific AWS service is not a solid career investment. Tell that to anyone who tried to learn CloudFormation and then SAM and now forget everything because AWS pushes you to use CDK.

[pbz]

May wanna read that again...

[barumi]

> If you're not using AWS you're not fully leveraging your software team, because that means you've got people spending time building and supporting these sorts of internal systems.

This is simply not true at all, and flies in the face of real world usage.

The only concrete and objective selling point of AWS is it's global coverage of data centers, and the infrastructure they have in place aimed at delivering reliable global-scale web services.

The problem is that the companies who actually operate at such a scale and with such tight operational requirements can be counted with your fingers. That count then drops down to a fraction once you start to do a cost/benefit analysis.

The rest of the world is quite honestly engaged in cargo cult software development.

And no, doing AWS is not simpler nor more efficient. You might launch an EC2 instance with a couple of clicks, but to navigate a service designed with global scale and multiple levels of redundancy across the same service and with tight integration and dependency across half a dozen AWS offers which may or may not be redundant or competing... No, that is not simple or allows for any type of time efficiency.

Hell, with AWS you do not learn how to manage or operate Infrastructure. With AWS you learn the AWS dashboard,and learn pavlov reactions to which button you press if you hear an alarm. You never fully grasp the impact or the reaction of pressing a button, and you have absolutely no idea what impact that click will have on your monthly bill.

In contrast, if you need to run microservices chatting through a message broker then your system on OVH or Hetzner or any other barebones system will be comprised of a bunch of nodes where one of them runs RabbitMQ and everyone else points to the RabbitMQ node. You can get everything running from scratch on a cluster managed by Docker Swarm in about 15 to 20 minutes. In the end you have a far simpler service running for a fraction of the cost and ina far more manageable environment.

AWS is resume-driven development fueled by cargo cult development.

[dilyevsky]

For some stacks - sure. There’re good number where you’ll run into scalability/cost problem fairly quickly