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

141–150 of 215 posts

Re: Serverless Architectures

#141

Post by eldavido »

Aren't we kind of already there (serverless)?

A lot of web frameworks enforce the shared-not-that-much (not quire "shared nothing", but close) style of programming where every HTTP request is essentially just an "event" that hooks into a controller-handler? And if you want anything to stick around from one request to the next, you keep it in memcache/db/BaaS/third-party service, not your own process?

I don't think this is as radical a shift as many here might think, especially given the move to containers is already well underway.

Re: Serverless Architectures

#142

Post by snikch »

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…

This may definitely be a concern for some organizations, but I think there's a lot of focus on serverless being all about apis and web requests. Serverless is also a great way to manage stream processing, and job queues - where these issues are less relevant.

Re: Serverless Architectures

#143

Post by beat »

themihai wrote: post #138
beat wrote: post #122

Earlier quoted context omitted.

But it's not on a proprietary Amazon language! The three most common/dominant languages in the back end app development world are already covered. Why are you inventing a problem that doesn't even exist to complain about? For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use…

I didn't say there is a proprietary language. I just said that the current trend leeds to total lock-in. After BaaS,the programming language is the only open piece of your stack. I hope you can see the difference between licese per core and cloud services. The cloud vendor can render your code/business useless at any time. You control nothing on your stack. Some are comfortable with that but I don't think it's a good…

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.

Re: Serverless Architectures

#146

Post by themihai »

beat wrote: post #143
themihai wrote: post #138

Earlier quoted context omitted.

I didn't say there is a proprietary language. I just said that the current trend leeds to total lock-in. After BaaS,the programming language is the only open piece of your stack. I hope you can see the difference between licese per core and cloud services. The cloud vendor can render your code/business useless at any time. You control nothing on your stack. Some are comfortable with that but I don't think it's a good…

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) not only to perform their task(i.e. crunch some data or update an entity). The only signifiant thing that you have from the previous system is perhaps the specification(hopefully you have a such thing).It has nothing to do with laziness. It's just a waste of time and energy. You could use that time to improve the current system not to migrate it to a different platform. You end-up with a rewrite. You will see it when it hits you. I've been all for managed services but lately I've started to change my opinion.

Re: Serverless Architectures

#147

Post by wcummings »

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…

First we need a common standard for the serverless pieces of code to talk to the app server and gateway... maybe we could call it a common gateway interface. Then maybe someone will write an apache module for it.

Re: Serverless Architectures

#148

Post by beat »

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…

I've done far more exotic ports than that - wholesale platform rearchitectures (mainframe batch jobs to J2EE SOA, anyone?). I've dealt with obsolescence in some seriously painful ways. Nah, moving a bunch of serverless business logic in Python or JavaScript to a Flask or Node.js host? That's trivial. Authentication? APIs? Write a shim!

If infrastructure is really 90% of your code work and you can't salvage business logic in a platform change that doesn't require a new language, the problem isn't the serverless architecture.

Re: Serverless Architectures

#149

Post by dingaling »

themihai wrote: post #67
bronson wrote: post #59

Earlier quoted context omitted.

So my car is engineless if I never look under the hood?

Maybe worry free if you don't need to look under the hood. If the manufacturer would lock the hood you would never know :)

They actually did lock the hood with the Audi A1. Just had a flap through which you could top-up water and oil.

Perhaps we could adopt 'A1' instead of the confusing term 'serverless'...

Re: Serverless Architectures

#150

Post by bradscarleton »

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…

I think you're right that one of the big downsides currently for AWS lambda would be dev tooling, however one of the big upsides is that the code you throw up there should run "forever". This is potentially really useful if you are simply working on frontend code, and hitting these Lambda endpoints as a client.

I've set them up a few times for contact forms and other light pieces of functionality for static websites, and it fits that niche really well. Obviously, I think the serverless movement has some grander notions of the size and scale of applications that could be constructed, so we'll see.

Post reply on HN