If you can run your app on a £10 VPS then you are not the target market for the big clouds. That's why it doesn't make sense for you. Larger users have very different priorities.
This really isn't true. People use them for everything. Tiny little enterprise apps with 10s of users. Startups with mere 1,000s of uniques per month. Side projects. Everything.
If you look at Microsoft's strategy with C#/Azure you'll see that every single tutorial uses deploying on Azure. Their instructions for how to deploy to a real server in their tutorial is pretty much "we're not telling you, figure it out yourself, sucker".
Their new business strategy is to get the entire of their userbase paying massively over the odds for hosting small apps.
And, in reality, almost every app by any startup you could go and look at on producthunt (and probably most of ycombinator startups) have such low volumes of usage they could run on a $5 VPS. But I bet all of them are on AWS (there's even a few comments on this thread that basically say "start on AWS, then move").
Everyone is using cloud now, go to any meetup and ask. Or simply look at the sales figures.
The thing is, maybe you're overpaying spending $100/month instead of $10/month, but those are both small numbers. Simply not having to standup a DB/server/getting certs/debug if something goes wrong somewhere/etc is worth more in my time than a few $100. If you're very small scale you can also use the "always free" tier of VMs.
I really like that for my side projects/solo hacks I don't have to think about anything other "here is my code that does the thing that I think is cool" and all the deployment/serving/data layer/ml model inference/etc just kind of happens.
For small/very early startups it's also similar. At least in the US, it's not the extra $5k/year you spend on cloud hosting vs doing it yourself that kills you; for many engineers that less than a week of comp.
At the same time, when you are large and spending $100s of k on your hosting then sure, look into alternatives and migrate if needed. This is where "start on AWS, then move" comes from.
I guess the point I was trying to make is that all that "extra" stuff isn't really much extra work at all and the same magic deploy tools could be just as easy on a VPS/bare-metal, but aren't because of $$profit$$ making it better that they don't make it super-easy to deploy on VPS/bare-metal.
I can make a script to do it all for me (and have in the past), but it's a bit of work.
That's really why the title of the article is apt being "the Amazon Premium", and not "the Amazon Rip-off".
Honestly if you are deploying an application to production, hopefully you have a level of knowledge beyond "click here, then click here'.
The other side of this is that documentation is hard, and Microsoft documentation is frequently lacking or out of date, especially for anything off the beaten path. I use IoT Hub for messaging, and it's documentation is scant, many limitations and failure modes are found by trial and error.
haha, sometimes it feels that way, for their less-popular commercial services documentation is lacking and you can't even read the source!
On reflection my comment about level of skill is unfair, what I should have said is: generally the information is there, but it's not always in the form of follow-able 'How-to' guides, often it's a dry detailed documentation. If you need something other than the standard setup, it is up to you to know what you are looking for and put 2 and 2 together. Of course it is by no means easy.
They do have reasonable guidance on how to deploy ASP.net core on Linux, but it can be lacking for lesser used stuff
Honestly, why chime in with that? Not only is it sort of sneering (if you're that small), it's wrong and counter to the most practical advice we give out here, use what you know. It's hard enough starting a business without learning a whole new tech stack.
Ironically, we were having the discussion here yesterday about a guy with a failed startup saying he'd wasted the opportunity because he used too much new stuff and spent all his time on that instead of iterating the actual product. Several comments focused on it'd just be better to start off with a Rails app, it's quick, it's easy and it's understood.
And really, is lambda appropriate for anything more than a very focused niche app? I mean, try writing all the usual things you need to slot into a SaaS on it, billing, user management, signup, admin reports, admin functionality, emails, multi-tenancy, custom domains, etc. etc. Even a 20 user, internal, enterprise app needs most of that functionality. Put on top of that, you're forced to use a particular, proprietary tech stack and lock yourself into something that might very well die in a couple of years.
It takes a lot to have any meaningful lambda bill. That in no way is meant to be an insult. If you’re spending even $100/month on lambda, you’re running a successful website.
It's hard enough starting a business without learning a whole new tech stack.
If you know how to write a program and create a function that takes two parameters - a payload and context argument - you know lambda. You can write it in the console if you’re using Python or Node and just run it from there.
Even if you don’t want to learn that, you can host your standard C#/WebAPI, Python/Django/Flask, Node/Express API on lambda just by adding code and changing your endpoint.
Several comments focused on it'd just be better to start off with a Rails app, it's quick, it's easy and it's understood.
There is also code to wrap a Rails app and run it on lambda....
And really, is lambda appropriate for anything more than a very focused niche app? I mean, try writing all the usual things you need to slot into a SaaS on it, billing, user management, signup, admin reports, admin functionality, emails, multi-tenancy, custom domains, etc. etc. Even a 20 user, internal, enterprise app needs most of that functionality
Yes. Especially in today’s world of client side frameworks and microservices, you host your static assets like Javascript, css, and HTML in S3 and call server side APIs hosted on lambda.
Put on top of that, you're forced to use a particular, proprietary tech stack and lock yourself into something that might very well die in a couple of years.
Well, two things. What’s more likely to die in two years / your startup or AWS?
Second, you can host your standard API just by adding four lines of code and you don’t have to make any changes to host it in Docker or on a VM.
There is a way to do this in every language that lambda natively supports. For instance for Node:
I have a Node/Express app that gets deployed to both lambda and Fargate (Serverless Docker) when I push it. The only difference is that lambda uses one entry point and Docker uses another.
Where it is deployed to both lambda and a Windows server running IIS.
I can be a lot more productive with all the resources that AWS has to offer when all I have to do is provision resources with a CloudFormation template and instead of doing the grunt work of infrastructure administration I can concentrate on writing software.
