Hacker News Reader

Comment by cryptica | Hacker News Reader

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion.

We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assessments.

Even if you make the wrong decision initially, at least it will be your own decision and you will learn from it. Moreover, when it's your own decision, you will learn from it sooner because you're not going to be getting undue reinforcement from peers.

If you over-idealize thought leaders, you will tend to stick to the popular doctrine instead of listening to your own reasoning.

View on HN

This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

I suspect if you were to put "your money where your mouth is" those 80% of yours would turn into 20 or less. ;)

Not a strawman, nope. Please put the React salesmen on this list of bogus hype as well. It’s all projection and propaganda—zero substance.

Here’s the proof of evil intent behind React, for example:

https://news.ycombinator.com/item?id=20711598

I suspect I am more wary of Facebook than most. However, unless there is something in that linked discussion that I'm just not seeing, I don't get it.

Or perhaps your idea of "proof" and mine are just vastly different.

proof = hint. /correction

i guess we’ll have to wait for the trail of destruction to appear as proof of everything else that has come from Facebook.

Um, I couldn't find any evil in that thread, sorry.

While in most cases I would agree, in this case I have to disagree. I think serverless has been a good idea implemented badly in every instance.

If (nearly) every implementation of a good idea turns out badly, is it still a good idea ? It smells like the No True Scotsman fallacy.

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.

Have been running our API on Gateway/Lambda for well over a year now, having migrated from EC2. We've spent almost no time "managing" API gateway, monitoring or logging since the initial setup and migration of our infrastructure.

If you are managing API gateway or your logging it's a failing on your initial setup and design, not on Serverless.

You should work in enterprises where you have to deal with stringent security requirements, emergency CVE mitigation across multiple regions, compliance requirements, etc., and you’ll quickly gain an appreciation for why enterprise folks don’t want to manage servers.

>> emergency CVE mitigation across multiple regions, compliance requirements

These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line.

Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy.

Enterprise folks don't want to manage servers for a whole host of reasons. But I would say the number #1 reasons is they don't understand the cost, and the #2 is the management team has no clue what they are doing -- and probably running a play book somebody else wrote one time long ago that happened to work exactly once.

> Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy.

It shifts blame, especially if it's in the contract with the provider.

Shifting blame doesn’t help much when you lose customers (or pay financial penalties) due to non—compliance.

You learn quickly that while AWS is “compliant”, they have enough legal sway to never be on the hook if they aren’t actually compliant.

Yup! If something goes wrong with compliance, who is going to win the finger pointing game? A smaller company that needs to outsource their compute, or Amazon?

If it was really Amazon's service that was at fault, then what are the chances that only one client is affected?

It’s rare for things to go so disastrously wrong that legal sway is relevant. What’s much more common is an angry CTO looking for someone to be mad at, and Amazon doesn’t have any particular ability to deflect that.

If you're dealing with businesses where compliance is required, such as PCI, HIPPA, or FedRamp, legal sway is absolutely relevant. If you should have a breach and an associated fine, Amazon can easily push the blame (and the likely-company-breaking fines) back on you.

AWS' compliance model isn't a magic wand that makes your crappy app's XSS vulnerabilities go away. The real question: do you think AWS will try to push responsibility for a breach to their customers unjustly?

If you don't adhere to the shared responsibility model and a contractor checks long lived IAM credentials into Github, that breach is definitely attributable to you and you deserve all the "blame" you get.

But if someone figures out how to trick AWS' IAM into issuing credentials that allow PHI to be pulled out of S3, do you think that gets passed along to a customer?

But they do go away. They go straight away to a vendor which is very likely to address them faster, and with more competent resources, than you and your team (or, if that sound insulting - me and my team). They become covered with that famous someone else's problem field

> They go straight away to a vendor

This argument only works until you reach a certain size or security requirements.

At the end of the day, if it's critical to the business it doesn't matter what the paper says, you're still responsible for any damage to the business from a bad vendor.

----

It's just like car manufacturers, nobody cares that Takata was actually responsible for faulty airbags. They simply know their GM vehicle has a dangerous recall.

But, at that same “certain size”, shareholder value for your company becomes something influenced mostly by making your value-chain upstream/downstream partners happy, not by making the eventual customers of your product/service happy.

Rather than thinking about GM’s perspective, think about Takata’s perspective: they screwed up making an airbag, but everything was fine because they outsourced their audit to GM, so indeed it was “GM’s responsibility.” On top of that, GM is still happy to treat them as a partner.

Now imagine that instead of some random third-party supplier, Takata was a division of GM, selling to a different division of GM. The same considerations still apply from the Takata-as-division’s perspective, even though nominally they’re part of a company of that “certain scale.”

> Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy.

Are you joking? Outsourcing compliance critical parts of your environment is the raison d'être of huge swaths of the enterprise IT landscape.

https://aws.amazon.com/compliance/services-in-scope/

Can you imagine how much that page costs in terms of getting the audits, developing the processes & procedures internally to execute on the requirements, etc?

That's not hand-waving away concerns: it's paying a premium to know your infrastructure was managed in scope of whichever compliance regime your business falls under, and to get attestations that prove to your auditors that things are indeed being done properly.

Most Enterprise are still married to java, they still write off node as "not a real language" most likely node is your best bet for the most efficient lambdas Java is a poor for for that.

Whenever I've spoken with engineers from AWS and Google Cloud they saw serverless as a platform for glue code, webhooks, cronjobs and the like. In that role it works great: you don't care if it takes 300ms to start and it's genuinely easier and cheaper than running that code on a server.

But somehow in marketing materials and blog posts it's instead discussed as if it was a good idea to run everything serverless. Maybe that works great for some edge cases (e.g. reaching PCI compliance), but in general that's not what it's for.

Wasn't it originally called Function as a Service? That seems to be a better name for its intended use-case than serverless.

FaaS is one example of a serverless service. Workflow or object storage services are others. It was the arrival of FaaS that stimulated the term.

Marketing latches onto that because 1) executives understand front-end use cases better than glue cases; and 2) it's way more profitable.

I'm not sure about your quantification of the overhead, I think you can have wins with severless there, but the other side of it is that you can make your server management a source of strength.

