17 ms·

Serverless Computing in 2018

118 points by emforce 9y ago

iamleppert 9y ago
Wow, there's so much misinformation and outright lies in the comments here. You do not have to "notify" anyone at AWS to scale your lambda up to whatever your account invocation limits or spending limit. Also you can run whatever code you want, native libraries, etc. If you need a cache you can use the disk or connect to some in-memory data store. You can log to wheverer you like, or throw your logs away. Local development is easy and there are several frameworks that abstract away AWS' wart-like configuration API. The limitations with lambda mostly have to do with the fact you're basically doing distributed processing with finite resources, and under an ephemeral model. Many libraries aren't written in that way, so you'll need to do some first principles work here and there but I'd argue the resultant architecture, independent of AWS, is worth it. You can share databases, S3 files, whatever. Generally speaking lambda is good for workloads that aren't always at 100% (basically almost every kind of long-tail application in computing). The cost per CPU cycle is made up when you consider this, and there's nothing to stop people from setting up lamda-style processing on their own clusters, machines, or bare metal if you think you can optimize for utilization better/cheaper than lambda/AWS. If you're in the 1 or 2% of applications where your system is latency sensitive or always at 100%, you either need to consider other architectures or ways of solving your problem. If that's not possible, lambda might not be for you. If you're someone that doesn't like new technology and is resistant to change, by all means continue to spend your time provisioning and tending to your flock of instances. You're just going to pass that cost on to your customer or user anyway.
- thezilch 9y ago
  You will absolutely need to notify AWS to scale to "world changing" levels or take on "massive surges" without spewing errors. There literal limits that require filling out a web form and waiting to get your ticket administered. Then Lambda is backed by EC2, which itself has functional (Re: AWS has per-minute limits on how fast you can add concurrency) and physical (Re: AWS has finite compute and will tell you they would like advances on your "massive" compute needs -- you can't just get infinite cloud off the shelf).
macawfish 9y ago
i wanna see "serverless computing" on p2p mesh networks!
- braderhart 9y ago
  Thank you! Isn't this what serverless really is about... federated and distributed cloud platforms? Not another buzzword from whatever cloud provider, that essentially means more proprietary systems that benefit their profits and not technology as a whole.
api 9y ago
Coding everything to run on proprietary mainframes (sorry, cloud services) is going to "change the world." Sigh.
- RhodesianHunter 9y ago
  >proprietary mainframes (sorry, cloud services) It's all just Linux. Easily transferable between environments.
- dboreham 9y ago
  The software version of The Lion King’s Circle of Life..
- Agebor 9y ago
  In 5-10 years, you'll click a button to move all your functions to a decentralised computing fog.
throwaway13337 9y ago
I hear a lot of evangelism but no success stories aside from one-off use cases that almost seem designed to benefit from the autoscaling. To me, this is marketing and second-tier marketing by consultants hoping to sell you their services. Serverless makes it harder to test locally, harder to move between hosts, often times much slower (cold starts), and forces going to the network to do things like persist to disk, run queues, etc. Of course, all these services are provided by the megacorp in charge of your servers so the lock-in goes deeper. The only ones that should be considering serverless are companies that need to scale up and down operations at a moment's notice. That is if you're huge or doing a lot of short-burt big data processing. Otherwise, it's all koolaid. Enjoy the open standards we have. Let's work on improving and evangelizing those instead of megacorp lock-ins.
- emforce 9y ago
  If we look at the likes of Unity3D, nothing was perfect straight off the bat, and I feel like the same can be said of Serverless architectures. The people offering serverless are no doubt aware of the difficulties and I wouldn't be surprised if they said they were developing something that would make this easier. Cold starts are a valid issue though and I feel that the effects of this can be minimized with the use of fast compiled languages such as Go. Lock-in is also a worry for most, as we progress we need to ensure that we are able to write serverless code in such a manner that they can easily be transported across to other serverless providers.
  - jacques_chester 9y ago
    > Cold starts are a valid issue though and I feel that the effects of this can be minimized with the use of fast compiled languages such as Go. Warmed-up code will always have an edge. Even if Go code can launch very fast, the same binary retained in main memory and heavily represented in L2 and L3 caches is going to absolutely stomp the same bits being loaded from disk over and over. > Lock-in is also a worry for most, as we progress we need to ensure that we are able to write serverless code in such a manner that they can easily be transported across to other serverless providers. This will come down to folks building such platforms. I am working for Pivotal on Project Riff. Oracle released Fn, IBM and others are supporting OpenWhisk. There are really a lot of people working on it.
thezilch 9y ago
> you don’t necessarily have to worry about massive surges in traffic. The underlying system will automatically handle things such as load-balancing and the provisioning of appropriate infrastructure in order to meet any massive surges in traffic. This is wrong. Most cloud providers, AWS included, will _require_ a heads up for even small surges. There are also caps on capacity; in fact, you need to contact them to lift said caps. It's solving the market of oversaturated shared-VPS that run Node, Python, or Go? Call when you have PHP.
- risaacs99 9y ago
  This is just not true. A brand new account on AWS will come with a default lambda limit of 1000 concurrent invocations with up to 2 cores and 3gb per invocation. That is a massive amount of computing power. The load balancer (typically API gateway in front of lambda for a serverless app) will scale very quickly to any request volume and no one needs to be notified ahead of time.
  - always_good 9y ago
    AWS' Elastic Load Balancer took minutes to spin up such that it was pretty useless, god forbid you're getting DoSed. I have a hard time believing that their other products don't have the same issue when auto-scaling.
    - thezilch 9y ago
      Lambda is backed by EC2 and absolutely has EC2's limits. Just like scaling an ELB takes minutes to serve "massive surges" -- AWS recommends you pre-warm ELBs or contact them to do so -- the same is true of Lambda.
      - risaacs99 9y ago
        AWS no longer recommends warming up the newer ALBs for the vast majority of customers and scenarios. Of course lambda isn't magic and has an initial start penalty. There are ways to mitigate it and as long as you are actively handling requests your functions will be reused. It's not magic, but it's capable of keeping up with normal traffic surges. If you have a special circumstance where you expect a large surge on a scheduled basis (say thousands of clients checking in at the stroke of midnight, you would have to arrange to be ready for that and there are a lot of ways to do it). API gateway isn't alb or elb and there isn't any recommendation or expectation that customers warm anything up. I never said "massive surge" but I stand by the idea that 2000 cores and 6 terabytes of memory is massive for most workloads. Of course, that's not the limit and you can request more if you need it. Lambda isn't for all workloads but AWS (and everyone else) is always changing and improving. You have to check in occasionally to see if old assumptions (e.g. elb) still hold.
jacques_chester 9y ago
I've recently been allocated to work on a FaaS platform[0]. A few months back a colleague and researched and wrote about FaaSes more generally. I think FaaSes have value, but I am still on the fence about their changing "everything". To start with ... > When it comes to services such as AWS Lambda, when you expose an endpoint, you don’t necessarily have to worry about massive surges in traffic. You sorta still do. The latency of a cold start is still higher than a warmed-up chunk of code. Can Node start, interpret code, perform logic and respond in less than 100ms? It certainly can. Meanwhile, a warmed up JVM can perform the same logic in nanoseconds. Lambda and most other designs I've seen retain warm copies. Either loaded in advance (I saw an AWS slide deck saying that a large part of their secret sauce is load prediction) or kept around once it has launched. But you will always have a bimodal distribution, probably quite wide, because FaaSes typically scale down to zero. Hugging the curve is never free. Either you accept idle capacity (enough to cover a start of a surge while you bring additional capacity online) or you accept lumpy latency. I suspect FaaSes will shine in situations which are sensitive to billing cost but not latency. Where latency is non-negotiable, you will either see folks sticking to services or some mix of services that are augmented by functions built from the same codebase. > These Serverless cloud providers constantly monitor and manage the underlying fleet of servers running your code. PaaSes do this too. It's one of the main selling points. > Thankfully, every endpoint you set up can use a different language runtime. This isn't really true. FaaSes currently provide a closed list of supported languages. Implementations vary, even within a single platform. What's missing here is an open extension point. I have internally argued, and I will be continuing to argue, that we already have one: buildpacks. The concept is well-understood, the tooling and testing is well in hand and we have a great deal of expertise in this area. In particular, it means we don't need to reinvent a wheel. Identifying that code is meant to be mounted in a FaaSes is no different in kind from detecting that it is intended to be run as a Rails app or a vanilla Rack app. What's missing from the discussion is what is missing from FaaSes: tools for composing larger systems. Most efforts (eg. IBM's composer[1] tool or Lambda's step functions) look at creating state machines wrapped around functions. I think this is the wrong approach. Composition should be declarative, mediated through state, with no logic outside of the functions. My model here is how Concourse defines tasks. I've been making this argument too and I hope we'll bring to FaaS users the kind of lego-brick composability that Concourse users enjoy. [0] https://pivotal.io/platform/pivotal-function-service https://pivotal.io/platform/pivotal-function-service, based on https://projectriff.io/ https://projectriff.io/ [1] https://github.com/ibm-functions/composer https://github.com/ibm-functions/composer
hobaak 9y ago
sorry, not much substance to the content.
- tzahola 9y ago
  >How Serverless Computing Will Change the World in 2018 You shouldn’t have expected much in the first place.
jknoepfler 9y ago
I'm personally betting against serverless computing in the enterprise, except for very specific uses. In general, serverless computing tasks cost 100-1000× more per cpu cycle than a counterpart running on a cloud server. That means that for tasks that are running regularly, they are a huge loser. They have unpredictable latency, you lose control of things like logging to disk (you get locked in to cloudwatch or whatever, yet more money and tooling required) The notion of scale seems promising at first, but I would be very skeptical before I accepted the claim that someone can scale lambda volume from 10 to 10 thousand executions per minute without setting off alarms, dropping traffic, and probably having an engineer at AWS Lamba get paged. So what are lambdas good for? I'd argue that they make good glue for deployments or batch processes that happen infrequently, don't require predictable performance, and for which having a dedicated server is a little wasteful. I'm skeptical even of those. Remember, a micro server is free tier. I have had success building prototypes with AWS Lambda, so there's that aspect too. I'd be interested to hear a counterpoint from someone who uses serverless compute in a large enterprise setting in place of a traditional server stack.
- shams93 9y ago
  Yeah say you do most of your processing in the client but need to sync local storage to a server for persistence and then may need to re-hydrate that state later, those can be run in the background with a service worker where the slowness doesn't affect the other parts of the application.
- ryanmarsh 9y ago
  I do technical agile coaching and I’m telling you not only will Serverless be successful in the enterprise it’s going to take over. 1. Enterprise systems are always Rube Goldberg machines. Serverless is perfect for this. Check out the 12 Serverless architectures talk at reinvent. 2. Most enteprise IT shops completely missed containerization. Many are still struggling to adopt the public cloud. The feet dragging and lip service by IT Infra and Security regarding public cloud is real. 3. It’s easier to give someone permission to use lambda than EC2. Thus teams follow the path of least resistance. Infra really fucked up in a lot of shops by allowing lambda but feet dragging on EC2. Teams are skipping over the whole containerization and devops mindset and just going with serverlesss. I’m seeing it happen in my F 500 clients. Teams are designing around lambdas because they know they can get their apps provisioned and deployed easily. Remember bureaucracy is enemy #1 of success so anything that circumvents it will become a well worn path.
empath75 9y ago
In my experience, serverless, at least in aws, is primarily useful as automated glue connecting various aws services together. I think as a platform to build your core application on, it creates a lot of vendor lock in for very little benefit that couldn’t be achieved using a container scheduler like kubernetes.
schappim 9y ago
Does anyone know of a major service that natively supports Ruby? I have previously used Lambda with Traveling Ruby and Iron.io.
blabla321 9y ago
No it won't , save yourself 4 mins read
johansch 9y ago
Well, Google App Engine (both the standard/classic and flexible kinds) has been and still is pretty awesome for people who don't want to worry too much about SRE stuff but still not pay through the nose. AWS Lambda just seemed like too much bureaucratic busywork for no good reason (ugh API Gateway...), last time I tried it out. I guess it maybe appeals to "enterprise" type developers? Maybe it this way cause Werner Vogels is german and from an academic background? :-) I'm adventurous, because I write this knowing that even referring to national characteristics results in instant down votes here. Just give me an endpoint where I can respond to HTTP requests and parse the URL path/parameters myself, thank you. That way I can keep it as simple or as complex as is needed, per situation. I just don't want to bother with your insanely over-engineered API of definining custom API requests.
- flowardnut 9y ago
  >Just give me an endpoint where I can respond to HTTP requests and parse the URL path/parematers myself, thank you. This would be "lambda proxy"with api gateway. Happy to post code samples or whatever. You can also specify via slightly watered down regex what controller is called, and even do "nothing matched go here"configuration it's clunky, it needs work, but it's been great for crud or utility stuff
- michael_l_650 9y ago
  Yeah I don't use the AWS much, how does this different from GAE? Hasn't GAE existed for a while already? I feel like it's always had it's uses, and it's very nice! But the revolution didn't happen five years ago, don't see why it would happen now.
  - johansch 9y ago
    The difference is that Lambda is a) way more annoying to use, b) gets way more coverage, because developers are locked into the AWS ecosystem and often don't pay the bills.
