Hacker News Reader

Comment by Aeolun | Hacker News Reader

I feel like it’s an object lesson in using the right solution for a problem. Step functions do not appear to me to be something that you’d use for things that need to be executed multiple times per second.

View on HN

Having occasionally looked at them for workflow driven tasks I'm not sure what the use case for Step Functions is, unless your workflow being called once an hour or something they seem infeasibly expensive for what they offer, and somehow manage to be more complex than just writing some code to model the workflow.

It's a BPM product. If you have a highly regulated workflow that has to be changed a lot by multiple parties, these products start to make sense. The AWS step functions aren't that great in the BPM and workflow automation either, but I imagine AWS just wants to have a first party offering.

Yeah, this is my takeaway too.

I'm pretty happy with the monolith that we run at our business and this seems to validate our decision to stick to that monolith, but I'm also pretty confident that where we use AWS Lambda, serverless is absolutely the right way to go.

For example, I've written a Lambda application to reply to webhook calls and send API calls whenever those come in. It costs maybe $2 per month to run in compute and requests. Would that make more sense to rewrite as a monolith and run on EC2? I really doubt it.

For some Alexa integrations it is neat and convenient, but I went back to hosting such small interfaces as a service on another server. Not an EC2 instance, just another hosted unmanaged server. They are as cheap as they can get right now.

I'm not really interested in the operational overhead that brings for these small services. Cost-wise they might be just about neck-and-neck, but at least I don't need to worry about the server going down, or having outdated software. Lambda gives me scaling, load balancing and redundancy for that $2.

> these small services

I think you might be unintentionally arguing with a strawman, as everyone else here is talking about using monoliths instead of that.

Few people want to administer a bunch of micro services themselves, but running a single service on a box is pretty low effort, even if you duplicate it for fail over/redundancy

By "using monoliths", do you mean bolting all code you write into a single runtime, even if they are not the same service? Because that's not what was in this article. Instead, they took Step Functions and a bunch of Lambda functions, and created a brand new monolith from that.

> define monolith software

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

"mono" stands for one/alone/singular, so monolithic is kinda defined to be exactly that, yes.

You can still have multiple monoliths, but they wouldn't communicate with each other and would be entirely separate applications.

I didn't say that my Lambda application communicates with my monolith. Just that I have a monolith and a Lambda application.

From experience I say that the operational overhead to host on Amazon isn't trivial at all.

I like AWS and I would still recommend it. It saves some work but also creates new stuff to do. Especially if you also want the costs be manageable. Automatic updates, configuring a firewall + reverse proxy with automatic certificate renewals and you favorite deployment mechanism isn't more complicated or labor intensive than managing a small application with AWS. You need to interface it just like software you run on your server.

One of the services I host needed to be authenticated by IP. Happens. You easily get a static IP on AWS for incoming traffic. No problem and cheap too. Now try to get one for the other direction... Possible too, but maintenance just became at least as labor intensive as hosting your own machine. AWS just has to fit your scenario and I think many people overestimate how comparatively easier it has become to host a server with feasible security today. Chances are your databases would be less public than if you skip the AWS documentation.

If you already have those instances for something else, there's rarely a good reason not to cohost. Save $2 a month and the maintenance burden.

In your example, you compare Lambda against a separate monolith for handling the webhooks, but with a monolith wouldn't the comparison be between lambda and just adding a route and controller (or equivalent) to the monolith?

I'm more thinking of rewriting the application (a bunch of Lambda functions + API gateway + random bits and bobs) as a monolith and running that separately on an EC2 instance (or any other VPS).

In this article, they didn't bolt the serverless architecture onto another existing monolith, but rather rewrote the Step Functions and Lambda functions to be a single ECS task.

But background tasks are a thing. You could add a webhook endpoint to your monolith that writes a background job. Then your background worker (running on the same ec2 because it’s hardware requirements look pretty low at $2 a month in lambda) runs the job. $2 a month is now $0 since it’s running next to your monolith on the VM you’re already paying for.

It really depends on the quantity & scale though right? If in my entire estate I have a single shell script that I run - wow lambdas / serverless are amazing.

When I have 200 things that cost $5/mo each to run but fit nicely on a single 8core/32gb ram server.. then this lambda stuff starts to seem crazy expensive right?

Reply on news.ycombinator.com