This is becoming unfashionable because it is arcane, but *nix (and Windows I'm sure) really provide some rich functionality and tunability that can let you move fast or reach performance/scale challenges that are very expensive or perhaps out of reach otherwise.

Of course, at one point I was told the same thing about managing your own hardware, and the thought of dealing with the jumpers on the back of the harddrive fills me with the same sense of frustration I'm sure a newer developer would feel when learning their disk is out of inodes for the first time.

Wow everyone all excited about hosted FreeBSD jails

Some of us had deploy pipelines into “containers” working like a Lambda in 2003.

Nothing in software is all that novel these days, IMO.

All these features that have been there for a decade plus are just wrapped in a corporate brand now.

Progress.

> Nothing in software is all that novel these days, IMO.

There is surely truth in this. But also, almost nothing is novel if you watch at the new stuff with the same mindset of the past.

It is wise to realize that most new stuff was already invented, but it is also wise to understand that the surrounding might have changed more than you realize.

(Talking out of my own ass here, just in philosophical terms)

The “feature” behind Lambdas aren’t the way they work; it’s the way they force you to work, exposing an ABI that forces “Lambda-compatible code” into a shape where it isn’t attempting to call into OS features of the local machine for things like state storage or IPC, but rather making calls to network-visible service endpoints to accomplish those tasks.

In other words, the Lambda environment, as a development target, is the exact opposite point on the spectrum from an OS like Mosix: rather than trying to make a big cluster of specialized compute resources appear as a standardized local POSIX environment, Lambda instead does away with the POSIX environment entirely and forces your code to interface with the big cluster of specialized compute resource “where it lives.” You can’t just write to disk, because there is no disk. You can’t just talk to other processes on the same machine, because there is no (multiprocessing) machine. In fact, you can’t even cache state in process memory indefinitely, because your process isn’t indefinite like it is in POSIX. Etc.

This is a big benefit for ops folks, insofar as code that’s written as “Lambda code” (but generically, using libraries like Fog) can be easily run in many more modern infrastructure environments (including on-prem ones!) than regular code can, “at scale”, without modification to the code itself. As well, these restrictions (like the one on not caching state in memory) force devs to confront what turn out to be the realities of fault-tolerance, which means far less of an ops headache later on, trying to baby along workloads that rely on never dying.

I would describe Lambda as doing a very similar thing for the server, as what Google’s Native Client (PPAPI) attempted to do for the browser: to create a new, strict ABI for developers to target, that forces code written against that ABI to build its features differently (i.e. more portably, more securely, etc.)

Or, philosophically, “serverless” is just a further extension of Heroku’s “twelve-factor”: it’s an approach that hobbles developers’ available toolkit, for the sake of making the workloads they produce better-behaved and more predictable at runtime.

Like I said I was providing largely that pattern years ago to devs.

Not very net new for me, except I’m tethered to AWS.

As usual: ymmv

Right, but, the "feature" of a popular standard isn't that it's a standard, but that it's popular.

The thing that was new about Facebook wasn't that it was different than MySpace, but that it was the first social network that managed to scale such that all your friends and relatives ended up using it without your pushing them to do so.

The differentiator of the serverless model is that it's a Schelling-fence development practice, such that you can find real infrastructure components in the wild that are targeted at "serverless deployment" and use them.

Or: there was likely no version of Wordpress developed specifically for your stack; but there is likely some version of Wordpress developed to be deployed on a FaaS cluster. That's what makes "serverless" worth paying attention to. Like Kubernetes, or even Linux: they're the first ubiquitous examples of their archetypes.

> Wow everyone all excited about hosted FreeBSD jails

Wow, FreeBSD weenies are excited about re-discovering CICS.

See how annoying and wrong you sound?

> For the 80% or more, serverless works just fine.

Citation?

> For the 80% or more, serverless works just fine.

Cite this. I don't believe you. I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues, but the majority of people with actual hands-on experience are disillusioned and say that the biggest (only?) drive for serverless at this point is top-down organisational pressure created by technically incompetent strategic management that looks to 'thought leaders' and Gartner to tell them what technologies to use.

if serverless works for 80%, then why is that 80% not even remotely reflected in the sentiment here? HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

Because comment sections are not good measures of opinion - they are places for discussion.

People make more effort to engage if they have strong positive opinions and minor negative opinions. Minor positive opinions, which (you hope) are the average in an audience, get unrepresented if the effort required to give feedback is great. That's why metrics measuring average opinion - like NPS - aim to require as little effort as possible.

> HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

Source?

Odd that you demand a citation and then counter with 3rd party anecdotes.

Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless (https://twitter.com/chrismunns).

I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing.

If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sharepoint, SAP, or similar) and then look at how many business applications take on a trivial amount of load over time, then the author's post becomes more of an outlier. Few folks have apps that do 100rps realistically. And so for data processing/streaming/batch or web/api workloads serverless actually does work out pretty well. Is this 80%, I am not sure.

There is 100% an inflection point where if your operator cost is low enough(human work+3p tools+process+care and feeding) then the "metal to metal" costs can be comparable. Even the author admits that's leaving something on the floor and so it really comes down to what your organization values most.

I would love for most of our serverless app workloads to be top-down organizationally driven but the reality of it is that it comes often from developers themselves and/or line of business organizations with skin in the game of seeing things move faster in most organizations. This will then typically require buy in from security and ops groups. If these folks you know have the trick to driving top down incompetent strategic management towards serverless I'd buy in on that newsletter.

In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey. I think there's also a larger number of people that represent IT vendors that would love to see AWS fail here :)

Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

and I totally posted this from the wrong account... sigh..

this is me. Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

> And so for data processing/streaming/batch [...] serverless actually does work out pretty well.

This is my field of expertise. Serverless in the sense of lambda/functions is not usable for serious analytics pipelines due to the max allowed image size being smaller than the smallest NLP models or even lightweight analytics python distributions. You can't use lambda on the ETL side and you can't use lambda on the query side unless your queries are trivial enough to be piped straight through to the underlying store. And if your workload is trivial, you should just use clickhouse or straight up postgres because it vastly outperforms serverless stacks in cost and performance[1]

For non-trivial pipelines, tools like spark and dask dominate. And it just so happens that both have plugins to provision their own resources through kubernetes instead of messing around with serverless/paas noise.

And PasS products, well.

https://weekly-geekly.github.io/articles/433346/index.html

>One table instead of 90

>Service requests are executed in milliseconds

>The cost has decreased by half

>Easy removal of duplicate events

Please explain.

[1] https://blog.cloudflare.com/http-analytics-for-6m-requests-p...

IaaS is the peak value proposition of cloud vendors. Serverless/PaaS are grossly overpriced products aimed at non-technical audiences and are mostly snake oil. Change my mind.

That article appears to be discussing a migration from Redshift to Clickhouse. Redshift is a managed data warehouse, not a serverless solution in the same vein as Lambda.

I don't understand the point you are trying to make.

Edit: The comment I am replying to was originally just 'Please explain' and a link to the article in question, and contained no other context or details.

Sorry I have a bad habit of making a comment and then actually writing it in full. I should stop that.

The issue of the application artifact size is definitely real and it blocks some NLP/ML workloads for sure. Consider that a today problem that isn't hard in Lambda.

But we've 100% got customers doing near realtime streaming analytics in complicated pipelines feeding off of things like Kinesis Data Streams. This FINRA example is one datapoint: https://aws.amazon.com/solutions/case-studies/finra-data-val... and this Thompson Reuters one: https://aws.amazon.com/solutions/case-studies/thomson-reuter...

These are nontrivial and business critical workloads.

Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

edit:

-------------------------------------

Missosoup i see you making changes to your comment and it greatly changes the tone/context. i won't adjust my own reply in suit but leave it as it was for your original comments on this.

I'm not going to make any elaborations on my comment now. Please feel free to edit yours or post another to answer anything I raised. Your original reply containing some generic sales brochures isn't what I expected from someone representing aws stepping into this discussion.

Quite a lot of ETL ends up being some minor transforms + a query or two.

Not all of it is massive ML models doing a lot of computation, and I've had a lot of success using pandas and numpy in it (and gcp cloud functions).

Serverless has its niche and is a great little tool to smooth the impedance mismatch between data stores.

Clickhouse is a really strange thing to compare to Lambda here. One is a method of performing small compute jobs, the other is an analytics database. They serve vastly different functions and saying "Clickhouse or postgres is cheaper and more performant than lambdas" is nonsensical.

Kinda wild in your post history you're advocating for AWS as a cheaper superior platform without disclosing that you work there.

Yup! Haven't done it in years and created this different account to be more clear/direct in who I am. That is also why I called it out at the start and bottom of all my responses.

Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

[meta] Please stop downvoting this. Clearly those comments were years ago and clearly the author has been doing the right thing for years since.

Maybe that's how he got the job.

No. I've been at AWS for over 7 years in a few different roles. Came to the serverless space >2.5 years ago because I felt passionate about it (could have literally done almost anything). Again, sorry for mis-posting under my older personal account, it was rarely used fwiw.

I wasn't criticizing you. I was pointing out that an equally likely and more charitable interpretation is that you posted as a fan of AWS before you started posting as an employee.

Turns out I was wrong in this case, but you've explained the situation and everything is hunky dory.

Hugs Chris!

Hug back at ya big guy!

Really? Hahahha

Miles and I know each other, what's wrong with a friendly hug?

Do you need a hug hesburg?

I recall a certain uptight code of conduct which explicitly forbids unasked for virtual hugs.

Yah, but I know him and we hug.

> In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey.

They also like to join the latest hype more often than not so that should even out the anti-enterprise sentiment. I don't think serverless is over that point yet.

General opinion regarding the topic: I haven't done serverless in any way yet, but if it's similar to "regular"/other cloud services then in my experience it only makes sense of you're so big that building a scalable infrastructure yourself is too expensive (unless you're Facebook or Google). The other use case is if your load is actually fluctuating a lot, to a point where having enough resources available just to handle the peaks at all time is too expensive.