ridruejo 9y ago
I see serverless as the new Visual Basic (in a good way!). It allows you to glue together disparate cloud APIs and services (the equivalent of OCX controls in VB) and create useful applications. Though we are still in the early days, serverless platforms will continue to get easier to use and lower the barrier of entry to cloud application development for a whole new group of developers. We built our own open source serverless solution on top of Kubernetes, called Kubeless: http://kubeless.io http://kubeless.io
- jacques_chester 9y ago
  I had occasion to look at Kubeless and Fission early in 2017. At the time I recommended we look more closely at Fission, but I am more partial to the Kubeless view that startup time is a matter to push down to Kubernetes. The decision made was to implement another FaaS instead (Project Riff). It resembles Kubeless in a lot of respects. And now I'm assigned to work on it. Funny how things turn out.
  - ridruejo 9y ago
    Thanks, I was not aware of Riff, seems indeed very similar to Kubeless in its use of Kubernetes for dealing with the low level mechanics of scaling, usage of CRDs, etc. I would encourage to revisit Kubeless as a lot of progress has been made since early 2017 and the project is getting momentum with contributions from SAP, BlackRock, Microsoft and others. Here's Seb presentation from the last Kubecon https://www.youtube.com/watch?v=8P-aXKylCVs&index=94&list=PLj6h78yzYM2P-3-xqvmWaZbbI1sW-ulZb https://www.youtube.com/watch?v=8P-aXKylCVs&index=94&list=PL...
    - jacques_chester 9y ago
      I'll draw attention to the similarities when I'm back at work. Convergent evolution is often informative.
