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

21–30 of 215 posts

Re: Serverless Architectures

#21

Post by themihai »

davidw wrote: post #13
themihai wrote: post #2

The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.

Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.

I don't follow. You can write other modules in different languages. The data sources are language agnostic. Nobody forces you to do use a specific programming language in the first place unless the platform is close sourced. The point is that with a close source BaaS you have no control on the tools or costs or availability(i.e. deprecation policy) of the service.

Re: Serverless Architectures

#22

Post by scrollaway »

themihai wrote: post #2

The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.

I like to think that vendor lockin is something I care greatly about, for the correct reasons. In the case of AWS Lambda however, it doesn't apply.

Serverless architecture isn't a "lockin" problem. You don't develop your app with serverless in mind, thinking that you might some day go back to serverful. Serverless is a core design of (some parts of) your app.

When I hear people say they're trying to "be generic", "abstract away serverless architecture" or some such, I'm replacing "serverless" with "asynchronous", or "functional", and it sounds bloody ridiculous, because it is.

If competitors to AWS lambda arise, I do hope they'll have a similar architecture available because that's where the power of Lambda resides. The "lock in" is only whatever those fake WSGI objects lambda is passing to the function are, as well as internal triggers for the servers (SNS, S3, ...). Those things can be abstracted away if competitors offer similar mechanism.

Trying to abstract serverless+serverful together is ridiculous. If you're successfully doing this, it sounds like your app doesn't belong in a serverless environment in the first place.

PS: There's plenty of drawbacks which are vendor-specific, not tied to the serverless design itself. For example, the Amazon API Gateway is atrociously bad. AWS Lambda doesn't even support Python 3, only Python 2.7 (get your shit together Amazon). Those are things I'd switch to a different vendor for in a heartbeat... if there was actual competition.

Re: Serverless Architectures

#25

Post by eloycoto »

I'm early adopter of serverless applications, few weeks ago was released a tool that make manage our Amazon lambda applications even easy.

https://github.com/jorgebastida/gordon

A few examples can be found here, and it's a good point to start if you're using Aws Lambda

https://github.com/jorgebastida/gordon/tree/master/examples

Re: Serverless Architectures

#26

Post by davidw »

safeignorance wrote: post #17
davidw wrote: post #13

Earlier quoted context omitted.

Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.

In almost all cases, there's a significant difference in the sort of risk that comes from B/FaaS dependencies and the sort of risk that comes from PL lock-in. The former leads to technology lock-in and vendor lock-in , while the latter almost never[1] leads to vendor lock-in. Technology lock-in without vendor lock-in isn't that huge of a liability. A popular PL under an appropriate license isn't going to disappear to…

I agree - "vendor lock-in" seems like a valid point, although I don't know the details of many of these services. "Locked into a programming language" is something that will probably happen kind of naturally anyway.

Re: Serverless Architectures

#27

Post by nawitus »

davidw wrote: post #13
themihai wrote: post #2

The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.

Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.

Locked in maybe, but not vendor locked in if the language is open source.

Re: Serverless Architectures

#29

Post by nawitus »

spriggan3 wrote: post #11
rainhacker wrote: post #8

If successful this could lead reduction in developers needed in companies that use say AWS lambda.

> If successful this could lead reduction in developers needed in companies that use say AWS lambda. How so ? to me it makes development even more complicated, cheaper relative to hosting fees maybe, but simpler ? I don't think so. What if I want to use language XYZ not supported by lambda ?

> cheaper relative to hosting fees maybe

Currently serverless is more expensive in the average case from what I gather, mainly since it's new and there's little competition.

Re: Serverless Architectures

#30

Post by themihai »

skewart wrote: post #7

I'm cautiously optimistic that the vendor lock-in will fade away over time. Hopefully open source frameworks can provide a jQuery-like abstraction layer over all of the vendor-specific implementation details. Of course, there are lots of challenges when you start getting into deeper architectures - queues triggering layers of lambdas interacting with various caches and data stores. But I we'll see best practices emer…

I actually think the opposite. Serverless architectures are the future for most of the app servers that need a language agnostic API. Maybe I didn't get it right but to me BaaS is just a PaaS with a common API interface(i.e. authentication, input/output serialization, cache etc).
Post reply on HN