6 ms·

Cloud Programming Simplified: A Berkeley View on Serverless Computing

166 points by adjohn 8y ago

crazyforbytes 8y ago
Does anyone else not feel so good about a future of computing where everything but the application layer is rented from Jeff Bezos?
- dman 8y ago
  I agree with you on this, it is a moral dilemna I think about every day. Programming was one of the few professions where the practitioner owned/had access to their tools in their own spare time. Across history and professions this is a rare property, and I fear that we might lose this in the next 10-20 years. Disclaimer: Views expressed are my own and do not reflect any positions held by my employer.
  - scarface74 8y ago
    What I have access to with AWS just using their always free tier and their cheap offerings is more than I ever could have dreamed of 5 years ago, let alone as a hobbyist in my bedroom doing 65C02 assembly in the 80s.
- a_imho 8y ago
  Cloud native has been the buzzword for a long time now, I don't see much difference with serverless in that regard.
- seedie 8y ago
  Developers are now in the same position system administrators were a decade ago when all of the infrastructure was moved to the cloud.
- moduspol 8y ago
  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.
- Cthulhu_ 8y ago
  I feel fine; one of the main selling points of cloud computing (as will be imprinted on you if you ever do an AWS course, sigh) is that before, if you wanted to launch a product, you had to invest in a huge amount of hardware first - just look at the first few years of Twitter where they were struggling to scale up. I mean yeah you could (and can) get managed hosting, rent some servers still at a lot of providers, often for cheaper than at Amazon, but scaling those out is not easy at all. Nowadays? If Twitter launched today they would have had no trouble scaling up from one user to a hundred million within weeks. AWS is a major (MAJOR) factor in the startup boom, and allows for crazy levels of scaling for new startups that attract a lot of users. If you set up your stuff right before launch, getting slashdotted (or the HN variant) is a thing of the past. The only limit to scaling now is your credit limit.
jacques_chester 8y ago
For the paper being introduced, the direct link is: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-... I agree with a lot though I think they overegg the possibilities for data performance at the as-a-Function level. Some more specific reactions: > Put precisely, there are three critical distinctions between serverless and serverful computing ... 3. Paying in proportion to resources used instead of for resources allocated. I've taken to calling this "buying capacity vs buying consumption". You need to think about which you need (they touch on this in the fallacies section). An ambulance is idle almost constantly. When I was a kid they were built on F150s and vapourised ten litres every time you glanced at them. But when I need one I don't care about the idleness and resource costs, I want to come to my aid ASAP. What I don't want is the paramedics converging from random locations on electric scooters rented on-the-fly. > In acritical departure, [AWS Lambda] charged the customer for the time their code was actually executing, not for the resources reserved to execute their program. This distinction ensured the cloud provider had “skin in the game” on autoscaling, and consequently provided incentives to ensure efficient resource allocation. I'd say yes and no. Yes, it provides an incentive to the platform provider. But there is a much, much bigger incentive to achieve platform lockin through data services. Keeping the function alive after the first invocation is a subsidy. I would bet folding money that Amazon are tracking this cost and weighing it against their market strategy. > By allowing users to bring their own libraries, serverless computing can support a much broader range of applications thanPaaS services which are tied closely to particular use cases. I'm not sure if the authors are familiar with buildpacks, despite citing Heroku. They don't mention buildpacks anywhere. Disclosure: I work for Pivotal, we do a bunch of stuff in this area, including Buildpacks and Knative. But nothing is forward looking, personal opinion, consult your dr etc etc
coderintherye 8y ago
>We expect serverless computing to become simpler to program securely than serverful computing, benefiting from the high level of programming abstraction and the fine-grained isolation of cloud functions In my view, that's the really key bit. Securing systems is an endless task, even (or especially) if they are cloud hosted.
- redisman 8y ago
  Right now serverless is definitely not simpler than a monolith. It's "simple" if you squint but any real workloads have you dealing with high concurrency for almost all tasks that a single monolith could handle with a single instance.
  - Cthulhu_ 8y ago
    You are right and I'm glad you're mentioning it, and the general skepticism about serverless; it's not a golden hammer, its applications are limited, and not every problem should be (can be?) solved with a serverless architecture. The same goes for microservices, which is another gold hammer that people picked up and started to apply to a lot of problems - I've seen a few projects where microservices was the initial architecture, while all of those would've been better off with a monolith for the first two years of operation (before any significant load) to figure out the actual problem to be solved.