yegle 9y ago
A quote from my colleague: despite the serverless world we provide to our customers, people still want to SSH to access their app. Also a quote from unknown source: there's no such thing called cloud, it's someone else's servers.
- illumin8 9y ago
  Who cares if they can SSH to their app? That's like saying "no matter how nice my natural gas furnace is, I still want to shovel coal." The market will speak - people don't like SSHing into servers any more than they like shoveling coal into their furnace.
CSDude 9y ago
We are using AWS Lambda in production heavily. It is basically an unhealthy hate and love abusive relationship. It works great for event triggering, cloudwatch events, sns topics, kinesis etc. when you combine them. However, the lack of ability to monitor it properly and the unflexible parts is a burdern. I hoped we were just allowed passing Docker images, and AWS handled request/input passing & provisoning properly.
- whoisjuan 9y ago
  I think where Serverless wins against managed containers, it's that you can start creating microservices that solve problems very rapidly. Need a service to manipulate an image or extract data from a file or make some type of rare business logic calculation or simply keep your storage clean... Lambda + API Gateway and 1 hour later you have a fully managed end-point that can do exactly those things in isolation.
deleted 9y ago
[deleted]
pwaai 9y ago
Serverless is the new Blockchain--hype overrides all arguments against it's inefficiencies.
rcarmo 9y ago
I just don’t “feel” this article, and I use Azure Functions heavily. My money’s on Istio (or something like it) and managed Kubernetes, since they can provide the right degree of insight/monitoring and control (any runtime, as long as you can pack it into a container) and don’t restrict you to any platform.
- emforce 9y ago
  I would be interested in getting more feedback on the article from yourself, what is it you dont feel and I could improve upon? Cheers, Elliot
  - rcarmo 9y ago
    I think the Unity analogy doesn’t make sense (I use Unity on occasion for hobby stuff) and that the article is too shallow. It lacks concrete use cases and measurable quantities.
    - emforce 9y ago
      I believe Unity has ultimately changed the way game developers work on Indie titles though. It's undoubtedly had a huge effect on all levels of indie developers due to its ease of use and the fact it handles a hell of a lot of the complexities for you. Similar to how Serverless does too. But I appreciate the feedback, it was somewhat hastily written as I was preparing for the new year celebrations haha but I will take this feedback onboard for my next articles!