Whenever you can somewhat predict your load, having your own infra is almost always less expensive (at least here in Europe/Germany).

An example of where serverless is lovely for us:

We run on AWS. We log lots of stuff to CloudWatch. CloudWatch allows you to scan for regexps (more or less) and send matching lines to a destination of your choosing. There are about 5-10 such matching events per day that we care about, and when they happen, we want an alert in a Slack channel (or email or text or PagerDuty or...).

Option A:

Stand up a server. Deploy a web service on it that accepts POSTs from CloudWatch and acts on them. Update the box as OS vulnerabilities come along. Pay 24/7 for a server that accepts 10 incoming requests per day.

Option B:

Write a plain Python function that takes the contents of a POST that's already been processed and has no other idea that it's living behind a web server. Drop it in Lambda. Pay for 1000ms of processing time per day.

I wouldn't want to run our entire stack on Lambda and friends, but for certain specific situations it's brilliant and I wouldn't want to give it up.

If you have spare capacity on a server you can probably squeeze in such functionality at no extra cost.

It's almost never about server capacity. It's usually about who's maintaining them, who controls the updates and versions of software on there, and which dept the server's billed to. All stuff that's reasonable for things of a certain size, but unreasonable for things too small or big to fit the process will.

Ah so it's serverless as a tool to work around corporate red tape, then ;)

I would love to see a study of how much IT spending in general is just for tools to work around corporate bureaucracy. I suspect the figure would be staggering.

A market that will never die!

But that makes operational expenses go up. For instance, now you have to tweak the Nginx config to support the service that normally lives on that machine and the new system. And you still have to write and maintain the web service driving it (which may not be hard, like a Flask app with a single route, but still more than zero). And you still have to maintain the server itself, which should involve regular OS updates and any work you have to do to automate deployment of the web service, unless you really like doing all that stuff by hand.

Or you can upload a single function definition to Lambda and let it do everything else.

Again, I wouldn't use Lambda for everything, but I'll gladly let it handle the stuff I won't want to bother with.

>But that makes operational expenses go up

On the other hand, you're probably all set up to do that already. It's no big deal. Introducing a new tech requires training, new deployment procedures, new documentation, etc., and now you probably have a one off component out there. There's a line somewhere, but if I were just adding a webhook for log events I'd throw it on a server I already have.

> ...at no extra cost

Complexity and dependency are costs too, and I would argue often more significant costs than the $30/month to run a server.

I like serverless for my own use cases, but I don't usually comment about it. People would probably not be interested. I have an HTTP call happen once every five minutes or so and just record the response. Thats it. About 100 ms of time. I would be paying more if I just had an always-on server doing this type of work. The sentiment we normally hear on HN is from people who really love or really hate something. I appreciate the option, but other than that I'm not going to be telling the world about my simple use case.

Hear, hear. I have a use case where I need to run some data extraction a few times a week that takes a few minutes and a few GB RAM to complete. I could simply squeeze it in on one of our other servers but that means the whole setup there would get slightly less elegant and would pollute the logs with weird load spikes.

Lambda is just perfect for such a use case, and the number of processing minutes makes it almost free.

> top-down organisational pressure created by technically incompetent strategic management

Do most people work in this kind of environment? At my company our management couldn't care less what technologies we use. They want to see reasonable cost and solid uptime, and they ask engineering to deliver that.

Imagine a new CTO or middle manager coming in, with a small ego, and a big need to prove himself, and initiating a make-work project.

What defense mechanisms does your firm have against this? Unless your team leads are golf buddies with the C-suite, it is unlikely that their opinions are going to be taken seriously.

How would your hypothetical defence mechanism tell which C-suite initiatives are worthwhile, and which are ego driven make-work?

That's the thing. The two are indistinguishable, unless you give people with strong technical skills veto power on projects. If you don't work in such an environment, the only reason you haven't ran into a dangerous, idiot manager, is luck.

