Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloud Programming Simplified: A Berkeley View on Serverless Computing

rise.cs.berkeley.edu

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#21

Post by choppaface »

wmf wrote: post #11
choppaface wrote: post #10

I'm surprised a Berkeley survey would neglect to mention PiCloud, which may be defunct but cloudpickle is still used heavily today (e.g. in Spark). The paper also appears to neglect the issue of code deployment, which can be a major undertaking and hidden cost of any web-based application, especially if the app has particular system dependencies. There are (private) solutions out there for moving parts of running JVM…

moving parts of running programs across machines Why is this desirable and what is the magnitude of the benefit?

One application is fault tolerance. If you need to take a machine down, you can move the node (JVM program) to some other machine. So similar to pausing a long-running Lambda function, moving it elsewhere, and resuming it.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#22

Post by tsimionescu »

meekins wrote: post #17
agentultra wrote: post #5

It’s also great for vendor lock in and rent extraction. At least in its current iterations. I’m fairly certain Amazon isn’t going to make it easy to run your “serverless” applications on anything but their infrastructure. What would be more interesting would be languages and runtimes that run on the next network that is distributed, peer-to-peer, and able to be trusted. And easier to program for than they are today i…

The interface between Lambda and your business logic is usually very thin so in case of simple REST APIs migrating from platform (as long as the target platform has a compatible language runtime) to another or to be executed in a web app framework is rather easy. Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...

The problem is also that Lambda works really poorly with anything that is NOT Cognito and DynamoDB. For example, we were using some CouchBase we deployed ourselves - however, that meant that the Lambda now had a network interface in a private subnet, and start times skyrocketed, especially for concurrent access. When we also started doing our own authentication with yet another Lambda, request times for cold lambdas (which also means every new concurrent connection, remember) almost doubled.

There's also the fact that most of the code isn't really gone, it's just transformed from web server logic to lambda deployment/configuration logic.

The biggest win all told seems to be security - at least with Lambda you don't need to worry about staying on top of OS updates and the likes. I'm not at all convinced that we gained much of anything else.

Oh, and one thing that's rarely discussed is how much development&qa costs skyrocket when you have a larger team developing a fully serverless application, each with their own setup and running a few performance tests every few months...

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#23

Post by TomMarius »

rlyshw wrote: post #9

>[serverless computing] closely parallels past advances in programmer productivity, such as the transition from assembly language to high-level programming languages Is this serious? The author seems to imply that we can just abstract away the entire internet in the same way we abstracted away copper wires.

But we did, didn't we? How is modern serverless different from shared LAMP hostings of the past?

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#24

Post by seedie »

crazyforbytes wrote: post #2

Does anyone else not feel so good about a future of computing where everything but the application layer is rented from Jeff Bezos?

Developers are now in the same position system administrators were a decade ago when all of the infrastructure was moved to the cloud.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#25

Post by biztos »

tonyarkles wrote: post #12
xrd wrote: post #7

Earlier quoted context omitted.

But, the thing is so much code is removed in serverless. I'm not saying cloud providers aren't fighting to lock you in. It is just so much easier to switch if you have 1% of the code you used to.

I’m asking this from a place of genuine curiosity. Since the whole serverless thing has been gaining momentum, I’ve been mostly working on embedded stuff and haven’t been back to see what the new hotness is over in web land. What code gets eliminated in serverless? I have historically done most of my http backends using things like Flask or Sinatra or Elixir or Go (with net/http), and I’ve never felt like there’s a w…

I've only done a little bit of this stuff, but so far my impression is your code will get more complicated in AWS if you glue in Flask/Sinatra/etc. for the API Gateway, but can still get a lot less complicated if you "think serverless" and run fairly tight functions in AWS Lambda. The system then takes care of auth, request parsing, response formatting, and most of the other stuff you'd do in Flask, plus of course it eliminates the actual web-server layer.

The downside is that you then need to call them via Lambda instead of using some kind of REST API -- however at least in my case, this turns out to be the much lesser evil as I'm only using them internally, and have my own code that makes the calls. My "lock in" is that I would have to change that code, but it's trivial.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#26

Post by moduspol »

meekins wrote: post #17
agentultra wrote: post #5