_Marak_ 9y ago
I've had good success this year running and hosting serverless on my own hardware both locally in the cloud using my own application server: https://github.com/stackvana/microcule https://github.com/stackvana/microcule
MrBuddyCasino 9y ago
I hope serverless matures. Devops is the bane of my (and many of my colleagues) existence.

118 points by emforce 9y ago

Wow, there's so much misinformation and outright lies in the comments here. You do not have to "notify" anyone at AWS to scale your lambda up to whatever your account invocation limits or spending limit. Also you can run whatever code you want, native libraries, etc. If you need a cache you can use the disk or connect to some in-memory data store. You can log to wheverer you like, or throw your logs away. Local development is easy and there are several frameworks that abstract away AWS' wart-like configuration API. The limitations with lambda mostly have to do with the fact you're basically doing distributed processing with finite resources, and under an ephemeral model. Many libraries aren't written in that way, so you'll need to do some first principles work here and there but I'd argue the resultant architecture, independent of AWS, is worth it. You can share databases, S3 files, whatever. Generally speaking lambda is good for workloads that aren't always at 100% (basically almost every kind of long-tail application in computing). The cost per CPU cycle is made up when you consider this, and there's nothing to stop people from setting up lamda-style processing on their own clusters, machines, or bare metal if you think you can optimize for utilization better/cheaper than lambda/AWS. If you're in the 1 or 2% of applications where your system is latency sensitive or always at 100%, you either need to consider other architectures or ways of solving your problem. If that's not possible, lambda might not be for you. If you're someone that doesn't like new technology and is resistant to change, by all means continue to spend your time provisioning and tending to your flock of instances. You're just going to pass that cost on to your customer or user anyway.

