Hacker News Reader

Comment by colllectorof | Hacker News Reader

>Almost all applications have data and separate from code.

Almost all applications aren't distributed in any meaningful sense of the word.

If you aren’t doing distributed applications, why are you even considering lambda - the main purpose of which is massive parallelism?

Because 'you' don't get to make the decisions.

What type of organization will ignore experienced developers that can rationally argue the type of architecture? I've been developing professionally for over 20 years and I can honestly say that I’ve never been overridden about small scale architectural decisions like should we use lambda versus an EC2 instance unless the decisions makers had some larger insight than I had.

I don’t mean I could have decided whether to go to Azure or AWS or use Oracle instead of SQL Server or something on that level.

I'm not in this arena at all but Amazon's lambdas seem like a way bigger architectural decision than azure vs AWS or Oracle vs sqls

It’s acrually smaller. A lambda code wise is just a function that takes in two parameters. Like I said before, architecturally, your lambda entry point should be skinny - take in lambda event data, map it to your domain object and call your domain services (not http services, your business layer).

In fact, you can take a standard C# web api and using the AWS SDK deploy the same code either as a lambda or you can do a standard deployment to IIS or a self hosted executable with Kestral

I’m speaking in terms of .Net but the same concept applies to any language.

One project has your lambda interface with a dependency on your domain classes.

A second project has your standard controller code with a dependency on your same domain classes.

You can have yet a third project that in my case uses TopShelf - a nuget package that makes it easy to create Windows services - that also uses Kestral to self host a web service.

I can deploy the same code to either IIS, Windows as a service, a Linux VM (with Kestral without TopShelf) or lambda. The only difference is the code deployment part of my CI/CD Pipeline. I use AWS CodeBuild with a preconfigured .Net Core Linux Docker container that builds to either target and stores the artifact as a zip file to S3.

None of this onerous. I test locally on my Windows machine and just push to git everything else just works based on some yaml files.

For us, lambda is great for the random junk drawer of compute load. Cron jobs; miscellaneous async jobs we'd have used something like sidekiq for in the past; infrequently used microsevices (where cold start doesn't matter) like schema registries (where client caching means it might not be hit for days). In the past I've had "job servers" running these various things.

Yeah, the article isn't arguing about those things, but the rest of the jobs, especially data dependent things. For non time critical miscellaneous stuff lambda is great.

Is the main purpose massive parallelism? I was under the impression it was mostly for rarely used resources, because you only pay when you use them.

I think another very huge benefit is that developers don't have to worry about infrastructure.

I don't know if its there yet but at least I imagine that's something serverless technologies strive towards

Not worrying about infrastructure implies trivial portability between IaaS providers... Is that at all true?

Again in the real world, an AWS shop isn’t just going to pick up and decide willy nilly to pick up and go Azure just to temporarily save a few dollars.

Reply on news.ycombinator.com