[chadash]

I don't know. Maybe I'm in a bubble, but it seems to me that knowing the basics of AWS (or some cloud provider) has become part of the standard developer's toolkit. With AWS specifically, there's so much documentation out there about getting started that I think you can have something up in a day or two on something like ECS or lambda (using something like the Serverless framework). And then when you need the more complex functionality, you are already in the AWS ecosystem.

If you are a startup trying to get a product to market, AWS is typically going to be a very small cost unless you are doing something very compute intensive (in which case something like Heroku, which the author recommends, certainly won't be cheaper anyway). The high bills only come later, if ever, after you've decided to create 20 databases and 50 apps for your 70 person startup.

[Aeolun]

The problem with even lambda or ECS though is that it’s all much more complex than a simple rsync to your desired server.

[sofixa]

With Fargate or Google Cloud Run, it really isn't. Assuming zero knowledge it's probably easier to learn how to build a docker container and call a binary to send it to the service than it is to setup ssh and rsync and a server to host your website.

[Aeolun]

I don’t think you can build a docker container without already understanding concepts that you need to run rsync. So it seems like an extra step?

[scarface74]

I went from not knowing Docker to having a production capable ECS/Fargate microservice spun up within less than a week.

I based it on this CFT

https://github.com/1Strategy/fargate-cloudformation-example/...

And this walk through for C#. I had a similar walkthrough for building a container for a Node service.

https://aws.amazon.com/blogs/compute/hosting-asp-net-core-ap...

[coredog64]

https://aws.github.io/copilot-cli/

That takes a Dockerfile, manages networking, secrets and CI/CD deployment. I have a few quibbles with what it does, but it generally works and is being maintained/updated.

[holografix]

App Runner is total crap compared to Cloud Run. Actually I don’t think the other 2 clouds have anything as nice and easy as Cloud Run

[tyingq]

Though there's lots of different ways to use AWS, so the experience your team brings may be a sort of complicated venn diagram. Even within a simple product, like deploying serverless, there's SAM vs serverless framework, vs scripted AWS cli. Using stacks or not. Using another layer on top or not like Terraform or CDK, and so on. Then the actual pattern of using it, Lambda layers, heavy or light patterns for securing things, using versions/aliases or not, and so on.

It wouldn't be unusual for a tech lead to pick some approach that ends up being new for the rest of the team. So some ecosystem with fewer choices would probably be faster.

[hotpotamus]

> but it seems to me that knowing the basics of AWS (or some cloud provider) has become part of the standard developer's toolkit.

This seems to be flirting with the idea that Amazon has become a required component of hosting an application on the internet.

[chadash]

Required? No, I'm not saying that. But yes, it's become the industry standard. If you don't know some AWS basics and you are a generalist web developer, you'd probably do well to learn them in order to make yourself a more marketable engineer.

There are plenty of good alternatives, but AWS is the 800-pound gorilla. You have to know at least a little bit about it in order to know why not to use it.

It's like saying you don't want to use React/Angular/Vue for your web app. There are good reasons not to, but at this point you should at least have some experience with web frameworks before making a technical decision not to use them. If your answer is "I don't know them and I don't want to learn them", that's fine for a personal project, but probably not a reason not to use them at your full-time startup. If your reason is "I know React, but for my specific use case, vanilla HTML/CSS/JS is better" then you are making a more informed decision.

[hotpotamus]

I suppose my problem is that the enormous complexity paired with the utility billing feels like I'm trying to drink from a pool of water surrounded by enormous lurking predators (the 800-pound gorilla analogy seems apt). I think everyone has at least a story of a forgotten instance that billed them a bit more, but with "infinitely scalable" compute come infinitely scalable bills. There are instances of developers creating infinite loops in cloud functions that result in 6 figure AWS bills. Of course then the advice is to plead your case and hope for a credit, but I wouldn't expect everlasting benevolence from Bezos's machine.

I have other issues and could probably expound on them at length, but work to do and all that. I don't disagree with you that it's an important tool for engineers today (I've certainly got an account or two), but that doesn't mean I have to like it.

[vsareto]

The basics give you enough to be dangerous, but cloud stuff has become complex enough to require dedicated people to do it well.

I'd prefer to hire someone dedicated to that and just let them work part time when the environment is simple over a developer with just the basics who's going to try to architect and run everything.

[sebazzz]

> I'd prefer to hire someone dedicated to that and just let them work part time when the environment is simple over a developer with just the basics who's going to try to architect and run everything.

And me thinking we got to the cloud to get rid of the BOFH.