Hacker News Reader

Comment by aeturnum | Hacker News Reader

I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution.

As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these environments have difference performance, cost and maintenance characteristics, but I think of the star feature of serverless as the light deploy. For companies that don't have a deploy chain, that makes serverless very attractive, but if you've already invested in one it seems less compelling.

I think serverless products have a ton of potential for side projects and hobby projects. It's great that you can just type out python and access it on the internet immediately! That quality just never seemed to be what was holding back SAAS companies.

View on HN

Another niche where it shines is the small, low-volume tool. You don't want to give it an entire VM, because that's a major waste. You don't want to have it share one "tools box," because it is awkward sharing like that, security becomes more of an issue, and it generally devolves into a mess. So if you've got other things running on AWS, then AWS Lambda is great for this. Do you need a random web-facing snippet to receive a webhook a few times a day and send a Slack message to your team? Perfect.

Not the core of your app, but a tool of great utility. On the other hand, this isn't exactly the Serverless Revolution either.

This is why Serverless will be huge in enterprise IT. You just described 90% of workloads.

I use that a lot. There's the joke lambda spackle sticker (https://www.thecloudpod.net/product/lambda-spackle-sticker/) but that's exactly the great use case.

Thanks for mentioning our Lambda Spackle sticker. :-) Just throw a little lambda at all your op problems.

I called it "dabs of glue", usually in the context of warning against going crazy with the glue gun.

I'd add on top of that, that it provides even more value when volume is usually low and sparse, but unpredictable.

If you have a server that can handle up to 100 requests at a time, but you're only getting one or two a day, you could probably save money by switching to serverless. On the flip side though, you're also a bit screwed if 1000 requests all come in at once, since, even if you have some autoscaling solution, it probably won't be able to bring new servers up in time. Serverless provides a solution for that case as well, since you have almost unlimited resources.

But yeah, serverless is a tool for solving a certain set of problems. This idea of the "Serverless Revolution" was kind of silly from the start

> Serverless provides a solution for that case as well, since you have almost unlimited resources.

Not really, since it takes a few seconds to spin up all the serverless instances, so your app response becomes really erratic.

Then you need some magic to deal with database connections from 1000 lambda functions. All of them use their own since they cannot pool.

multiple seconds??

what platform?

AWS, inside a VPN. To be fair, it used to be 10ish seconds, and they improved it quite a bit.

All the platforms (GCP, Lambda, Azure Functions) have fairly long cold start times, but some platforms let you essentially pay for one or more cold start instances that are always on (I saw Azure had this, others are sure to follow). According to the article this "undermines" the model, but I disagree, as instance start time measured in the seconds is crazy difficult to achieve when doing VM automation. Typically it'll take 5m to get a fresh VM into the load balancer during scaling, could be as low as 1-2m if you do it just right. Buying one or two instances and then having the rest of the requests billed per invocation with a fast scale up time is very appealing.

We happily connection pool using sequelize by leveraging the fact that lambdas run in reusable containers.

If the next lambda invocation happens within minutes of the previous one ending, you can carry forward a db connection from the older lambda, no magic needed. Just place your db connection object in global scope (nodejs).

Yeah, they can use the same connection for a while. The problem is that 1000 lambdas cannot use 50 connections while waiting their turn. Each of them wants a connection to the DB server.

Now if you somehow get a spike of requests to some endpoint that goes over your DB connection limit, suddenly all your newly scaled functions fail because they cannot get a connection to the database.

AWS added a service for RDS to deal with this, but it all just feels like a big kludge to deal with a problem that shouldn’t have to exist in the first place.

My view is that logic shouldn't be retrieving or storing data. Separation of Church and state, so to speak.

If you are expecting one thousand simultaneous requests, serverless or not, you will need a db and an appserver which support one thousand simultaneous connections. There is no getting around that.

You will have to analyze your burst rate and the lifetime of each request to figure out the size of your connection pool.

I also am not clear how AWS introduced the problem of not being able to connect to the DB. We've known about the need for connection pools and connection reuse from before AWS was a thing, no?

If your function spends 80% of its time on logic and 20% on database time, with a server app, you can get by with 200 DB connections to handle that throughout, but will need 1000 connections in a serverless setup.

I don't think connection pooling works this way. Happy to be corrected.