thezilch 9y ago
You will absolutely need to notify AWS to scale to "world changing" levels or take on "massive surges" without spewing errors. There literal limits that require filling out a web form and waiting to get your ticket administered. Then Lambda is backed by EC2, which itself has functional (Re: AWS has per-minute limits on how fast you can add concurrency) and physical (Re: AWS has finite compute and will tell you they would like advances on your "massive" compute needs -- you can't just get infinite cloud off the shelf).

macawfish 9y ago

i wanna see "serverless computing" on p2p mesh networks!

braderhart 9y ago
Thank you! Isn't this what serverless really is about... federated and distributed cloud platforms? Not another buzzword from whatever cloud provider, that essentially means more proprietary systems that benefit their profits and not technology as a whole.

api 9y ago

Coding everything to run on proprietary mainframes (sorry, cloud services) is going to "change the world." Sigh.

RhodesianHunter 9y ago
>proprietary mainframes (sorry, cloud services) It's all just Linux. Easily transferable between environments.
dboreham 9y ago
The software version of The Lion King’s Circle of Life..
Agebor 9y ago
In 5-10 years, you'll click a button to move all your functions to a decentralised computing fog.

throwaway13337 9y ago

I hear a lot of evangelism but no success stories aside from one-off use cases that almost seem designed to benefit from the autoscaling. To me, this is marketing and second-tier marketing by consultants hoping to sell you their services. Serverless makes it harder to test locally, harder to move between hosts, often times much slower (cold starts), and forces going to the network to do things like persist to disk, run queues, etc. Of course, all these services are provided by the megacorp in charge of your servers so the lock-in goes deeper. The only ones that should be considering serverless are companies that need to scale up and down operations at a moment's notice. That is if you're huge or doing a lot of short-burt big data processing. Otherwise, it's all koolaid. Enjoy the open standards we have. Let's work on improving and evangelizing those instead of megacorp lock-ins.

emforce 9y ago
If we look at the likes of Unity3D, nothing was perfect straight off the bat, and I feel like the same can be said of Serverless architectures. The people offering serverless are no doubt aware of the difficulties and I wouldn't be surprised if they said they were developing something that would make this easier. Cold starts are a valid issue though and I feel that the effects of this can be minimized with the use of fast compiled languages such as Go. Lock-in is also a worry for most, as we progress we need to ensure that we are able to write serverless code in such a manner that they can easily be transported across to other serverless providers.
- jacques_chester 9y ago
  > Cold starts are a valid issue though and I feel that the effects of this can be minimized with the use of fast compiled languages such as Go. Warmed-up code will always have an edge. Even if Go code can launch very fast, the same binary retained in main memory and heavily represented in L2 and L3 caches is going to absolutely stomp the same bits being loaded from disk over and over. > Lock-in is also a worry for most, as we progress we need to ensure that we are able to write serverless code in such a manner that they can easily be transported across to other serverless providers. This will come down to folks building such platforms. I am working for Pivotal on Project Riff. Oracle released Fn, IBM and others are supporting OpenWhisk. There are really a lot of people working on it.

thezilch 9y ago

> you don’t necessarily have to worry about massive surges in traffic. The underlying system will automatically handle things such as load-balancing and the provisioning of appropriate infrastructure in order to meet any massive surges in traffic. This is wrong. Most cloud providers, AWS included, will _require_ a heads up for even small surges. There are also caps on capacity; in fact, you need to contact them to lift said caps. It's solving the market of oversaturated shared-VPS that run Node, Python, or Go? Call when you have PHP.

risaacs99 9y ago
This is just not true. A brand new account on AWS will come with a default lambda limit of 1000 concurrent invocations with up to 2 cores and 3gb per invocation. That is a massive amount of computing power. The load balancer (typically API gateway in front of lambda for a serverless app) will scale very quickly to any request volume and no one needs to be notified ahead of time.
- always_good 9y ago
  AWS' Elastic Load Balancer took minutes to spin up such that it was pretty useless, god forbid you're getting DoSed. I have a hard time believing that their other products don't have the same issue when auto-scaling.
  - thezilch 9y ago
    Lambda is backed by EC2 and absolutely has EC2's limits. Just like scaling an ELB takes minutes to serve "massive surges" -- AWS recommends you pre-warm ELBs or contact them to do so -- the same is true of Lambda.
    - risaacs99 9y ago
      AWS no longer recommends warming up the newer ALBs for the vast majority of customers and scenarios. Of course lambda isn't magic and has an initial start penalty. There are ways to mitigate it and as long as you are actively handling requests your functions will be reused. It's not magic, but it's capable of keeping up with normal traffic surges. If you have a special circumstance where you expect a large surge on a scheduled basis (say thousands of clients checking in at the stroke of midnight, you would have to arrange to be ready for that and there are a lot of ways to do it). API gateway isn't alb or elb and there isn't any recommendation or expectation that customers warm anything up. I never said "massive surge" but I stand by the idea that 2000 cores and 6 terabytes of memory is massive for most workloads. Of course, that's not the limit and you can request more if you need it. Lambda isn't for all workloads but AWS (and everyone else) is always changing and improving. You have to check in occasionally to see if old assumptions (e.g. elb) still hold.

jacques_chester 9y ago

I've recently been allocated to work on a FaaS platform[0]. A few months back a colleague and researched and wrote about FaaSes more generally. I think FaaSes have value, but I am still on the fence about their changing "everything". To start with ... > When it comes to services such as AWS Lambda, when you expose an endpoint, you don’t necessarily have to worry about massive surges in traffic. You sorta still do. The latency of a cold start is still higher than a warmed-up chunk of code. Can Node start, interpret code, perform logic and respond in less than 100ms? It certainly can. Meanwhile, a warmed up JVM can perform the same logic in nanoseconds. Lambda and most other designs I've seen retain warm copies. Either loaded in advance (I saw an AWS slide deck saying that a large part of their secret sauce is load prediction) or kept around once it has launched. But you will always have a bimodal distribution, probably quite wide, because FaaSes typically scale down to zero. Hugging the curve is never free. Either you accept idle capacity (enough to cover a start of a surge while you bring additional capacity online) or you accept lumpy latency. I suspect FaaSes will shine in situations which are sensitive to billing cost but not latency. Where latency is non-negotiable, you will either see folks sticking to services or some mix of services that are augmented by functions built from the same codebase. > These Serverless cloud providers constantly monitor and manage the underlying fleet of servers running your code. PaaSes do this too. It's one of the main selling points. > Thankfully, every endpoint you set up can use a different language runtime. This isn't really true. FaaSes currently provide a closed list of supported languages. Implementations vary, even within a single platform. What's missing here is an open extension point. I have internally argued, and I will be continuing to argue, that we already have one: buildpacks. The concept is well-understood, the tooling and testing is well in hand and we have a great deal of expertise in this area. In particular, it means we don't need to reinvent a wheel. Identifying that code is meant to be mounted in a FaaSes is no different in kind from detecting that it is intended to be run as a Rails app or a vanilla Rack app. What's missing from the discussion is what is missing from FaaSes: tools for composing larger systems. Most efforts (eg. IBM's composer[1] tool or Lambda's step functions) look at creating state machines wrapped around functions. I think this is the wrong approach. Composition should be declarative, mediated through state, with no logic outside of the functions. My model here is how Concourse defines tasks. I've been making this argument too and I hope we'll bring to FaaS users the kind of lego-brick composability that Concourse users enjoy. [0] https://pivotal.io/platform/pivotal-function-service https://pivotal.io/platform/pivotal-function-service, based on https://projectriff.io/ https://projectriff.io/ [1] https://github.com/ibm-functions/composer https://github.com/ibm-functions/composer

hobaak 9y ago

sorry, not much substance to the content.

tzahola 9y ago
>How Serverless Computing Will Change the World in 2018 You shouldn’t have expected much in the first place.

jknoepfler 9y ago

I'm personally betting against serverless computing in the enterprise, except for very specific uses. In general, serverless computing tasks cost 100-1000× more per cpu cycle than a counterpart running on a cloud server. That means that for tasks that are running regularly, they are a huge loser. They have unpredictable latency, you lose control of things like logging to disk (you get locked in to cloudwatch or whatever, yet more money and tooling required) The notion of scale seems promising at first, but I would be very skeptical before I accepted the claim that someone can scale lambda volume from 10 to 10 thousand executions per minute without setting off alarms, dropping traffic, and probably having an engineer at AWS Lamba get paged. So what are lambdas good for? I'd argue that they make good glue for deployments or batch processes that happen infrequently, don't require predictable performance, and for which having a dedicated server is a little wasteful. I'm skeptical even of those. Remember, a micro server is free tier. I have had success building prototypes with AWS Lambda, so there's that aspect too. I'd be interested to hear a counterpoint from someone who uses serverless compute in a large enterprise setting in place of a traditional server stack.

shams93 9y ago
Yeah say you do most of your processing in the client but need to sync local storage to a server for persistence and then may need to re-hydrate that state later, those can be run in the background with a service worker where the slowness doesn't affect the other parts of the application.
ryanmarsh 9y ago
I do technical agile coaching and I’m telling you not only will Serverless be successful in the enterprise it’s going to take over. 1. Enterprise systems are always Rube Goldberg machines. Serverless is perfect for this. Check out the 12 Serverless architectures talk at reinvent. 2. Most enteprise IT shops completely missed containerization. Many are still struggling to adopt the public cloud. The feet dragging and lip service by IT Infra and Security regarding public cloud is real. 3. It’s easier to give someone permission to use lambda than EC2. Thus teams follow the path of least resistance. Infra really fucked up in a lot of shops by allowing lambda but feet dragging on EC2. Teams are skipping over the whole containerization and devops mindset and just going with serverlesss. I’m seeing it happen in my F 500 clients. Teams are designing around lambdas because they know they can get their apps provisioned and deployed easily. Remember bureaucracy is enemy #1 of success so anything that circumvents it will become a well worn path.

empath75 9y ago

In my experience, serverless, at least in aws, is primarily useful as automated glue connecting various aws services together. I think as a platform to build your core application on, it creates a lot of vendor lock in for very little benefit that couldn’t be achieved using a container scheduler like kubernetes.

schappim 9y ago

Does anyone know of a major service that natively supports Ruby? I have previously used Lambda with Traveling Ruby and Iron.io.

blabla321 9y ago

No it won't , save yourself 4 mins read

johansch 9y ago

Well, Google App Engine (both the standard/classic and flexible kinds) has been and still is pretty awesome for people who don't want to worry too much about SRE stuff but still not pay through the nose. AWS Lambda just seemed like too much bureaucratic busywork for no good reason (ugh API Gateway...), last time I tried it out. I guess it maybe appeals to "enterprise" type developers? Maybe it this way cause Werner Vogels is german and from an academic background? :-) I'm adventurous, because I write this knowing that even referring to national characteristics results in instant down votes here. Just give me an endpoint where I can respond to HTTP requests and parse the URL path/parameters myself, thank you. That way I can keep it as simple or as complex as is needed, per situation. I just don't want to bother with your insanely over-engineered API of definining custom API requests.

flowardnut 9y ago
>Just give me an endpoint where I can respond to HTTP requests and parse the URL path/parematers myself, thank you. This would be "lambda proxy"with api gateway. Happy to post code samples or whatever. You can also specify via slightly watered down regex what controller is called, and even do "nothing matched go here"configuration it's clunky, it needs work, but it's been great for crud or utility stuff
michael_l_650 9y ago
Yeah I don't use the AWS much, how does this different from GAE? Hasn't GAE existed for a while already? I feel like it's always had it's uses, and it's very nice! But the revolution didn't happen five years ago, don't see why it would happen now.
- johansch 9y ago
  The difference is that Lambda is a) way more annoying to use, b) gets way more coverage, because developers are locked into the AWS ecosystem and often don't pay the bills.

