Why would I split, write, and deploy an vendor cloud function for every cloud provider when Docker moves between them?

My team ditched serverless functions. We're better off without them.

Wouldn't it be ideal if Docker (and other independent platform vendors) added function support? In my mind "cloud functions" are easily implemented on top of containers. Then we would get the best of both worlds.

Check out this project: https://github.com/openfaas/faas

It wouldn't, to me.

I've had to answer many questions about delays in serverless functions that didn't come up with Docker. Serverless doesn't have the introspection necessary to answer performance questions.

What if Docker supported functions? I'd ask what we gain trading a main loop for only bindings. Similar bindings are made either way.

I honestly wish cloud providers would make their core SDKs as easily composable as their serverless offerings.

Exactly. This is the goal of http://FnProject.io -- power of containers + simplicity of serverless. No managed service yet but there will be, and anyone can run the bits to create a service of their own.

I do agree with Paul about containers having a greater update surface area, but we think this is also solvable and doesn't need to be a responsibility of the developer either.

The Azure Functions (Azure's equivalent to AWS Lambda) Host is open source: https://github.com/Azure/azure-functions-host/

There's probably enough there to bootstrap a container version.

Have you looked into Cloud Foundry? From my understanding, it can operate like a FaaS provider or like a Docker container scheduler.

Do you manually manage the infrastructure (keeping instances hot/cold, updates, scaling, etc.)? If so that's a lot to consider.

Containers are generally managed similar to serverless.

AWS drains connections and workloads on container deployments. I set the same rules to scale either.

Containers offer flexibility that serverless doesn't for implementing hot/cold, blue/green, n running with n+1, etc.

So, additional flexibility with the same considerstions.

Lambda support blue/green and all sorts of flexible stuff:

    aws lambda update-alias --function-name myfunction --name myalias --routing-config '{"AdditionalVersionWeights" : {"2" : 0.05} }'

Because then every single functionality will scale independently as needed. No need for orchestration.

AWS and Azure offer cloud hosted Docker support that scales independently as needed. Both can orchestrate Docker with similar interfaces to functions.

What's the difference? Scaling isn't one.

> AWS Lambda itself isn't vendor lock in.

Can I call my Postgres deployment on Azure via AWS lambda?

Yes you can, but even that wouldn't be lock-in. Lock-in imo had much more to do with whether you have to write your code specifically to the vendor, and in the case of all 3 FaaS, the answer is mostly "not really." It is trivial to transfer the same behavior from lambda to Google cloud functions.

This is a pretty fair point about service discovery. Without proper service discovery, Lambda is pretty useless IMO.