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
My team ditched serverless functions. We're better off without them.
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.
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.
There's probably enough there to bootstrap a container version.
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.
aws lambda update-alias --function-name myfunction --name myalias --routing-config '{"AdditionalVersionWeights" : {"2" : 0.05} }'What's the difference? Scaling isn't one.
Can I call my Postgres deployment on Azure via AWS lambda?
Lambda also provides a lot more than containerized services, as the article mentions - I no longer have to patch my system, which is a huge operational/ security burden that many companies struggle with. The time to configure API Gateway/ Lambda feels trivial compared to the work involved in maintaining a patched FAAS solution.
On top of that, many of AWS's services use standard API's. It's not hard to move away from RDS or Elasticache, you're just using SQL/Redis anyways...
If we're talking about something like SQS, ok, well you can just as easily say you're "locked in" when you use RabbitMQ because there is work involved to not be using RabbitMQ.
API Gateway, kinsesis, s3 change/addition...
It definitely has more lock in potential than more "vanilla" offerings like EC2, RDS, S3.
You could name a replacement/competitor service for each of the above, but if the Lambda is triggered by S3 changes then that's a big barrier to putting your static files elsewhere
The major difference is that Lambda hooks into your developer tooling, and source code, in a way that EC2 doesn't.
Sure, you can use Lambda without calling AWS APIs from your app... But you'll be using SDKs, tools and documentation that push you to do so, every day. It will require conscious thought and effort in your development to avoid lock-in, and over time the required effort will increase, because more and more third-party tools and libraries will switch to proprietary dependencies, dragging you along with them.
Traditional vendor lock-in is when you can't move away from (e.g.) your Oracle database because you've got a dozen different applications that will need simultaneous rearchitecting if you ever want to get away from it.
Someone thinking the need to adapt the input parameter format to achieve provider portability is by itself enough reason to add docker to the application stack is making a huge mistake in accessing the relative cost of these components ...
I don’t think deploying containers to different providers is anymore standard than the differences involved in deploying cloud functions to different providers so it’s not as if using docker would actually give a more uniform multi-provider deployment model ...
EDIT: I'm actually less curious about the code, and more curious about how you're sharing code between different Lambda functions. Did you publish an npm package? Are you just repeating the code? Symlinks?
Serverless allows deploying multiple lambdas with entry points exposed from an npm package using cloud formation with standard code sharing practices applying — that is it’s easy to share code between entry points if all the entrypoints are defined in one serverless config file (one serverless config file corresponds to one cloud formation stack)...
It’s a bit more work to share code between stacks with serverless tho ... You either have to put shared code into a separate npm module and depend on that module everywhere you need the shared code (often incidental complexity for simple or unstable code!) or use symlink patterns that work with the grain of how the serverless bundling process works...
I actually created an issue suggesting a serverless feature to ease this a few months ago https://github.com/serverless/serverless/issues/4124. In that somewhat long feature request I describe the symlink pattern I’m using for easily sharing code and compilation contexts between stacks... I’m still using that pattern — it’s not terribly fun to explain to new developers on the project but it works well without a lot of gotchas so far ...
On vendor lock-in, I'm moving between clouds now. Serverless did not translate well at all. We would have saved a ton of time, and frankly had an easier operational experience, if we went with Docker from be beginning.
"Ok Jill, next we need to determine how Azure Storage Account bucket calls differ from AWS S3. Oh, S3 doesn't have queues so we need to use SNS which changes the transaction model...Yeah, we've gotta handle different guarantees"
Product at most places "doesn't have the time" for developers to abstract the serverless hooks. You have to change the interface that runs your app instead.of the interface your app provides.
https://azure.microsoft.com/en-us/blog/announcing-azure-blob...
Let’s split lock-in into two categories:
1. Essential complexity
DyanmoDB and Firebase are different products with different features and complexities. There is no “ANSI SQL” here. They are as different as they are similar. Moving from one to the other is a non-zero cost because they have different features your app would have to make up for or adopt.
2. Inessential complexity
Serverless functions don’t necessarily need different signatures and it is conceivable that a standard for HTTP evented functions could emerge. Many are working on this. I expect this to be largely resolved over the next few years.
Lastly, I’m grateful for ANSI SQL but over the last 20 years I think I’ve seen one or two clients migrate a mature Java app from one database vendor to another (excluding some very recent moves to AWS RDS). Keep in mind that JDBC is about as good an abstraction as we’ve ever had for database agnosticism.
When you choose to build a lot of complexity upon an abstraction you have to be honest with yourself: have you ever dealt with a service (storage, queues, naming, auth, etc...) that didn’t have leaky abstractions? Of those with few/zero leaky abstractions how often did you need to migrate to a different vendor? Why do we expect a rapidly evolving set of systems and services to behave like mature commodity software?
Fear of vendor lock-in is a premature optimization.
All of the manual configuration of API gateway vanishes because it builds up an implicit API gateway from your functions and event mapping config.
You can see a boilerplate SAM config here: https://github.com/nzoschke/gofaas/blob/master/template.yml
I'm hacking on CORS today and with SAM it's 2 lines of config to add the allowed origins and methods.
While we're on the subject, Cloudformation could definitely use some work too. AWS, please tell me what line the template failed at. We had to use the swagger extensions to integrate cognito and those were failing because of indentation errors, but it just kept complaining about invalid swagger 2.0 definitions. That is just so gross.
Also, Lambda doesn’t provide any sla’s on container reuse. They could restart your container multiple times per second or every few minutes. You are at their mercy to keep your containers warm.
Finally, with the meltdown example, would containers actually need to be patched if the parent OS gets patched since the kernels are shared between host and client containers? With Fargate, amazon would patch the base OS and your containers would be safe as they get rescheduled onto patched nodes.
There are also some abstractions like Kubernetes that are neutral yet also managed with extras by all the providers which is a nice middle ground.
None of this is new or groundbreaking other than the silly hype words like "serverless".
While other auto-scaling PaaS exist, the granularity of the lambda pricing model is fairly new and groundbreaking. A service can be launched that may see very little use and just costs pennies to test out during its initial phases. That same service will scale exponentially rather easily in comparison to a similar deployment on a traditional server.
Forget that they take more time to care for, and to learn how to ride, and how to feed properly.
Serverless platforms increase convenience.
Throwing them away decreases convenience and increases developer time to learn and launch.
Many great inventions, like writing, automobiles, all increased convenience.
Throwing away inventions that increase convenience, decreases convenience.
Humans reproduce. Trees reproduce. Humans should reproduce with trees.
Just because something is logical doesn't mean it makes sense.
You can choose to deploy your own open source Faas framework (like openwhisk or open-faas) on one of these clouds, but YOU will have to:
1. Manage scaling of underling EC2s
2. Manage security patching of both the docker and underlying OS
3. Setup whole lot of configs
4 manage optimizations
With a managed FaaS you're trading ops for more dev time, but someone has to be paid for the ops - it isn't free
Serverless (AWS Lambda) is just the cloud's way of trying to "de-commoditize" the containers that commoditized them. They want you to tightly couple your applications to their specific cloud provider again. And charge you more. How much is that function in the zip from S3 going to cost you to run in a container managed and run by AWS? And how long did you spend configuring the API Gateway (and where else can you apply what you've learned doing the configuration)? Next time you see an article fawning over serverless and saying things like "Containers just don’t matter in the serverless world" take a look at what the author does for a living. You'll start to see the same pattern I've been seeing.
Meanwhile, you could be spending less money and time treating AWS like a dumb processor with a network connection while only really configuring the open source software you already know. But it's your time and money.