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

31–40 of 149 posts

Re: Serverless Architectures

#31

Post by jrs235 »

Tomte wrote: post #24
infodroid wrote: post #6

It is misleading that the HN title suggests the author is Martin Fowler, but this is not the case for this guest article. The actual author is Mike Roberts, the article is hosted on Fowler's site.

Yes, but that's probably because the HN submission bookmarklet puts the site name behind the dash. It annoys me every time I'm submitting something. But evidently not enough to finally edit the bookmarklet.

Ditto about the annoyance. Never thought about editing the bookmarklet... I'm going to do that now!

Re: Serverless Architectures

#32

Post by SideburnsOfDoom »

Spearchucker wrote: post #3

The API gateway made me smile. In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing. There's merit in serverless, no doubt. There are many things that worry me. Not owning the infrastructure means I don't get the telemetry I'd like, making triage difficult. Direct access to the database is a good idea said nobody e…

> In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing.

On AWS, you have options a message queues (SQS), busses (SNS), API gateways, and load balancers (ELB). i.e. many of the existing proven patterns are still around, and you can choose which one is best for the particular circumstance. And that indicates that while they have similarities, they're not exactly the same thing.

I can see cases where a design of "API gateway -> lambda fn -> database" is performant, simple and very cost effective. particularly where the function is very simple and load is low or varies a lot. That won't be everything though.

I don't understand why you think that "Direct access to the database" is always bad. Someone has to access that database directly, on behalf of everyone else who is insulated from it. A lambda fn may not be worse than a web app for that role. But if it is inadvisable, then it can use the same indirect requests that a web app would.

Re: Serverless Architectures

#33

Post by atrudeau »

osipov wrote: post #26
gmazza wrote: post #14

Serverless = new name for PaaS. VPS (virtual private servers) were available (and largely ignored) for quite a while before 2006, when AWS came along with the catchy word "cloud". This single word changed everything. Same technology all of the sudden became cool, and everybody started using it. Maybe now it is the turn of PaaS [1] - call it "serverless" and folks finally start seeing all the benefits (true scalabilit…

Since serverless is a kind of a PaaS, it offers many of the same benefits. However, unlike Heroku, Cloud Foundry, OpenShift, and other traditional PaaSes focused on supporting long running applications and services, serverless frameworks offer a new kind of a platform for running short lived processes and functions, also called microflows. The distinction between the long running processes and microflows is subtle bu…

Sounds like inet.d, or CGI behind a webserver.

Re: Serverless Architectures

#34

Post by Touche »

SideburnsOfDoom wrote: post #29
Touche wrote: post #28

With this type of architecture, aren't you creating latency by separating out the "backend" from the database? In the traditional approach the backend server and database are in the same datacenter, but it seems that's often not the case in FaaS approach, what are the ramifications of that?

If you were on AWS, I would expect the Lamdba fn to be running in the same datacenter as the backing dynamodb table, or at least in the same region. dynamodb response times are pretty good - typically under 10 milliseconds.

Thanks, is this something you have to be aware of when setting this all up or does Amazon do this for you?

Re: Serverless Architectures

#35

Post by marktangotango »

jeswin wrote: post #10
marktangotango wrote: post #9

Earlier quoted context omitted.

The vast majority of web sites on the internet today don't need much infrastructure, they're low traffic blogs, web sites for the hair salon down the street, or a landing page for a non software corporation. Facebook fills this role for a lot users, and they in turn sacrifice their data and privacy to a souless corporation. Don't forget the $billions dollars industry of shared hosting providers out there. A lot of bu…

Even if it costs nothing, Facebook is a far better option for hair salons and other similar small businesses. Facebook drives engagement and views, while nobody will bother with a self hosted website. The oft repeated lesson here is that convenience trumps privacy for the vast majority of users. If you look at the last decade, in spite of there being robust, self-hosted solutions for syndication and engagement such a…

I think the secret sauce may be in things like 'call ahead seating' or 'get in line, online' that some restaurants and hair styling places do now. You don't typical get that capability on facebook, and it's a differentiator.

Re: Serverless Architectures

#36

Post by Spearchucker »

SideburnsOfDoom wrote: post #32
Spearchucker wrote: post #3

The API gateway made me smile. In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing. There's merit in serverless, no doubt. There are many things that worry me. Not owning the infrastructure means I don't get the telemetry I'd like, making triage difficult. Direct access to the database is a good idea said nobody e…

> In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing. On AWS, you have options a message queues (SQS), busses (SNS), API gateways, and load balancers (ELB). i.e. many of the existing proven patterns are still around, and you can choose which one is best for the particular circumstance. And that indicates that whi…

If you give client code access to your database you have to trust that client to respect data types, sizes and, depending on how your database is designed, referential integrity. There's risk of data loss because again, you have to trust the client. There's risk of denial of service in scenarios where the client fills up your database with junk. It's risk all the way down and using it or not is down to probability x impact.

Re: Serverless Architectures

#37

Post by gmazza »

atrudeau wrote: post #33
osipov wrote: post #26

Earlier quoted context omitted.

Since serverless is a kind of a PaaS, it offers many of the same benefits. However, unlike Heroku, Cloud Foundry, OpenShift, and other traditional PaaSes focused on supporting long running applications and services, serverless frameworks offer a new kind of a platform for running short lived processes and functions, also called microflows. The distinction between the long running processes and microflows is subtle bu…

Sounds like inet.d, or CGI behind a webserver.

...or socket-activated systemd service [1, 2]

[1] http://0pointer.de/blog/projects/socket-activated-containers...

[2] https://developer.atlassian.com/blog/2015/03/docker-systemd-...

Re: Serverless Architectures

#38

Post by mikebroberts »

gmazza wrote: post #14

Serverless = new name for PaaS. VPS (virtual private servers) were available (and largely ignored) for quite a while before 2006, when AWS came along with the catchy word "cloud". This single word changed everything. Same technology all of the sudden became cool, and everybody started using it. Maybe now it is the turn of PaaS [1] - call it "serverless" and folks finally start seeing all the benefits (true scalabilit…

The latest installment just went live - conveniently I offer a comparison to PaaS in it (in that I think there are significant differences between PaaS and FaaS)

Re: Serverless Architectures

#39

Post by mikebroberts »

jrs235 wrote: post #31
Tomte wrote: post #24

Earlier quoted context omitted.

Yes, but that's probably because the HN submission bookmarklet puts the site name behind the dash. It annoys me every time I'm submitting something. But evidently not enough to finally edit the bookmarklet.

Ditto about the annoyance. Never thought about editing the bookmarklet... I'm going to do that now!

If you are able to do that you would have my appreciation as the article author! :)

Re: Serverless Architectures

#40

Post by jlward4th »

In regards to Stateless and 12 Factor...

> This has a huge impact on application architecture, albeit not a unique one - the ‘Twelve-Factor App’ concept has precisely the same restriction.

While 12 Factor does say that processes should be stateless I've never thought it really meant it. Connection Pools and in-memory caches are pretty typical in 12 Factor (or all non-serverless) apps. And for me that is what makes serverless kinda silly. Some global state is actually pretty useful when you can avoid the overhead of initializing things or going over the network.

Post reply on HN