ridruejo 9y ago

I see serverless as the new Visual Basic (in a good way!). It allows you to glue together disparate cloud APIs and services (the equivalent of OCX controls in VB) and create useful applications. Though we are still in the early days, serverless platforms will continue to get easier to use and lower the barrier of entry to cloud application development for a whole new group of developers. We built our own open source serverless solution on top of Kubernetes, called Kubeless: http://kubeless.io http://kubeless.io

jacques_chester 9y ago
I had occasion to look at Kubeless and Fission early in 2017. At the time I recommended we look more closely at Fission, but I am more partial to the Kubeless view that startup time is a matter to push down to Kubernetes. The decision made was to implement another FaaS instead (Project Riff). It resembles Kubeless in a lot of respects. And now I'm assigned to work on it. Funny how things turn out.
- ridruejo 9y ago
  Thanks, I was not aware of Riff, seems indeed very similar to Kubeless in its use of Kubernetes for dealing with the low level mechanics of scaling, usage of CRDs, etc. I would encourage to revisit Kubeless as a lot of progress has been made since early 2017 and the project is getting momentum with contributions from SAP, BlackRock, Microsoft and others. Here's Seb presentation from the last Kubecon https://www.youtube.com/watch?v=8P-aXKylCVs&index=94&list=PLj6h78yzYM2P-3-xqvmWaZbbI1sW-ulZb https://www.youtube.com/watch?v=8P-aXKylCVs&index=94&list=PL...
  - jacques_chester 9y ago
    I'll draw attention to the similarities when I'm back at work. Convergent evolution is often informative.