For some reason, in most firms, the c-suite isn't super keen on delegating that power.

> The two are indistinguishable, unless...

So are they indistinguishable or not? Two things can't be a bit indistinguishable.

>HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

HN is a pretty good gauge for how a subset of a very startup focused portion of the engineering community feels about technology.

I don't know that the same can be said about it reflecting the opinions of the engineering community on the whole, or if the community is even unified enough for anything to be a representative sample. We're a pretty diverse and opinionated lot.

This! There are lots of people in tech that don’t know/visit HN !

I honestly doubt that anyone else in my team of 7 reads HN. There's one guy who might. The rest, it just doesn't seem in their character.

While we might like to think the opposite, I feel like the majority of people in our profession are like the majority of people anywhere -- going to work to work, and going on FB/twitter/reddit to waste time. I don't know many devs personally who take a big interest in the goings-on of the startup world or open-source world in the large. Do they care about spending some of their free time honing their craft or messing around with a new tool? Absolutely. But few seem like the type who would enjoy engaging in a quasi-philosophical discussion on the strengths of various design paradigms. They spend all their day thinking at work; not many want to continue thinking about the same sort of stuff during their off hours.

I agree. All I have done for the past 15 years is startups and I love HN, however in the last few years it has become very apparent there is a selection bias to people in startup/valley type tech. I spend a ton of time explaining to my CEO and CTO why a customer cannot just dump that old way and embrace the new hotness. The valley culture is a bubble and does not reflect that of real world IT in general. Still love HN.

> HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

....no, no it really isn't. HN is a bit of an echo chamber of people who care about being on the cutting edge. 80% of the rest of the industry goes home and stops thinking about software engineering.

Anyway, here's my two cents: I'm building a web app that has the following components:

* A super simple SPA frontend

* Like...5 API endpoints? that allow people to register their emails to the service

* A mailer that sends out a daily email at the time the user specified

* Like 5 more API endpoints for manipulating some per-user data (profile, preferences, etc).

For this use case, serverless is _perfect_. I'm using the "Serverless framework" which allows you to write the definitions for your functions (think routing rules, a la `routes.py` in a Django app) and CloudFormation directly into a YAML file, then it consumes that, updates a CloudFormation stack with all your bits n' bobs all connected together, and gives me:

* 10 or so lambdas

* Monitoring for all of the above, including pings if something goes catastrophically wrong

* A DynamoDB table to hold all the data

* An API gateway hooked up to all the lambdas

* An S3 bucket with my static assets in it

* A CloudFront distro set up to CDN all my static assets

* A DNS record to hook up CloudFront to my URL

* An SMS (emailer from AWS) queue to ship out emails on an hourly or so basis

This whole stack is declared and managed with like 120 lines of YAML and deploys itself in a minute or two, no extra automation or management required. It costs me like 2 dollars a month right now since I haven't launched the site, but by my back of the napkin calculations, it'll probably cost under 50 bucks a month with my expected traffic. Serverless can be great for this sort of thing, and if I do eventually need to migrate this to VMs running containers or something it won't be _that_ hard (it is, after all, just a pile of TypeScript running on Node).

Now, I'll be honest, it took me a full day of tinkering to figure out how to get static assets in an S3 bucket to publish to CloudFront, but that's because I don't read docs very well, and now I know how to do it for the future. I imagine if I had less hubris and found someone else's tutorial for doing so, I could have had it solved in an hour or so. But lambda does work for a lot of simple use cases.