A process is given a connection from a pool when it requests the connection and holds it until it relinquishes the connection regardless of whether the process was in the logic or data access portions of their lifecycle. It is up to you as the developer to ask for the connection and to return it on an as-needed basis...Which is exactly what you should be doing in a lambda as well.

Just because a lambda container is persistent does not mean the connection given to it is stuck to that lambda even after that lambda returns the connection.

Lambda does hold onto it in order improve response time. It connects to the database in a handler outside the context of a request, so you do hold onto N connections persistently (at least until the lambda scales down).

With a connection pool, you don’t need to hold onto a connection longer than necessary, but you are right that you could implement it in such a way that you hold it for life of the request.

I believe there’s a setting in RDS to enable connection pooling.

I've never understood why people who would never dream of using a single-instance application server are ok with using a single-instance datastore. Of course your datastore needs to autoscale just like your application does. Duh.

That only works if you’re relatively latency tolerant. Serverless systems currently suffer badly from cold start issues, particularly when large spikes arise. This can be solved, but it involves enough silliness that paying for a VM is probably cheaper once you factor in engineering time.

> Do you need a random web-facing snippet to receive a webhook a few times a day and send a Slack message to your team? Perfect.

How many people have that use-case but not in multiples? How many of those people have such a use-case but would not be better served by platforms such as IFTTT or webhooks on other services?

Exactly our use case, esp. for things that are outside of k8s, for example, standard tasks that every cloud account of ours needs to perform (they are heavily segmented due to regulations) and developers or k8s ops do not get to touch. Almost all are on events or timers. Cronjobs without infrastructure to worry about are nice. Basically I wrote some of this stuff 5 years ago and didn't have to look at it since; it just runs.

I use Node-RED for this. Cheap and very flexible.

To be honest, the serverless environments I dealt with had worse deploy experience than plain servers. There's a bit of a ritual around deploying a lambda for example and it requires a specific packaging process. I can't easily use poetry for python projects there.

I guess if we count fargate as serverless, it's much better for this use case.

While I am not that big fan of serverless projects (I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) you can use poetry with lambda.

I'm sure there are other ways of doing it, but the way I do it is using serverless framework (is a nodejs app) together with serverless-python-requirements plugin. The plugin understand poetry (make sure you don't leave requirements.txt because it will use that, you don't need that file if you use poetry).

