Hacker News Reader

Comment by djhworld | Hacker News Reader

AWS Lambda itself isn't vendor lock in.

If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers.

The vendor lock in creeps in more around the surrounding services that the cloud provider offers. You can protect yourself from this though by writing good quality hooks that have pluggable backends, e.g. writing/reading to an object store should be abstracted

View on HN

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.

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.

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.

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.

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

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.

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

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.

> AWS Lambda itself isn't vendor lock in.

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

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

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.

Reply on news.ycombinator.com