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

11–20 of 43 posts

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

#11

Post by wmf »

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?

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

#12

Post by tonyarkles »

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

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 whole lot of code to begin with. What am I missing (if you don’t mind elaborating)?

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

#14

Post by meekins »

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…

API Gateway becomes your HTTP server, your routing layer defined in Flask/Sinatra/Express & co is implemented in API GW integration configuration and handling routed requests is implemented as Lambdas that process events from API GW.

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

#15

Post by mozey »

meekins wrote: post #14
tonyarkles wrote: post #12

Earlier quoted context omitted.

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…

API Gateway becomes your HTTP server, your routing layer defined in Flask/Sinatra/Express & co is implemented in API GW integration configuration and handling routed requests is implemented as Lambdas that process events from API GW.

With AWS Lambda I try to avoid using API Gateway as it seems to me that is exactly where the lock-in occurs. Instead I have one catch-all route on API GW and I keep my routing layer in the app. This also makes it easier to run the app on dev without recreating the entire AWS environment

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

#16

Post by xrd »

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'm thinking of Firebase. For example, with Firebase, my web clients (web or Android, for example) don't ever talk to my backend directly. I have a serverless firebase function that accepts a trigger when there is an update to the firestore (cloud database) or storage (like AWS S3). I get a JSON object (which is declarative) that I can use to send the file or data on to a new process. This decoupling makes my firebase function really small: it only parses JSON and sends an event, perhaps to another Google service.

Compare this to a large application where you are marshalling objects from the HTTP POST request into temp objects inside your application language. Making that work with all clients, within all server contexts, is a lot of code which I hated to write.

With serverless, I'm never connecting my clients or backends directly. I'm thinking in terms of moving high level objects (JSON, files, events) between systems, and Google provides the glue to wire those together. It takes a mind shift, but when you realize how much glue code you are writing and that you can forget, it makes your application layer really simple.

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

#17

Post by meekins »

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

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

#18

Post by meekins »

mozey wrote: post #15
meekins wrote: post #14

Earlier quoted context omitted.

API Gateway becomes your HTTP server, your routing layer defined in Flask/Sinatra/Express & co is implemented in API GW integration configuration and handling routed requests is implemented as Lambdas that process events from API GW.

With AWS Lambda I try to avoid using API Gateway as it seems to me that is exactly where the lock-in occurs. Instead I have one catch-all route on API GW and I keep my routing layer in the app. This also makes it easier to run the app on dev without recreating the entire AWS environment

You can absolutely do that. Then you just need to do more custom work to enable route level observability and metrics.

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

#20

Post by a_imho »

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?

Cloud native has been the buzzword for a long time now, I don't see much difference with serverless in that regard.
Post reply on HN