Anyway it has warts, one big thing is that nodejs developers don't care about norms and standards and constantly reinvent the wheel so for starters you're pretty much forced to create project.json project-lock.json files, which then will create node_modules directory in root of your project. Then you need to start project through npx command (I believe you could still install serverless globally but looks like that's being depreciated).

The node_modules directory will contain over 200MB of javascript code after you install it.

But after all of those things, when you get it to work it is not terrible.

>(I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it)

I've created a whole photo sharing website in AWS Lambda, including a complete user accounts system (register, login, forgot password, email verification, profile photos, etc), social aspects, as well as other things like youtube video search and transcoding in the same system.

I also had to create my own Lambda build system because what was out there wasn't what I wanted. I wanted to be able to hit save on a file and have it repackage my Lambda on AWS (using a Lambda to create the lambda) including shared code in 'Layers'. Kind of a "live-reload" for Lambda. It's all working very efficiently.

This was a lot of effort though, but now that I've got a basic system I can extend it to any kind of website.

My photo sharing site for friends costs me about $0.25 every few months, and that is mostly/all the cost of storing gigabytes of photos on S3. No, it doesn't see a lot of traffic, and that's exactly why I chose Lambda to build this site on, because I don't have to run an EC2 instance for my photo sharing site 24/7 if nobody is using it. It's worked out exactly how I wanted, costs me practically nothing to run every year.

And, if I did build a system with a ton of active users, Lambda handles the scaling of that. Another reason I spent the time to create this build system and write all the code to handle user accounts, etc.

> And, if I did build a system with a ton of active users, Lambda handles the scaling of that.

This is a bold claim to make without verifying it.

> Another reason I spent the time to create this build system and write all the code to handle user accounts, etc.

But did you also spend the additional time to scale test it and verify it won’t break in confusing and annoying ways when scaling / spiking up? (see the other discussions re: connection pooling above).

The reason a lot of folks are skeptical is that in practice there don’t seem to be a lot of great examples of stateful services using a “pure” serverless lambda pattern but with arbitrary dependencies that actually do scale smoothly and don’t break in annoying ways such that you end up building something more complicated than just using App Engine or Heroku...

> > And, if I did build a system with a ton of active users, Lambda handles the scaling of that. > This is a bold claim to make without verifying it.

I mean, Lambda's ability to scale is a well documented thing. It will happily do more if you ask it to.

The real scaling problem is your wallet, because Lambda is damn expensive once you have any somewhat serious compute requirements.

Among other reasons, enterprises love serverless b/c it relieves them of many server maintenance costs and risks. This includes things like:

  - OS patches and emergent fixes
  - Compliance certification
  - SSH access control and auditing
  - Secret distribution
  - Log rotation and storage
  - TLS termination 
  - Configuring and testing auto-scaling policies
  - Deployment configuration (rolling deploys, blue/green deployments, connection draining, etc.)

They can do the same thing with fargate, and that’s tons easier to manage.

Fargate is considered a serverless service. Serverless generally encompasses FaaS + BaaS. Think anything whose infrastructure you can use without touching the underlying VM(s): SQS, SNS, EventBridge, RDS, Lambda, Fargate, Athena, Kinesis and so on.

Fargate is still pretty expensive.

You don't need serverless for that. Any PaaS such as heroku provides those benefits.

I'm not really interested in having the 1,000th discussion about the definition of "serverless". The parent was wondering what the value of the paradigm is, so I provided a list of specific features that many companies consider valuable with serverless offerings.

I hope this "risk aversion" mindset starts to apply to code as well.

Can't wait for codeless, zero code, nocode, whatever name it gets called... something where normal people can build their own ideas without having meaningless discussion about tdd, frameworks and etc, nor the need to maintain codebases, ci/cd and all the jazz

It actually does:

"Low-code" is the buzzword to search for. It's been around a while now.

Of course like all the things the idea has existed a long time, but "low-code" development services seem to be increasingly popular and visible in the last couple of years, and they do seem to be getting more advanced and ergonomic.

Literally nothing in that list is unique to Serverless. There is in fact at least 2-3 ways to do that in AWS alone using VMs.

Serveless platforms like AWS Lambda are great for "glue" between services, or for workloads that are used infrequently. It can also be a great replacement for scripts that need to be run via a cron job (its surprisingly hard to create a highly available idempotent cron system using servers) provided all of the dependencies fit in the small space allotted.

I'm not sure I understand your point about not needing a deployment chain. I developed a framework (open sourcing it soon) using Jenkins Pipeline DSL for deploying Lambda functions and its very useful and helpful.

Regardless of the target environment the reasons for using a deployment pipeline are still there even if you use a server less platform.

One serverless scenario I find useful is for processing messages from low-volume queues. It avoids having to stand up "real" infrastructure that would be under-utilised.

Of course, if you already have servers with something like k8s or Swarm running, you might deploy a container there instead.

Part of the problem is that the hobbyist market is overwhelmingly PHP, which Lambda doesn't support natively.

I’d be curious to see the data behind that claim that the hobbyist market is overwhelmingly PHP. I must not have any exposure to that ecosystem because PHP does not come to mind when I think of hobbyist development.

Maybe not hobbyists, but wordpress alone powers like a a third of the web.

Sure, but Wordpress is nothing to do with PHP lambdas.

Yes, that's kind of my point :)

is it, though? Every person I know with side projects writes them in either nodejs/ + react/vue or django/flask + react/vue/templates

That is just the divide between frontend devs and backend programmers.

Not necessarily. After I discovered node/typescript I don’t think I will ever go back to PHP.

In my workplace our main product is written in PHP. Still we have a bunch of Lambda functions written in node we use all the time

Not natively, but fairly easily. We’re using Laravel Vapor - it handles all the setup and deployment of Lambda bundles that include the app code and a PHP runtime. Smooth and fast so far.

Yeah; I'd imagine anyone technically savvy enough to use Lambda + API Gateway, in any form, is savvy enough to bundle PHP if they really want to use it. And if they're not savvy enough to do that, they're probably using hosted Wordpress somewhere and it's a moot point.

Reply on news.ycombinator.com