I imagine that most peoples' shitty wordpress sites from 2006 would benefit a lot from being frozen into static HTML, dumped in an S3 bucket, and put on a CDN. They'd get security patches, OS updates, a global CDN and a bunch of other goodies essentially for free. And the sad reality of our industry is that most of it isn't building fantastically intricate real time distributed systems that both cook your breakfast and brush your teeth, it's maintaining some guy's shitty wordpress site from 2006. Tech isn't sexy outside of the FAANG/HN bubble, and _that's perfectly OK_. Serverless is a great paradigm for those people that don't need anything fancy, it's like the modern LAMP stack IMO. It's a good enough default from a performance and cost perspective for most people who have no business thinking about (or who just really don't want to think too hard about) their infrastructure.

Is it a pile of bespoke garbage that sometimes feels like it's going to topple over? Sure, but so does all the software I work on at my day job. At the end of the day, people should use whatever is right for the task, and serverless is great for low- to medium-volume mostly static sites and apps that have a little bit of data manipulation and a little bit of background processing but nothing that rises to the level of _needing_ to manage your own infrastructure. And that does really cover a significant portion of the industry, even if it's not being adopted by the 80% right now.

I don't think the only drive is top-down. I work in a place where devs get a lot of say in which tech we push (other than core languages; more just for hiring/market/support purposes) and there are a lot of devs that seem all about serverless .. and then are on 3 hour support calls with me because they can't get some set of A + B + C components working with lambdas.

I haven't done direct development with lambdas, but I've had to help other devs debug issues (currently in a devops role, but I was mostly a dev for like 15+ years before) and been to a few meetups where I watched people advocate, write and show severless deploys on AWS and Google.

I can see some use cases for it, but I honestly hate losing a lot of the introspection and debugging capabilities with them. I'd personally have to deal with setting up my EC2 instance or K8s/maraton deploy and being able to get to the underlying system if I need to. If things go well with a lambda, then you're all set, but the moment you need to start debugging anything serious, I feel like you're going to be in a world of pain.

In one specific instance, we had a developer who set up a lambda and also setup nginx to route to it because he didn't want to use API Gateway, which he got working, painfully after a lot of work. He should probably put up a blog post on it honestly, as I don't think it's officially supported.

Of course, this is all anecdotal. It's really difficult to measure things like speed and cost objectively with this stuff since everyone's stack and needs and uses are just a little bit different.

API Gateway gets expensive when things get busy. App load balancers also let you point methods at Lambdas though, so nowadays that's likely a better idea (and certainly more serverless) than doing the routing in nginx.

> if serverless works for 80%, then why is that 80% not even remotely reflected in the sentiment here? HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

Every time something sympathetic to a "hyped" technology is posted it's largely derided for being the "popular, hyped" option. MongoDB absolutely ruined the idea of NoSQL for years because everyone just meme'd about "webscale", without being willing to consider that maybe there's merit to the technology.

Are you seriously doubting that lots of people are moving towards serverless infrastructure?

Even internally at big companies they use "serverless-like" models eg:

* Lots of big companies have an internal FaaS

* Those FaaS are owned and managed by other internal teams, and are treated in much the same way as how you'd treat a 3rd party offering.

Serverless just outsources what those companies are doing already.

I leverage AWS lambdas almost exclusively. Yes I am paying a higher price for worse latency. That's OK. I'll pay money for that, if what I get in return is a managed hardware, os, and runtime environment - problems that generate billions of dollars in revenue for many different companies that are working on making it easier.

Performance is a problem I wish to address aggressively, but it's 3rd on the list. A rough approximation of my priorities might be:

1. Security

2. Complexity (including operational complexity)

3. Performance

Serverless gives me the tools to manage (1) and (2) in a way that has worked extremely well for me personally, and I have not found latency to be a problem for me.

Sadly, the site is down so I can not view the article and comment on things more concretely, however I saw the 8x figure and that's fine. 8x latency is fine for many workloads, but operational overhead isn't fine for mine.

edit: OK, so they just don't support HTTPS. It loads now. 8x cost, 15% performance. Cool.

Cool numbers and article, I appreciate what they're getting at. I don't see how you can walk away with "Serverless is all hype and never an option" from it, but whatever. I will once more point to the "Any time this comes up people bash it because 'hype bad'". The top voted comment currently is someone bashing serverless and contains literally no substance.

> Finally, I'm not trying to bash API Gateway, Lambda or serverless in general here, just showing that for some workloads they are a lot more expensive than boring old EC2 and Elastic Beanstalk

Really makes sense to me! Pick the right technology for your constraints. If serverless offerings like lambda could solve every use case AWS wouldn't need other services.

I spend six figures a month in AWS, on a mix of servers and serverless.

Serverless is more cost effective for sporadic, bursty things where the cost of an instance sitting idle outweighs the more expensive per-operation costs of serverless. On sustained load, it is almost never cheaper.

Another price to pay is complexity; it's simply more difficult to build, deploy, and monitor serverless systems.

> Another price to pay is complexity; it's simply more difficult to build, deploy, and monitor serverless systems.

What do you mean by serverless systems?

My experience isn't with AWS, but with Azure, so maybe it isn't an apples-to-apples comparison.

My experience has been that building, deploying and monitoring even moderately complex, interdependent Azure Functions has been less difficult than building the equivalent services to deploy to IaaS or on-prem. FWIW, a big part of that reduced complexity has been offloading infrastructure management to Azure instead our IT guys, but deployment and monitoring has also been practically painless. Are there some complexity "gotchas" that I've missed?

I too use a mixture of server and serverless solutions on AWS and you hit the nail on the head. Serverless is a really great solution for certain things that don't need to run all the time. If you are hosting a web server that needs to run all the time then just set up a traditional server.

We have a few lambda functions we use that send notifications or perform very specific tasks that are sort of on their own. Running on serverless is perfect for these. These functions are only invoked occasionally (a few times a month). So it is great that the Lambda only boots up the few times it is needed and I don't pay when it sits idle (most of the time). It costs me 10 cents a month instead of say $10 a month with a small EC2 server that might otherwise do the same thing.

Another great use case is bursting or inconsistent traffic/invocation patterns. For example, we have a use case where users can text/SMS in and receive a promotion code. We have this running on serverless because it runs very iradically. A nation-wide commercial will run and ask users to text a code, which triggers hundreds of thousands of Lambda instances within a few seconds. But then it might not run again for a month. On a traditional server platform, we would need a load-balanced server solution with several servers set up for redundancy on a huge influx of traffic, only for those servers to sit idle for who knows how long. You can't shut it off because people might text it at other times too, but you need to have a system that is available for "worst-case scenario" at all times (aka when a national commercial runs). You also don't know exactly when the commercial will run, so you have to always be ready. This setup might costs thousands of dollars a month on a traditional server system, but on Lambda it could cost $100 because we only pay during that huge influx of traffic. What I also like is that you can just trust that the Lamdas will boot up under nearly any traffic load. So you don't have to worry about making sure your server is "ready" or "the right size". If we get 1 hit, then we pay a fraction of a penny. If we get ten million hits then we pay $20 (really - it costs $0.20 /Million). Try to get the same reliability with a $20 server that can do that... spoiler: you can't!.

So I don't look at it as a slower solution that is more expensive. If you are running data analytics or a web server that is always on then this is surely the case. In which place I would say to use a traditional server.

But serverless has a role and it is great for infrequent usage, or for burst traffic. We love that we know we can get nearly infinite traffic and just pay per request without worrying about the infrastructure being ready. It is infinitely scalable, so that we don't need to worry about it.

It is always a pro and a con. I love serverless because it opens up new options for developers and system admins. It is another tool in our toolbelt. It is not the perfect solution for everything. We still run many vanilla EC2 instances for internal CRMs and webservers that run constantly. Or for booting up long computational processes. These are cases where servers are still far better than serverless. If we all learned to understand it as another tool available to us and not a "one or the other" requirement then there is a wonderful world where both tools can coexist.

Note: I use the word "infinite" very loosely in this post. I mean "infinitely scalable" in that it is scalable up to any reasonable amount, beyond what I would ever have to worry about. If the day comes that my servers are getting more traffic than Amazon is able to handle in their data servers then I will be far richer than anyone else here and I will come up with a new solution at that point.

I use both Lambda and EC2 a lot. The decision on which route to go for a particular service/feature/app is pretty straight forward for me: need to support high loads or super low latency? EC2. Low volume, unknown/unpredictable loads? Lambda.

Datapoint:

I'm using serverless because it lets me deploy a new API endpoint in a matter of minutes.

There is 0 configuration, and deployment is a single command. I also have my own servers running some of my APIs, the difference how much work I have to do is huge. Serverless on Google Firebase is literally "export a function, now you have a new endpoint!".

There is, quite literally, nothing else to do.

I can move 5x-10x the speed with serverless. There is less (almost 0) infrastructure to maintain.

Yes, it costs more, although the math with Google Firebase Functions is pretty trivial, everything is bundled under 1 service, and sending data around between Google cloud services is free.

Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit?

> Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit?

Startup, I am adding endpoints on a very regular basis as I build out the app. I probably add a couple a month.

As an example, I am writing one right now. It'll take me ~30 minutes to write+deploy it to test.

My long running and CPU intensive stuff is running on a VM of course.

I'm sure if I had spent several days learning yet another tech stack that I could create a system that let me deploy endpoints to a VM that fast, but I have Better Things To Do(tm).

I could also shove everything behind a single endpoint that has a bunch of options, but that brings in a separate set of problems.

Almost anything you were competent in would let you write and deploy and endpoint in half an hour (particularly in the early stages of app development), so I'm not sure that this is positive for serverless.

The amount of infrastructure I have to setup/maintain to do all of that is, well, nothing.

That is where the mental savings comes in.

When I first started, I went from "never wrote an HTTP endpoint" to "wrote a secured HTTP endpoint that connects to my DB" in under 20 minutes.

There is nothing for me to maintain. Setting up a new environment is a single CLI command. No futzing with build scripts. Everything will work and keep working pretty much forever, without me needing to touch it.

The sheer PITA of maintaining multiple environments and teaching build scripts what files to pull in on both my website and mobile app is enough work that I don't want to have to manage yet another set of build scripts. I don't want to spin up yet another set of VMs for each environment and handle replicating secrets across them. I just want a 30 line JS function with 0 state to get called now and then.

(As an example, trying to tell my mobile app's build system that I want a build with production code but pointed at my test environment? Hah! Good luck, the build system is hard coded to only have the concept of dev/prod! I've had enough of that.)

It is frustrations like that Serverless solves.

>When I first started, I went from "never wrote an HTTP endpoint" to "wrote a secured HTTP endpoint that connects to my DB" in under 20 minutes.

You could have had the exact same experience with Heroku or many other similar products that have been around for almost a decade and a half--it has nothing to do with serverless.

>The sheer PITA of maintaining multiple environments and teaching build scripts what files to pull in on both my website and mobile app is enough work that I don't want to have to manage yet another set of build scripts. I don't want to spin up yet another set of VMs for each environment and handle replicating secrets across them. I just want a 30 line JS function with 0 state to get called now and then.

It sounds like your architecture is far too complicated if you're managing all this by yourself. You don't need "a set of VMs" per environment if you're a small start up.

>Everything will work and keep working pretty much forever, without me needing to touch it.

If you believe that, you haven't been doing this long enough.

> You could have had the exact same experience with Heroku or many other similar products that have been around for almost a decade and a half--it has nothing to do with serverless.

See below with Ander.

I don't have much infra, I don't need infra.

(I do in fact have a couple of VMs because I do have a service that is stateful.)

Not having to think about anything aside from "here is my code, it runs" is nice. Debugging consists of "did I write bad code?"

> It sounds like your architecture is far too complicated if you're managing all this by yourself. You don't need "a set of VMs" per environment if you're a small start up.

For the few things I run on VMs I still have to manage secrets so they can connect to the right DB. I also need to point my apps to the proper environment. The app being dev'd on my phone needs to point to the dev server with the dev DB secrets stored on it. Same goes for the website on localhost, or the website on the development server.

In an ideal world I'd have a script that created new environments on demand and it'd wire up all the build scripts automatically. Every developer would trivially get their own VM and could switch parts of the software (website, app, services) to point to various environments easily.

Why in the bloody world some build systems hard code only 2 options in is beyond me.

> If you believe that, you haven't been doing this long enough.

Sure old runtimes will be deprecated, but let's compare that to:

1. Setting up nginx 2. Setting up letsencrypt 3. Figuring out why my certs auto-renew but nginx doesn't pick them up (Turns out default setup doesn't actually force nginx to pick up the certs!) 4. Learning about various process management tools for JS to keep my services running 5. Setting up alerts for aforementioned daemons. 5b. Probably involves configuring outbound email. 6. Realizing something went horribly wrong in 5b and my inbox is now flooded with alerts. 7. Writing scripts to automate as much of the above as possible. 8. This legit happened, there was a security fix to SCP on Windows that changed how one of the command line parameters worked, breaking my deployment scripts when running them from Windows. 9. Does Google really want to charge me per decryption to store my API keys in their cloud API key storage service? They have to make money, but ouch. 10. Security updates not just for code, but for the VM images.