yegle 9y ago

A quote from my colleague: despite the serverless world we provide to our customers, people still want to SSH to access their app. Also a quote from unknown source: there's no such thing called cloud, it's someone else's servers.

illumin8 9y ago
Who cares if they can SSH to their app? That's like saying "no matter how nice my natural gas furnace is, I still want to shovel coal." The market will speak - people don't like SSHing into servers any more than they like shoveling coal into their furnace.

CSDude 9y ago

We are using AWS Lambda in production heavily. It is basically an unhealthy hate and love abusive relationship. It works great for event triggering, cloudwatch events, sns topics, kinesis etc. when you combine them. However, the lack of ability to monitor it properly and the unflexible parts is a burdern. I hoped we were just allowed passing Docker images, and AWS handled request/input passing & provisoning properly.

whoisjuan 9y ago
I think where Serverless wins against managed containers, it's that you can start creating microservices that solve problems very rapidly. Need a service to manipulate an image or extract data from a file or make some type of rare business logic calculation or simply keep your storage clean... Lambda + API Gateway and 1 hour later you have a fully managed end-point that can do exactly those things in isolation.

deleted 9y ago

[deleted]

pwaai 9y ago

Serverless is the new Blockchain--hype overrides all arguments against it's inefficiencies.

rcarmo 9y ago

