The whole notion of a "virtual server" is basically like saying, "radio with pictures" or "horseless carriage". It only makes sense in a specific historical context. We're still figuring out what comes next, but I think it's safe to say that 20 years from now the main building block will be something different than the simulation of a 1970s university department minicomputer that we're all using now.
So you either spend very little time on it and build servers adhoc ("snowflake" style - SSH in, install some stuff, etc), or you spend precious time doing "the right thing" - which right now is a huge universe of options (Chef/Puppet/Ansible, Docker/other containers/no containers, etc).
If you're part of a larger team, not having a properly structured infrastructure is a nightmare - specially when it comes to scaling or dealing with failures of all kinds.
TLDR; - yes, I'd say it's somewhat hard...
I don't think it's hard, it's just time consuming. And we all know that "time is money", specially for small teams or solo devs (as you pointed out).
During the years I've used ssh, puppet, fabric, ansible, capistrano, cloud formation, etc for managing servers and infrastructure. And I think that the main benefit of any PaaS, AWS Lambda or AWS API Gateway is (obviously) that they're time saving and abstract the internals. In fact I use them in several small projects.
With virtual machines, we started to share physical resources which were otherwise wasted in dormancy. But even virtual machines were a waste of resources, as you need someone to set them up, keep them online and working. What if you could share the money you spent with those people and their knowledge?
Amazon just did that to you.
All some people want is to run code somewhere on the internet.
Amazon gather them together to share a server and an admin team.
In my point of view, Amazon Lambda is a huge improvement in efficiency for people around the world, as I (or someone else) can pay for a very tiny part of the work of a very specialized sysadmin and focus on my code.
However when talking about microservices, any non-trivial app quickly gets extremely complicated to setup and actually more inefficient in the amount of time it takes to execute each request. And probably more expensive since there still have to be servers somewhere, always ready to run your app and with all the management and orchestration layer on top.
Also VM technology is sufficiently advanced that they can be multitenant on the same base hardware very efficiently and consume almost no resources while in a sleep state. With live-migration and auto-scaling advancements it's not a big deal.
If your scale is large, you have enough work to make full use of however many servers you rent.
Reducing infrastructure waste at small scale seems pointless to me. The actual cash money saving is just lost in the noise.
The only way i can see that i could be wrong is if there's a suppressed demand for huge numbers of tiny-scale services. Is there?
You could correctly argue that usage increases with scale.. so while you with 1 app can maybe only keep a server 20% busy, Amazon can afford to keep their servers 70% busy.. which is part of the story.
But the other part is you are paying for the convenience. You can get raw CPU way cheaper than what lambda gives it out at. Even if you only kept your CPU usage at 10-20% - for example Digital Ocean would still be cheaper than the Amazon Lambda app version. You are literally paying a surcharge to not have to set up your own servers, or deal with maintenance. I find it very unlikely you will save big money with lambda over your own servers.
Agreed. I think what it avoids though is setting up ansible + puppet + firewall + updates + monitoring + blah blah stuff you do to secure and dev-ops a prod app (for a baby app).
You can half-arse this stuff in a day for a new company. I assume the defaults of lambda will be a little more secure... but amazon security is pretty complicated to set up right, so not totally sure what the max win will be.
Investing in things like API Gateway and Lambda gives me the ability to keep my programming desires satisfied, while reducing the friction of tedious, time wasting operations, like automatically encoding a video of a class, extracting thumbnails, and setting permissions via API calls back to our home-brewed DAM system to make the video available for our students. Sure, I could do it myself each time. Six times per day of teaching. And turn down the process priority so it won't interfere with the rest of my job.
The costs of using AWS at that scale, while certainly nothing like the scale some of you are dealing with, are a considerable savings over the hourly rate I can charge for the time spent in my subject domain, and would have otherwise lost. We manage VMs for classes already, and most of that is now automated by our Hubot. In the coming weeks, the services/sites/apps we do have running will be migrated over to the docker-based infrastructure I'm building (in my copious free time, ha!), and the services therein will be interconnected with API Gateway and Lambda functions. It's a beautiful thing. I'm really quite pleased with it, and proud of what we've been able to do.
I'm know that I'm not alone, and maybe this post will encourage others in similar situations to share their experiences too. Maybe my peers don't frequent HN - that's an unknown to me, I guess. But there are far more entrepreneurs like me who enjoy the job we do, and will do everything we can to offload the time sucking administrivia to some other system, especially if we get to flex our programming muscles along the way.
If this was close to true, AWS would not have existed. The thing is, when you're big, you're planning for spikes, and you're paying for your maxima per month. (Spare capacity aside, as that has to be a percentage of your desired monthly capacity.)
And that without having to set up virtual servers on an IaaS like EC2 isn't new, lies of people, big and small, were doing PaaS offerings long before Lambda.