Like, I get it, if my entire job is back-end development. But I want to write some functions that maybe hit double digit millisecond run times and throw away all their state after.

Firebase says "here, export some functions, we'll give you an HTTPS URL you can call them at."

That is the sum total of my relationship with the tooling. "Run my code." "Sure."

About the only other thing that works that simply is a headphone jack, and those are going away.

Again, none of this has anything to do with serverless architecture vs non-serverless architecture. There are many PaaS providers that would eliminate all of your complaints that aren't "serverless". They just manage the server for you. But you still write a normal app that you can easily run locally or port anywhere you want.

If you decide you don't like the service, you're app isn't tied to a proprietary API or architecture.

And you don't need to manage additional VMs for stateful services.

Only 2 endpoints per month? What exactly are you comparing to that doing it twice a month would waste way more time adding an endpoint vs serverless?

With Firebase if I need a new env I just type 1 command and get it.

With VMs I have the joy of managing my own keys.

VMs need security patches, updates, and I have to maintain images. I have to think.

It is hard to explain how simple firebase functions are.

There is literally no mental overhead. There is no worrying. There is nothing to maintain or think about, no settings up quotas or managing what machine something is running on or getting user auth setup. No certs that can expire or daemons that can crash.

I can come back 2 months later and count on everything I setup functioning just as I left it.

Some months I wrote a bunch of endpoints, I average 2 a month maybe, but if I am adding a new feature, I can pop out 3 or 4 a day, and then go on my way and work with the front end again.

Getting debugging up and running for them can be interesting (painful and bad), but everything else is just smooth.

I don't want to maintain a bunch of infrastructure, I want my users to ask for some data and get some data back.

If someone is doing non-trivial processing, serverless is probably not for them. But I have a bunch of 20-50 line functions that are all independent of each other and have 0 state.

I realize I'm paying a premium, but it is worth it to have this stuff that just works.

Ah ok so you're 100% serverless so functions are saving you all the headaches of running your own infra? That makes sense. It sounded like the time to add an endpoint was your main criteria and just seemed strange.

The time saved is time thinking about doing anything else other than "I want to write code". :)

> because it lets me deploy a new API endpoint in a matter of minutes

I've seen many projects that do the same without serverless just fine.

It's always been there, unless you had some enterprise-grade stacks. I was able to do this in early 2000s, with PHP and FTP, in a matter of seconds. Just upload that api/new_endpoint.php.

Not like this timing is the big deal, unless you really need to add those API endpoints real quick.

> I can move 5x-10x the speed with serverless.

I'd argue this is only applicable to the initial setup. There is one-time investment in designing your own infrastructure, but you can move fast on anything well-designed.

And it's not like serverless designs are immaculate. Just recently I was listening to Knative introduction talk and my obvious question was "what happens to event processing if servers that power this system fail and processing job just dies without a trace". Turned out, there are no delivery guarantees there yet. My conclusion: "uh, okay, blessed be the brave souls who try to use this in production, but I'll check out in a few years".

> There is less (almost 0) infrastructure to maintain.

It doesn't run on some sci-fi magitech in a quantum vacuum. The servers and networks are still there.

The benefit is that you don't have to design them. Saves you some (possibly, lots of) bootstrapping time when you're about to make your first deployment and ask yourself "how" and "where to".

