Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless Architectures

martinfowler.com

Post reply on HN
Print view View original

171–180 of 215 posts

Re: Serverless Architectures

#171

Post by aleem »

mpdehaan2 wrote: post #71

One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple users, working on multiple code branches, and all needing environments that somewhat closely mirror production. This leaves servless as a decent way to hook an event callback to some AWS event (new file uploaded to S3, etc) but IMHO not anything that approximates…

Second that. There's ELB + EC2 which can give you auto-scale but data persistence needs to be handled separately. There's AWS ECS which is/was quite unwieldy but I am hopeful for GAE's Flexible Environments (beta) built on Docker containers, putting it midway between Docker and Lambda with some interesting features https://cloud.google.com/appengine/docs/flexible/

Re: Serverless Architectures

#172

Post by rogerhoward »

themihai wrote: post #146
beat wrote: post #143

Earlier quoted context omitted.

Since the language isn't proprietary, there's nothing keeping me from moving the functionality to a new environment but laziness. Take the business logic encapsulated in the serverless function and wrap it into a microservice, and run it anywhere. Not that hard.

That sounds easy but in reality you end-up rewriting 90% of the code. BaaS/serverless by its very nature is tightly coupled with the environment(in this case proprietary ecosystem). I think you also underestimating the effort required to migrate a "system". Migrating a service it's not the same as migrating 90 of such things. You need to make them cooperate in the new environment(authentication, communication API etc…

90% of the code is locked to the vendor?

I've been using lambda lately and perhaps 5% of the code in my Lambdas is AWS-specific; the vast majority was rapidly extracted from existing projects, wrapped in a simple Lambda interface, and done.

While I don't advocate Lambda for everything, there's almost nothing there to lock you in - its a simple function that accepts two parameters. Even coupled with API Gateway, its just moving my routes definition to a slightly different layer. I could easily port any of this work back to any common Web framework with almost zero effort. I won't, because Lambda solves actual problems for me now.

Re: Serverless Architectures

#173

Post by Cub3 »

themihai wrote: post #128
hopfog wrote: post #126

I'm using the following setup for one of my sites: Client -> post -> API Gateway -> AWS Lambda -> upload JSON to S3 Client -> get -> S3 Works pretty good!

Is it cost effective? I mean roughly.

Very very cheap, as long as you're writing your lambdas as performant as possible we've costed our app at ~2c / user / month with heavy api / database / lambda usage

Re: Serverless Architectures

#174

Post by jwatte »

Sanddancer wrote: post #135

One of the big issues here that is only very very slightly glossed over is the security you give up. The only sort of security filtering you get is AWS' WAF, which is considerably weaker than a firewall like mod_security with a default ruleset, or even apache's .htaccess. Inbound filtering, you're limited to a tiny ruleset with only a few conditions, and outbound filtering doesn't exist at all. This lack of firewalli…

The sales pitch is that the fabric vendor does the administration, and people like you are out of a job.

Because the framework infrastructure is supposed to solve all of that behind the curtains, so developers cannot shoot themselves in the foot. (Other than through excessive resource consumption)

Re: Serverless Architectures

#175

Post by jwatte »

Sanddancer wrote: post #135

One of the big issues here that is only very very slightly glossed over is the security you give up. The only sort of security filtering you get is AWS' WAF, which is considerably weaker than a firewall like mod_security with a default ruleset, or even apache's .htaccess. Inbound filtering, you're limited to a tiny ruleset with only a few conditions, and outbound filtering doesn't exist at all. This lack of firewalli…

The sales pitch is that the fabric vendor does the administration, and people like you are out of a job.

Because the framework infrastructure is supposed to solve all of that behind the curtains, so developers cannot shoot themselves in the foot. (Other than through excessive resource consumption)

Re: Serverless Architectures

#176

Post by jwatte »

gshx wrote: post #90

One big challenge is the expense that is otherwise avoided via usage of connection pooling. Without the hack to keep the backing containers alive, tearing down and restarting them is expensive and wipes out all hot path optimizations made by JIT compilers besides having to reestablish connections and pay the handshake prices. Apart from the simplest of use-cases at this time, imho this is not an efficient model if su…

If you have any kind of real load, there skills always be instances running. If you have less load than that, you are not a case worth optimizing for, because you pay less than a few hundred per month.

Also, small instances are cheap to keep around, and as you pay per request, it's in the providers best interest to make that efficient.

Well, that's the sales pitch, anyway...

Re: Serverless Architectures

#177

Post by nickpsecurity »

Spooky23 wrote: post #164
nickpsecurity wrote: post #9

Earlier quoted context omitted.

You may be misunderstanding the concept of Lockin. It says you are stuck with whichever vendor you used that created the lockin. Benefits of services always seem to increase. So, whatever benefits exist for a current service isn't worth forgoing all potential benefits of all future competitors. That's what lock-in creates. That's why it's always bad for anything meant long-term. Now, short-term projects that can disa…

Lock-in is fine if it has value.

People keep saying that without a context. Non-lock-in usually has value too. Many times for similar or lower cost. And with way less risk.

So, the question instead is "With these requirements, which products and services meet them with good, cost-benefit analysis? And which is best when benefits and liabilities are considered?"

Re: Serverless Architectures

#179

Post by nickpsecurity »

rogerhoward wrote: post #172
themihai wrote: post #146

Earlier quoted context omitted.

That sounds easy but in reality you end-up rewriting 90% of the code. BaaS/serverless by its very nature is tightly coupled with the environment(in this case proprietary ecosystem). I think you also underestimating the effort required to migrate a "system". Migrating a service it's not the same as migrating 90 of such things. You need to make them cooperate in the new environment(authentication, communication API etc…

90% of the code is locked to the vendor? I've been using lambda lately and perhaps 5% of the code in my Lambdas is AWS-specific; the vast majority was rapidly extracted from existing projects, wrapped in a simple Lambda interface, and done. While I don't advocate Lambda for everything, there's almost nothing there to lock you in - its a simple function that accepts two parameters. Even coupled with API Gateway, its j…

There's a great assessment. Lock-in risk would be negligible in that case.

Re: Serverless Architectures

#180

Post by zippy786 »

I truly hope that people stop misleading the mass with buzz words. We already have too many of them being used for clickbait. I don't get why a simple client-server architecture would not suffice the "serverless". Software engineering and architecture design used to be cool in the past with useful design patterns. Now it's full of tricks/buzz words that promise the users of silver bullets that help them to manage code and servers. In reality, no such silver bullet exist and such tricks/architecture fail every day. I've noticed that martinfowler.com is one such place that seems to provide such empty promise of a silver bullet!
Post reply on HN