I just don’t “feel” this article, and I use Azure Functions heavily. My money’s on Istio (or something like it) and managed Kubernetes, since they can provide the right degree of insight/monitoring and control (any runtime, as long as you can pack it into a container) and don’t restrict you to any platform.

emforce 9y ago
I would be interested in getting more feedback on the article from yourself, what is it you dont feel and I could improve upon? Cheers, Elliot
- rcarmo 9y ago
  I think the Unity analogy doesn’t make sense (I use Unity on occasion for hobby stuff) and that the article is too shallow. It lacks concrete use cases and measurable quantities.
  - emforce 9y ago
    I believe Unity has ultimately changed the way game developers work on Indie titles though. It's undoubtedly had a huge effect on all levels of indie developers due to its ease of use and the fact it handles a hell of a lot of the complexities for you. Similar to how Serverless does too. But I appreciate the feedback, it was somewhat hastily written as I was preparing for the new year celebrations haha but I will take this feedback onboard for my next articles!

_Marak_ 9y ago

I've had good success this year running and hosting serverless on my own hardware both locally in the cloud using my own application server: https://github.com/stackvana/microcule https://github.com/stackvana/microcule

MrBuddyCasino 9y ago

I hope serverless matures. Devops is the bane of my (and many of my colleagues) existence.