agentultra 8y ago
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 in their current iteration. Edit: which is where I thought the BOOM group was going back in 2012 or so.
- xrd 8y ago
  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.
  - tonyarkles 8y ago
    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)?
    - meekins 8y ago
      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.
      - mozey 8y ago
        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
rlyshw 8y ago
>[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.
- TomMarius 8y ago
  But we did, didn't we? How is modern serverless different from shared LAMP hostings of the past?
  - scarface74 8y ago
    Shared lamp hosting didn’t give you the security, scalability or isolation that lambda gives you.
    - TomMarius 8y ago
      The implementation was lacking, but the concept is nearly identical.
choppaface 8y ago
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 programs across machines. Wouldn't one expect a forward-looking view of Serverless to encompass serialization and transport of the compute environment?
- wmf 8y ago
  moving parts of running programs across machines Why is this desirable and what is the magnitude of the benefit?
  - choppaface 8y ago
    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.
suyash 8y ago
The paper is a good read for those fairly new to Cloud Computing, even though it was published about 10 years ago!
- justincormack 8y ago
  This is not that paper it is a new one on serverless.
joshe 8y ago
Great paper, I've only gone through about 10% of it, but it offers a lot that the vendor docs and industry talks don't. Btw, this is David Patterson one of the inventors of RISC fame. Great podcast with him here (mostly about new Tensorflow chip and history): https://softwareengineeringdaily.com/2018/11/07/computer-architecture-with-dave-patterson/ https://softwareengineeringdaily.com/2018/11/07/computer-arc... Worth noting that he's at Google, but it looks like he had AWS reviewers.

166 points by adjohn 8y ago

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

dman 8y ago
I agree with you on this, it is a moral dilemna I think about every day. Programming was one of the few professions where the practitioner owned/had access to their tools in their own spare time. Across history and professions this is a rare property, and I fear that we might lose this in the next 10-20 years. Disclaimer: Views expressed are my own and do not reflect any positions held by my employer.
- scarface74 8y ago
  What I have access to with AWS just using their always free tier and their cheap offerings is more than I ever could have dreamed of 5 years ago, let alone as a hobbyist in my bedroom doing 65C02 assembly in the 80s.
a_imho 8y ago
Cloud native has been the buzzword for a long time now, I don't see much difference with serverless in that regard.
seedie 8y ago
Developers are now in the same position system administrators were a decade ago when all of the infrastructure was moved to the cloud.
moduspol 8y ago
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.
Cthulhu_ 8y ago
I feel fine; one of the main selling points of cloud computing (as will be imprinted on you if you ever do an AWS course, sigh) is that before, if you wanted to launch a product, you had to invest in a huge amount of hardware first - just look at the first few years of Twitter where they were struggling to scale up. I mean yeah you could (and can) get managed hosting, rent some servers still at a lot of providers, often for cheaper than at Amazon, but scaling those out is not easy at all. Nowadays? If Twitter launched today they would have had no trouble scaling up from one user to a hundred million within weeks. AWS is a major (MAJOR) factor in the startup boom, and allows for crazy levels of scaling for new startups that attract a lot of users. If you set up your stuff right before launch, getting slashdotted (or the HN variant) is a thing of the past. The only limit to scaling now is your credit limit.

jacques_chester 8y ago

For the paper being introduced, the direct link is: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-... I agree with a lot though I think they overegg the possibilities for data performance at the as-a-Function level. Some more specific reactions: > Put precisely, there are three critical distinctions between serverless and serverful computing ... 3. Paying in proportion to resources used instead of for resources allocated. I've taken to calling this "buying capacity vs buying consumption". You need to think about which you need (they touch on this in the fallacies section). An ambulance is idle almost constantly. When I was a kid they were built on F150s and vapourised ten litres every time you glanced at them. But when I need one I don't care about the idleness and resource costs, I want to come to my aid ASAP. What I don't want is the paramedics converging from random locations on electric scooters rented on-the-fly. > In acritical departure, [AWS Lambda] charged the customer for the time their code was actually executing, not for the resources reserved to execute their program. This distinction ensured the cloud provider had “skin in the game” on autoscaling, and consequently provided incentives to ensure efficient resource allocation. I'd say yes and no. Yes, it provides an incentive to the platform provider. But there is a much, much bigger incentive to achieve platform lockin through data services. Keeping the function alive after the first invocation is a subsidy. I would bet folding money that Amazon are tracking this cost and weighing it against their market strategy. > By allowing users to bring their own libraries, serverless computing can support a much broader range of applications thanPaaS services which are tied closely to particular use cases. I'm not sure if the authors are familiar with buildpacks, despite citing Heroku. They don't mention buildpacks anywhere. Disclosure: I work for Pivotal, we do a bunch of stuff in this area, including Buildpacks and Knative. But nothing is forward looking, personal opinion, consult your dr etc etc

coderintherye 8y ago

>We expect serverless computing to become simpler to program securely than serverful computing, benefiting from the high level of programming abstraction and the fine-grained isolation of cloud functions In my view, that's the really key bit. Securing systems is an endless task, even (or especially) if they are cloud hosted.

redisman 8y ago
Right now serverless is definitely not simpler than a monolith. It's "simple" if you squint but any real workloads have you dealing with high concurrency for almost all tasks that a single monolith could handle with a single instance.
- Cthulhu_ 8y ago
  You are right and I'm glad you're mentioning it, and the general skepticism about serverless; it's not a golden hammer, its applications are limited, and not every problem should be (can be?) solved with a serverless architecture. The same goes for microservices, which is another gold hammer that people picked up and started to apply to a lot of problems - I've seen a few projects where microservices was the initial architecture, while all of those would've been better off with a monolith for the first two years of operation (before any significant load) to figure out the actual problem to be solved.

agentultra 8y ago

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 in their current iteration. Edit: which is where I thought the BOOM group was going back in 2012 or so.

xrd 8y ago
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.
- tonyarkles 8y ago
  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)?
  - meekins 8y ago
    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.
    - mozey 8y ago
      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