The liability is that you can't - so when things break your can only wait, or try to re-deploy in hope that it would be scheduled to run on some servers that aren't affected.

We’re using Serverless where it fits and carrying on with our lives. I don’t feel the need to try and defend tools, because it’s exhausting. There are certain load graphs for which regular servers can’t follow the line in time, some for which regular servers can follow the line but would result in overprovisioning, and some in which request isolation is just a great thing to have. For these loads we use Serverless, for the rest we use normal EC2 or ECS.

Just understand the job and use the right tool for it. This fighting over Serverless and servers is like arguing over whether hammers or screwdrivers are better tools.

> HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

HN is a pretty good gauge for how Silicon Valley feels about a particular technology.

Here's an anecdote: I'm a one man shop who has been planning, developing and deploying Django applications for six years. I have not got to the point where my deploys are automated because I am swamped with work just keeping my clients up to date and my servers ticking along. I usually deploy one client per $5 DO VPS.

I just deployed my first project to PythonAnywhere and I am blown away at how much easier is. I'm going to pass the cost on to clients and that's that. I'm going to be less stressed and can concentrate on what I want to do: build applications.

I don't know if it's "severless" in the same sense as AWS Lambda or whatever, but I can imagine many solo/small shops seeing less ops work as a godsend.

That just looks like a standard PaaS to me--Heroku has been doing that forever.

> I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues,

Wow. Sounds like you should not be so certain.

FWIW. It has worked great for us, saving us mid six figures per year or more. The savings keeps increasing as we figure out ways to move more of our workload over to Lambda, we are even running PHP there. Step functions, lambda, sns, sqs and api gateway are pretty cool tools for a lot of projects when used properly. I think the paradigm shift in how you need to make things work is frustrating for some, but once you get it, it works nicely.

I have also helped engineers at two other companies start making the switch and they are both happy so far... so, in my (obviously limited) first hand experience it works 100% of the time. :)

mid-six figures is $500k?? Are you factoring in salaries to get to that number or merely AWS spend? I'd love to see a spreadsheet with this analysis.

fair question... $500k in measurable lowered AWS spend(cancelled RI's and end of term and never renewed). if i figured in salaries and was fair about it, id say about 80% of that was actual savings, 20% was related to costs involved with rewriting or porting code. i wouldn't count the costs of new features into that as that is still forward progress, just writing in Lambda rather then for life on a traditional web server.

to put this into perspective we have grown about 10x and our monthly AWS bills have actually lowered. so I have no way of knowing what this workload would cost on EC2, going down that rabbit hole would produce a "savings" number easily into the millions.

Man, that makes no sense to me if it's just aws cost -- very basic back of the envelop calculating assuming you had $500k to spend per year on cpus on aws:

A c5d.2xl (8 cores) on aws is about $1875 per year reserved, $500k per year would buy you over 2100 cores; if you only did 100 req/s per core, you'd be able to handle something like 213k req/s average.

Just the alb costs on lambda at this request rate would cost you $10MM annually... 20x the cost of doing it on VMs.

    >>> 500e3 / (1875.0/8) * 100 * 60*60*24*365 / 1e6 * 1.51
    10158796.8

    $500k to spend
    $1875 per box / 8 cores per box
    100 req/s
    60*60*24*365 seconds in a year
    1e6 requests per $1.51 of alb spend

Staggering the amount of work you can do with just the amount of money you saved and it seems impossible to me that lambda was able to account for this?

I'll color the picture in a little more, maybe that will help make sense of it.

We have a unique workload that includes very large bursts of work that need to be worked on ASAP. Spinning up instances on demand is not fast enough, so we had a lot of servers sitting idle. Lambda allows us to execute this same work for much cheaper because we aren't paying for idle CPUs. Lambda also allows us to execute at much higher concurrency than ec2 would, for the cost. 15000 Threads spread across 100's of IPs is easy and cheap on lambda, not so much on EC2.

We went from ~250 customers per cluster(our term for a set of dedicated workload servers) to 2600(haven't pushed it past there yet). The work that was done on those instances is slowly being moved to Lambda and all new work/features are added to Lambda directly. This has effectively allowed us to drop a few clusters and also move to lower resources per instance.

FWIW we don't use ELB for Lambda, they come in via API Gateway, to Lambda/Step Functions directly or into an SQS queue in the case of workloads that have rate limits. For Lambda based workloads it breaks down something like 56% of cost is Lambda, 34% of cost is Step Functions and 9% is API Gateway.

Yeah, cool, so very unique workload - I'm not surprised there are apps that fit lambda in a cost effective way, they're just not typical I think.

Thanks for the explanation ;)

The only application where I've found serverless to work well is for simple plumbing/event sourcing in AWS. They are less apps and more "tiny scripts that automatically run". 99% of the work is still done in containers on actual servers. The serverless portion is by far the least "developer ergonomic" but that's not a problem if your code is less than a hundred lines and rarely subject to changes.

The idea of running your entire app as serverless sounds like pulling teeth. Thought leaders are free to pat each other on the back on that one... I won't mind being called a luddite.

The most interesting thing about serverless for me isn't 'web scale' its 'scale to zero'. My apps tend to be bursty, with trickles of data in between. I mostly concerned in reducing their 'idle' costs, so not having to manage the OS, security etc is a massive cost saving for us.

> There are valid reasons for serverless

Those scenarios are probably just as happy with a PHP script on Apache.

It sounds like what you're saying is for OP to have been able to leverage serverless properly, he should have fired a devops engineer?

> most people choose it for reasons other than hype

[citation desperately needed]

Managed servers also exist and are in quite of a sweet spot if you need the performance.

>We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests)

That goes without saying!

That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before.

I don't think anybody uses things like AWS or serveless services because they're faster or cheaper...

> That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before.

Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle.

Other forms of serverless might save time. However there's always edge cases where they don't and you can lose hours or even days investigating an issue that would be a quick fix if you actually managed the host and/or application.

So the short answer is: not always faster nor easier. It really depends on what you're trying to accomplish.

> I don't think anybody uses things like AWS or serveless services because they're faster or cheaper...

Actually yes they do. But like my previous answer, it depends on what you're trying to accomplish.

This is the problem with serverless (and cloud computing in general). People try to distil it down to "this is better for x" and "that is better for y" but actually the benefits and trade offs are far more granular than that. To the extent that you could have two companies in the same sector releasing competing products and still what architecture makes sense for one company might not for the other.

This is also why nobody ever agrees about these topics online - by the time you've generalised the examples enough to describe them in a forum post, they lose the specificity that makes any accurate design possible.

Can't agree more. One example is CI/CD through docker image, building image / deploying container may take ten to thirty minutes long. It's a hindrance for quick bugfix / tempering on test server.

> Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle.

This has not been my experience at all. Maybe because I have a lot of experience with Lambda, but I find them to be a very fast way to get code written and running.

Granted, Lambda is a great tool for a specific category of task. Namely, when you need to programmatically respond to some event which was triggered by another AWS service and can do so in under 5 minutes. But it's poorly suited for tasks outside of that domain. In that sense, it's like Bash: you don't want to do everything with it, but there are situations where it's the best tool.

1 programmer/ops guy can do what it took 10 before.

The myth: devs are expensive and hardware is cheap

The reality: webdevs are a commodity and AWS is making record profits

The real reality: not all devs required are webdevs, especially if you want to build an infrastructure that can handle millions of people worldwide. It's not like some React and CSS will get you that.

The amount you'll pay for a single additional developer, even if it's "just" 70K, is already close (if not double) your whole Clould costs when you start...

Yes. And there’s also the issue that even if someone would choose to work for free, incremental bodies in an org tend to increase the org’s complexity.

When you start you don't need to handle millions of customers worldwide. If all you need is to handle a million customers per month digitalocean can handle that on a single server and you wouldn't hire a single let alone many developers to manage that.

If you ever reach the point where you need to handle 100s of millions of customers a month / hiring someone can save you money but perhaps serverless makes sense.

99% of businesses will not reach that level.

> it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before

Perhaps it's more related to the programmer than the tech stack...

It's also not solely developping, but debugging too. And serverless does make things a lot harder.

Why does serverless make things a lot harder? I'd argue that the stateless nature of serverless actually makes it much, much easier to debug.

If we really want easy, we’d all be writing ColdFusion or Visual Basic.

If we valued productivity, and those were indeed easier, then we should.

There's no real pride in not valuing easy if it's also good.

Why did we move away from VB? Great for writing for a single platform.

Cold Fusion had issues that would prevent it from taking over.

They can be a lot cheaper. Maybe only in some cases but then it can make a difference.

Agreed.

~2 years ago I seriously looked into Serverless and very quickly discarded it after seeing a large production deployment of it. I didn't have access to the billing info but the site loaded much slower than a regular site and developer productivity was quite low.

I'm going to stick with good old servers for now. If anyone is curious, a few years ago I did a write up on "Should your next project be built as a Serverless app?" which compares deployment styles in a bit more detail: https://nickjanetakis.com/blog/should-your-next-project-be-b...

Hey nickjj, you may want to update your blog post to reflect that the Lambda timeout is now 15m, not 5m.

Hi, thanks for the heads up. I just updated it.

It isn’t about “reality” it’s about trade offs. Every choice you make when it comes to infrastructure, whether to build or buy, etc comes with trade offs. The trade offs and benefits of using lambda isn’t a secret.

The true cost of any product is the project lifecycle cost. There are many cases where a serverless architecture would cut down on that.

There are enough results to prove that serverless is useful (may I say, correct) architecture in many use cases. Not everyone is dumb, contrary to a common belief. Don't be religious.

Everytime I read these types of articles, I immediately login to AWS billing console and review our costs.

We switched to AWS serverless about a year ago (API gateway and Lambda) and there have been no real surprises.

I've been able to increase our contractual SLA uptime to customers (and charge for it).

We can kick-off more backend async processes and let the magic of auto-scaling just do it's thing.

If anything, I now have a fear of getting too complacent, as we no longer have a FTE SRE monitoring infra. If something goes seriously wrong, we have to rely on our DevOps AWS console skills to troubleshoot.

But similarly, if the power goes out in California, I have to rely on PGE to fix the issue. Serverless is also a cultural decision to outsource the infra.

Those SRE infra skills pretty much crossover with knowing what your app is doing in FaaS environment.

How do you know those async requests are completing? What's the percentage of failures? Are you meeting those SLAs? Who's patching the code? How do you test and deploy new versions?

Those are all typically seen as ops tasks, now you're doing them.

Small bit of concern around you saying you're using the console, because good testing generally requires Infrastructure as Code, but I suspect the reality is your operational readiness meets your risk profile. That or you're winging it ya big cowboy. :p

AWS Cloudwatch pretty much delivers every metric imaginable.

Whether leasing EC2 servers or running serverless Lambdas, the logs all rollup to the same place.

We're gradually using more AWS CLI for things like deployment and policy management. But the console is sufficient for 80% of Serverless DevOps.

Getting metrics into the system is only half the battle; using them is arguably more important and complicated half.

And well, I mean if all your guys are just trusted to directly use the CLI or Console, then what you doing for governance and insider threats? Using logs? Blind trust?

As I said, how you're doing things might be fine for your risk profile, but probably not when you could suffer a $1m GDPR penalty, and actually, more than just the money, the ethical issue of fucking over your users matters to some of us.

Not having a go, just saying there are reasons people use terraform, stick it in gitlab, and use CI/CD. You might be too small for that, or you might not have the data, but we aren't doing it for fun :p

> Tech should be about results, it should not be a religion.

I couldn't agree more with this.

I'm trying to get a small library [1] I wrote popular and it's insane how much resistance I get because it doesn't fit the "mainstream religion" of using GraphQL.

People are brainwashed to think API = REST or GraphQL. How many times did I see a RESTful (or even worse GraphQL) for an internal API where RPC would be so so much simpler... (GraphQL is great for third parties but sh*t for internal stuff.)

[1]: https://github.com/reframejs/wildcard-api, a RPC library for Node.js server <-> Browser.

You know what I actually like Serverless (AWS Lambda) for?

Adding a script that is triggered upon a new message to an SQS queue. The cost in using AWS Lambda is actually in the use of API Gateway, and it doesn't use that, as well.

Now, you're right, I didn't find this from any thought leaders, etc. In fact, I would disregard anyone who couldn't give me a concrete use-case and a cost/benefit overview for a technology. I have met a few executives that more or less were trojan horse leaders for other companies' technologies. Salesforce rings a bell.

If you want something performant and cheap you just need to go with Assembly. It's expected that super flexible software platforms are very costly.

Not only that, but it is also way harder to structure and develop than a normal application. At least in my experience.

if you work for an org that has cash on hand but not a lot of developer talent, the tradeoff is worth it. If the difference is going to cost you $50k a year but let you hire one less programmer, it's worth it.

Serverless was just a lock in model pushed by big cloud vendors.

serverless is just servers_over_there :'). same shitty security. just a bit flexible pricing which might or might not benifit people depending on the pricing model and load averages / paterns.

most excuses people give for going serverless is just handing off responsibilities to cloud providers to be able to point and blame if the shit hits the fan.

amen

Reply on news.ycombinator.com