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

51–60 of 149 posts

Re: Serverless Architectures

#51

Post by mikebroberts »

mikegerwitz wrote: post #50

There are a number of things I find alarming about this (which is nothing new): Firstly, the author is encouraging the conversion of traditional web pages to single-page web applications, which means that users would now have to download actual software to use the website rather than using the software that they already have and trust: their web browser. Perhaps most alarming is the acknowledgement of this: > One of…

Hi Mike,

Article author here. Don't worry, I'll be laying on some cold, hard, reality later in the series. I definitely don't encourage SPAs universally and I'll be talking extensively about the concerns of handing over responsibility to vendors.

Re: Serverless Architectures

#52

Post by osipov »

falcolas wrote: post #46
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…

They are not always terminated, in an effort to avoid cold boot startup times. In fact, they run much like any other service framework, where your code is behind a function lookup, and called when an appropriate request is received. AWS Lambda in particular will spin up a new container running their framework, which will then stay alive for a period of time before being terminated. With socket activation (using xinit…

>They are not always terminated, in an effort to avoid cold boot startup times.

That's true. I should have pointed out that from the developer's point of view it appears as if the execution is terminated, in the sense that no state is carried across code executions. However, the issue of whether the code is cold booted or not is an implementation detail of a specific serverless platform.

Atlassian did a nice blog post[1] on running Docker containers using socket activation. In principle that makes for a serverless platform but for a one that's difficult to manage. [1] https://developer.atlassian.com/blog/2015/03/docker-systemd-...

Re: Serverless Architectures

#55

Post by SideburnsOfDoom »

Spearchucker wrote: post #36
SideburnsOfDoom wrote: post #32

Earlier quoted context omitted.

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

> If you give client code access to your database you have to trust that client to respect ...

I get all that but I still am unsure of what you mean. A database is useless if no-one can ever access it. So some code somewhere accesses that database, not so? And other code makes request to this code?

What do you consider "client code" and what are you comparing this to? Why do you think that lambda functions cannot be in the second category, and if they cannot be, why can't they use the same gated mechanisms as other "client code", and I would assume that they use restful http to read, and http or message queues to write?

> There's risk of denial of service

in the AWS lambda case, the rate limiting is specifically the role of the api gateway. There's always the risk, and I don't think that lambda increases it.

Re: Serverless Architectures

#56

Post by agentgt »

We sort of do this for a JVM with the exception that it is the JVM and you really can't be rebooting it all the time.

What we do is use a message queue and extreme thread isolation. Are internal framework is sort of analogous to an actor framework and/or Hystrix but is stateless through out. Messages are basically functions that need to be run.

That being said because our whole architecture is message driven and uses a queue with many client implementations we have been experimenting with OCaml Mirage and even some Rust + lightweight container because of the serious limitation of booting up the JVM.

Re: Serverless Architectures

#57

Post by SideburnsOfDoom »

Touche wrote: post #34
SideburnsOfDoom wrote: post #29

Earlier quoted context omitted.

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?

AWS is far from simple, and there is a lot to learn. For a start, you will need to know what a Region and Availability zone are: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-reg...

Roughly speaking: A region is a geographic location (e.g. eu-west-1 is in Ireland and eu-central-1 is in Frankfurt, Germany) The "Availability Zones" are separate datacenter buildings in that region connected by fat pipes.

For fault-tolerance, it is common to make sure that all of app's parts run across multiple availability zones in the region. This will happen without much manual config.

Crossing regions is very different - it's not going to happen automatically, they're pretty much isolated from each other. Only a few extremely-highly-available apps (e.g. netflix) have engineered to cross regions. See https://www.infoq.com/presentations/netflix-failure-multiple...

Re: Serverless Architectures

#58

Post by Spearchucker »

SideburnsOfDoom wrote: post #55
Spearchucker wrote: post #36

Earlier quoted context omitted.

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…

> If you give client code access to your database you have to trust that client to respect ... I get all that but I still am unsure of what you mean. A database is useless if no-one can ever access it. So some code somewhere accesses that database, not so? And other code makes request to this code? What do you consider "client code" and what are you comparing this to? Why do you think that lambda functions cannot be…

First, "client". A client is anything that calls a server but is outside the trust boundary of that server.

And yes, of course there's code that accesses the database. The problem is that if it's client code, that code must be trusted by the database.

A better approach is where there's code between the client and the database, also on the server (server estate, at least), that verifies data going into and out of the database.

That isolates client-side changes - malicious, unintentional or otherwise, that might impact the data, because there's a server-side gatekeeper.

So all of a sudden FAAS is more appealing than BAAS, and the FAAS API gateway doesn't just do routing, it does validation too. Guess what, you just created an application/business logic layer on a middle tier, and it's no longer serverless.

"...Why do you think that lambda functions cannot be in the second category..."

They can indeed be in the second category. The author, however, specifically calls out direct database access from the client without lambda functions.

Re: Serverless Architectures

#59

Post by mikegerwitz »

mikebroberts wrote: post #51
mikegerwitz wrote: post #50

There are a number of things I find alarming about this (which is nothing new): Firstly, the author is encouraging the conversion of traditional web pages to single-page web applications, which means that users would now have to download actual software to use the website rather than using the software that they already have and trust: their web browser. Perhaps most alarming is the acknowledgement of this: > One of…

Hi Mike, Article author here. Don't worry, I'll be laying on some cold, hard, reality later in the series. I definitely don't encourage SPAs universally and I'll be talking extensively about the concerns of handing over responsibility to vendors.

Thanks for the reply, Mike; I'm looking forward to reading your opinions, and I'm glad you'll be discussing it.

From a technical perspective, your article was very informative, and I did learn from it, so thank you for the information.

Re: Serverless Architectures

#60

Post by falcolas »

osipov wrote: post #52
falcolas wrote: post #46

Earlier quoted context omitted.

They are not always terminated, in an effort to avoid cold boot startup times. In fact, they run much like any other service framework, where your code is behind a function lookup, and called when an appropriate request is received. AWS Lambda in particular will spin up a new container running their framework, which will then stay alive for a period of time before being terminated. With socket activation (using xinit…

>They are not always terminated, in an effort to avoid cold boot startup times. That's true. I should have pointed out that from the developer's point of view it appears as if the execution is terminated, in the sense that no state is carried across code executions. However, the issue of whether the code is cold booted or not is an implementation detail of a specific serverless platform. Atlassian did a nice blog pos…

Any code written in a common web framework (such as Django, Rails, or Play) could easily be written with the same constraints - no state left over from request to request. That we typically choose to retain state between requests as an optimization speaks of one of the weaknesses in serverless architecture.

If you can't maintain state inside the application, you need to maintain it elsewhere (DB, Redis, memcache), and that elsewhere has a cost associated with accessing it.

Post reply on HN