But don't let it encourage you to think serverless has no value, or it can't be done portably or cheaply. It has its sweet spots just like everything else.
https://aws.amazon.com/solutions/implementations/aws-perspec...
https://news.ycombinator.com/item?id=24552779
(regarding costs, this setup ends up being +$500/month, again, to draw graphs of your architecture https://twitter.com/der_rehan/status/1308242717307174912)
This field used to be inspiring, but now I see the ideia of having a server being sold as the plague and lots of negativity towards people who are good at servers. They are not seen as another human being but the "other".
Also I can't understand why one would prefer to pay that much for such complexity.
It seems unsustainable for me, not to mention the new generation being spoon fed that that is way to go makes me concerned about the future of open computing.
If there is one thing that dealing with AWS reps has taught me, it's that this was 100% by customers. I swear to god, AWS doesn't do anything without customers asking for it.
If you are wondering why products are build in AWS, it's because people wanted to give them money for this. Say what you want, but this isn't something are pushing on us. This is something "we" push on them to provide.
To make an analogy, it's like hiring a carpenter based on the number of tools they have. NO. Show me your skill with a hammer and chisel, and I'll assume you can figure out the rest.
Just because it doesn't work for your situation doesn't mean it doesn't work at all.
It's a tool in your toolbox.
The new generation is always joining one cargo cult or another, that's why competent technical leadership is important. Remember when noSQL was the best thing since sliced bread?
Serverless can be a good option if you have large and unpredictable transient loads.
Like any architectural choice, you need to consider the tradeoffs and suitability for your use case. A TODO app probably doesn't need to be built with a serverless SOA.
I have not observed enough uses of serverless I can draw conclusions from, but if it's anywhere like hadoop style scaling, 95% of the users will pay 10x-100x on every metric without ever actually deriving any benefit compared to a non-distributed reasonably defined system, and 5% will actually benefit -- but everyone would want to put it on their resume and buzzword-bingo cards.
You might want to give a link next time to avoid ambiguity.
Each example that I've seen could have been replaced with a simple single process job. You should not need to go over the network because you need a process to run for more than 10 minutes. You should be able to check the status of resource creation via for loop.
An argument can be made for not needing a server, but I can easily fire off a container in fargate/gks/ecs and get similar benefit.
Futures are basically trivial to serialize, so the cost of involving a second node is as little as it could be; and node consolidation can be generalized because each node's dispatcher knows how many times it has accessed a remote process, which means that consensus on who should lead its log can be reached by simply sending it to the node that has the most use for it (with load balancing achieved by nodes simply not bidding for logs when their load factor or total service time is over some threshold, or say the 60th percentile of all the nodes, or whichever of those two is higher).
† In some cases it's faster to just catch up the log, rather than sending the aggregate.
We can't run it locally because the emulator won't run 7/10 of the code, there are memory limit errors that are totally opaque to us since we can't step through and watch it break. We are getting unexplained timing issues that were being worked on via logs in dev. The costs are insane.
If we want to say serverless is the future, the future isn't here yet. There are many tools that would need to be built to make serverless viable, and the tools that are built are immature and bad. Not to mention, you're tied to the companies support, so Google was outdated from the LTS for Node for a while. The reality is going serverless means you don't have control over what happens to your code.
In the end, you are just renting well maintained server farms (well, a specific percentage of operational time of some of the servers in them). There is absolutely no appeal for large technology-based companies do this once they can (the following is the lowest scale example) afford to maintain their own servers, while potentially renting a few offsite backups in other areas of the world (again, this is just the lowest-scale architecture starting at which Serverless is always the worse option).
Existing solutions are extremely over-engineered. It can be excused with "officially planning for the use-case where maximum scalability is required", but it's almost certainly a pretense to sell "certifications", aka "explaining our own convoluted badly documented mess". What this actually means is that many SWE's who are good enough to learn to use Serverless effectively, can learn any other framework that allows building distributed systems across server nodes with equal effort. Why would I base my whole business on your vendor locked, sub-optimized dumpster when I can do the same on an infinitely scalable VM networks, that can be ported to literally any vendor who supports $5/mo VMs (or, you know, self hosted if my company is large enough)?
Vendor lock-in is not a big consideration for us. I increasingly think about cloud vendors like Operating systems. I really dont care which Linux distro we are on. Pick a vendor and run 'natively' on it to go as fast as possible.
I'm happy paying AWS for maintaining the servers and getting out of that messy business. There are other concerns about serverless around observability and managability, but vendor lockin and cost is not part of my equation
But developing with "serverless" as base stack? Nope.
Still think it is mostly awesome and the services are solid. But such infrastructure comes with its own caveats.
EBS now bugs me about some 'HealthCheckAuthEnabled'. I don't know what it wants, just that I have limited time to react. Cannot understand the clearly auto-translated text. Still didn't get what it wants from me when I read it in English. I banned the health check from my logs and said where it can get a response from the service I run. I hoped our friendship ended there. Maybe it did and this is some form of retaliation.
The load balancer AWS set up for me now suddenly costs money. And I thought I could just use it to grab the free TLS cert that comes with it... well, the clients pay for the additional costs anyway and I would be surprised if anyone even noticed the price spike. The traffic is minimal but I am surprised it is actually that expensive. I could probably cut the costs in half if I actually had motivation to look through all the settings...
Microsoft just cancelled some features of some online service my colleague works with because they want to market an alternative for their BI solution. Did cost him 3 weeks of work at the minimum. The stuff cannot be ported to an on-premise version.
Hosting your own server is a lot of work and isn't fun. There is still a lot of work to do if you host on something on such an infrastructure.
Somehow the amount of work you have to put into software hasn't decreased. Honestly the main argument for it is that you can give away responsibilities.
edit: Just noticed that EBS probably counts as PaaS instead of serverless. I run "stuff" (very simple functions) on Lambda too, but to think it would replace apps like the article suggested seems a bit much. It has its purpose, but nearly everything I have on Lambda is AWS cloud specific. It comes in handy for Alexa integrations for example. I think the container won this fight to be honest.
For me it's easy because i just maintain my ansible roles.
It's fun because I get to keep up with OSS and be part of an amazing community.
And I get much better hardware for the price.
The tool doesn't matter, it's the practice that matters ;)
So true.
I really want to know how many of these "I host my own stuff"-people keep all there systems up to date. Updates, security patches etc.
Running a server has been a non-issue for years for me.
Sometimes I think it is a great trick some big players are pulling off, in convincing the world to subsidize their infrastructure costs (and more than that) by using their resources because it is "simpler" or more effective or alternatives are hard, etc ...
... to where the ability to competently setup and maintain those services will vanish, in due time. (Which, of course would only help to consolidate those -already- running such systems ...)
Serverless (specifically AWS Lambda) plays a part in the cloud, but most of your objections are true of the cloud and/or AWS more broadly, and have little to do with, specifically, serverless. (Despite whatever the webdev convention was trying to sell you.) There's a whole world of EC2 instances which are mostly VPSes, to know about that definitively aren't serverless (though there are some really neat cattle-level features that serverless learns from)
If the computer is a bicycle for the mind, then the cloud is a car for the programmer's mind. You can definitely build your own stack with your own team that manages to avoids the cloud, but at some point it becomes more than one person can handle. As you scale, there's a points where the cloud does, and does not make sense, but the cloud gets you access to far more resources as a tiny team than would otherwise be available to you.
If you are interested in these kind of stuff, maybe take a look at Wardley Maps: https://medium.com/wardleymaps
People who don't put time into learning development should not do it.
However, it seems detached from your first point.
If one's role is a front-end developer, is it necessary that they know about back-end development? If it is outside their intended job function, why would they need to know about it, if it doesn't get in the way of performing their job? If you are a backend developer, do you need to know about how to host your own infrastructure? Handle your own networking? Chip design? Your logic could be applied to any job function. Each level of the stack benefits from the levels below it being abstracted. We all stand on the shoulders of giants, and we're all much better for it.
Overall, I do think it's better that one has a good understanding about the various components one interacts with. Having a grasp of the overall system will come in handy. A curiosity into other parts of the system is beneficial, and likely is one of many indicators of success. However, if job functions can be simplified and superfluous context removed, why should we fault those for taking advantage of that?
This issue with "lowering the bar" and being glad that a simplification has "failed" (which, is yet to be determined), reeks to me like gatekeeping. The same logic could be applied to any job role which benefits from simplification. In an extreme example, this logic could be extrapolated to support the notion that anyone who cannot build their own machine from the ground up should never work in a programming position. What height is appropriate for the "bar"?
I went to a webdev convention, and it ended up being a serverless hype train. Industry experts with a financial incentive to promote serverless went on stage and told me they can't debug their code, or run it on their machine. They showed me comically large system diagrams for very simple use cases, then spent an hour explaining how to do not-quite-ACID transactions. Oh yeah and you can only use 3-5 languages, and each import statement has a dollar amount tied to it.
More importantly, all those skills you develop are tied to Amazon, or some other giant. All the code you write is at their mercy. Any problem you have depends on their support.
Am I supposed to bet hundreds or thousands of man hours on that?