rlyshw 8y ago

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

TomMarius 8y ago
But we did, didn't we? How is modern serverless different from shared LAMP hostings of the past?
- scarface74 8y ago
  Shared lamp hosting didn’t give you the security, scalability or isolation that lambda gives you.
  - TomMarius 8y ago
    The implementation was lacking, but the concept is nearly identical.

choppaface 8y ago

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 programs across machines. Wouldn't one expect a forward-looking view of Serverless to encompass serialization and transport of the compute environment?

wmf 8y ago
moving parts of running programs across machines Why is this desirable and what is the magnitude of the benefit?
- choppaface 8y ago
  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.

suyash 8y ago

The paper is a good read for those fairly new to Cloud Computing, even though it was published about 10 years ago!

justincormack 8y ago
This is not that paper it is a new one on serverless.

joshe 8y ago

Great paper, I've only gone through about 10% of it, but it offers a lot that the vendor docs and industry talks don't. Btw, this is David Patterson one of the inventors of RISC fame. Great podcast with him here (mostly about new Tensorflow chip and history): https://softwareengineeringdaily.com/2018/11/07/computer-architecture-with-dave-patterson/ https://softwareengineeringdaily.com/2018/11/07/computer-arc... Worth noting that he's at Google, but it looks like he had AWS reviewers.