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

151–160 of 215 posts

Re: Serverless Architectures

#151

Post by themihai »

beat wrote: post #148
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…

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 l…

It depends how tightly coupled is your code to the platform. You can't get more coupled than BaaS and thus the reason why I think proprietary BaaS is such a bad thing.

Re: Serverless Architectures

#152

Post by rapind »

wcummings wrote: post #147
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.

I laughed at the CGI reference, but TBH pub/sub + microservices feels really awesome and clean so far. Combined with DB as a service it's even better IMO.

Re: Serverless Architectures

#153

Post by [deleted] »

wcummings wrote: post #147
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.

[deleted]

Re: Serverless Architectures

#154

Post by [deleted] »

wcummings wrote: post #147
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.

[deleted]

Re: Serverless Architectures

#156

Post by BraveNewCurency »

themihai wrote: post #79
toddmorey wrote: post #68

Earlier quoted context omitted.

I completely disagree that it's DOA. In fact, I think it's clear that is the future of development. Like any piece of the software stack, there are providers focusing on services that are proprietary, open source, and a mixture of the two. I am personally most excited about the hosted open source providers, because it gives dev teams immediate access to the technology, but the option to bring it in house when and how…

I didn't say the technology is DOA. Just the current offers which seem locked in to specific vendor implementations. The current BaaS offers are too intrusive and just not good enough to worth the switch from a PaaS to a BaaS.

> good enough

To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things:

- Use a random site who may or may not radically change their business model in the new few years. - Pay $5/month for a VPS, then get forcibly dragged up the learning curve of becoming a full-time sysadmin - Pay pennies for Lambda

Is there a reason to re-write your backend? No. Is there a reason to consider it on your next project? Possibly.

Re: Serverless Architectures

#157

Post by dragonwriter »

BraveNewCurency wrote: post #156
themihai wrote: post #79

Earlier quoted context omitted.

I didn't say the technology is DOA. Just the current offers which seem locked in to specific vendor implementations. The current BaaS offers are too intrusive and just not good enough to worth the switch from a PaaS to a BaaS.

> good enough To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things: - Use a random site who may or may not radically change their business model in the new few years. - Pay $5/month for a VPS, then get forcibly dragged up the learning curve of becoming a full-time sysadmin - Pay pennies for Lambda Is there a reason to re-write your backend? No. Is there a reason…

> To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things:

Since any site "may or may not radially change their business model" at any time, you really only list two substantive options:

(1) Use an VPS, or (2) Use Lambda

But, really, there's a more choices:

(1) Use a VPS or IaaS (with full sysadmin overhead), (2) Use a PaaS (like Google AppEngine) and avoid sysadmin overhead (but probably have more code than a "serverless" function host like Lambda), or (3) Use a "serverless" function host like Lambda

You probably don't want to do #1, since for low-volume and trivial logic its (1) comparatively expensive, and (2) high sysadmin and programming overhead compared to the other options.

#2 is lower overhead (particular on the sysadmin side), but still more than #3. But possibly cheaper (e.g., if the requirements fit within the free quotas for AppEngine.)

#3 may be the best solution for some things, but its not as stark as a choice as you present it to be.

Re: Serverless Architectures

#158

Post by smt88 »

tomc1985 wrote: post #155

We used to have serverless architecture... it was called standalone desktop apps! No servers, no backend, no nothing, just you and the code. It was great!

It wasn't great. Updating apps was a huge pain, which meant that bugfixes were fewer and farther between. You couldn't sync preferences/settings between computers. Remember getting a new computer or wiping one? You knew you had hours of work ahead of you, just reconfiguring it. Did you write a shell script to do that for you? Too bad, it did something weird along the way, and now you have to spend hours figuring out what's wrong.

And don't even get me started on installing dependencies...

Re: Serverless Architectures

#159

Post by audleman »

SNvD7vEJ wrote: post #45

What a ridiculous and strange definition this is. Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers... Why not just call it "Multiserver" instead. If they mean "containerless servers" or "microservices", then why don't they say so? If they mean "distributed servers" why not call it that. If they mean that the client relies on multiple services (each hoste…

As a DevOps guy the definition makes sense to me. I've got several parts of my operation that require me to spin up 3 - 30 instances to handle parallel load. I'm always monitoring queues to see if I'm scaling correctly. If I went 'Serverless' Amazon would handle that whole chunk for me. That's approximately 20% of my job taken care of.

I think to an end-user the definition is meaningless, but to its intended audience it fits.

Re: Serverless Architectures

#160

Post by audleman »

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…

I've been wondering this same thing. We use gunicorn to handle our web requests and it pre-loads our code so it's ready at the drop of a hat to serve a request. It takes a few seconds to load up our site, so wouldn't Lambda have to pay that cost with every web request?

I've been going under the assumption that it's just not the right use case for Lambda, though I'm hoping I'm wrong.

Post reply on HN