It’s also great for vendor lock in and rent extraction. At least in its current iterations. I’m fairly certain Amazon isn’t going to make it easy to run your “serverless” applications on anything but their infrastructure. What would be more interesting would be languages and runtimes that run on the next network that is distributed, peer-to-peer, and able to be trusted. And easier to program for than they are today i…

The interface between Lambda and your business logic is usually very thin so in case of simple REST APIs migrating from platform (as long as the target platform has a compatible language runtime) to another or to be executed in a web app framework is rather easy. Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...

> Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...

I feel like even this lock-in is overstated. Those other services are billed based on usage and are completely separate from each other. Your migration path away would be one service at a time.

That's in no way comparable to traditional lock-in, which is like a decades-old Oracle database with high licensing fees paid annually and depended upon by dozens of complex business processes interacting directly and indirectly with each other. You don't really have a migration path in that case because there's not enough time / resources to decouple everything and migrate to something else, so you're stuck.

And that doesn't touch on the reality that if you're not relying on AWS for Lambda, DynamoDB, Kinesis, etc., then you're maintaining something yourself, which itself is not free from lock-in. Building a system that heavily utilizes Cassandra or Kafka may not have an annual licensing cost, but absolutely imposes a cost in terms of maintenance, team expertise, and (of course) makes moving away from them look not much different than moving from DynamoDB or Kinesis.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#27

Post by moduspol »

crazyforbytes wrote: post #2

Does anyone else not feel so good about a future of computing where everything but the application layer is rented from Jeff Bezos?

It doesn't have to be Jeff Bezos. It could be anyone--like your IT team in your own company. Kubernetes already supports multiple serverless variants.

The significance is where the line of abstraction is drawn, as has been the case every time programming moves up an abstraction layer.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#28

Post by scarface74 »

agentultra wrote: post #5

It’s also great for vendor lock in and rent extraction. At least in its current iterations. I’m fairly certain Amazon isn’t going to make it easy to run your “serverless” applications on anything but their infrastructure. What would be more interesting would be languages and runtimes that run on the next network that is distributed, peer-to-peer, and able to be trusted. And easier to program for than they are today i…

https://github.com/awslabs/aws-serverless-express

With no code changes, you can deploy a standard Node/Express app as either a lambda service or a standard Express app.

There are a frameworks like this from AWS for all supported languages. It’s well documented how to use the API Gateway lambda proxy feature.

For non API lambdas. The only thing you have to do is add an entry point method that takes has two arguments - a JSON event object and a lambda context.

I have another app that can be deployed as a Windows .Net Core service or lambda based on the CI/CD pipeline.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#29

Post by scarface74 »

meekins wrote: post #17
agentultra wrote: post #5

It’s also great for vendor lock in and rent extraction. At least in its current iterations. I’m fairly certain Amazon isn’t going to make it easy to run your “serverless” applications on anything but their infrastructure. What would be more interesting would be languages and runtimes that run on the next network that is distributed, peer-to-peer, and able to be trusted. And easier to program for than they are today i…

The interface between Lambda and your business logic is usually very thin so in case of simple REST APIs migrating from platform (as long as the target platform has a compatible language runtime) to another or to be executed in a web app framework is rather easy. Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...

Cognito is just a standard authorization service that supports Oath 2.0, SAML 2.0, and OpenID Connect.

It is a drop in replacement for dozens of other authentication providers.

Re: Cloud Programming Simplified: A Berkeley View on Serverless Computing

#30

Post by scarface74 »

tsimionescu wrote: post #22
meekins wrote: post #17

Earlier quoted context omitted.

The interface between Lambda and your business logic is usually very thin so in case of simple REST APIs migrating from platform (as long as the target platform has a compatible language runtime) to another or to be executed in a web app framework is rather easy. Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...

The problem is also that Lambda works really poorly with anything that is NOT Cognito and DynamoDB. For example, we were using some CouchBase we deployed ourselves - however, that meant that the Lambda now had a network interface in a private subnet, and start times skyrocketed, especially for concurrent access. When we also started doing our own authentication with yet another Lambda, request times for cold lambdas…

We use lambdas all of the time with ElasticSearch, Aurora (Mysql), etc.
Post reply on HN