as MBlume mentionned[1], they seem to support NodeJS.
From the FAQ :
"At launch AWS Lambda supports code written in Node.js (JavaScript). Your code can include existing Node.js libraries, even native ones."
so it seems that you can avoid lock-in if most of your javascript code is not too coupled to Amazon's API
And they claim on the detail page:
"With AWS Lambda, there are no new languages, tools, or frameworks to learn. You can use any third party library, even native ones. At launch, AWS Lambda will support Node.js code, with support for other languages coming in the future."
Err, I think the parent's point wasn't lockin in terms of the code you write, but in terms of your architecture. Setting up your own system driven off of s3 or dynamodb events (if you wanted to move the functions onto your own bare metal) would be a pretty big project.
that's a REALLY good point! this feature seems really solid, but they seem to be putting a sort-of "golden handcuff" on you. If you have a distributed system on AWS which implements "lambda functions," you can forget about switching to Azure, or your own bare metal servers without having to go through some pain. "vendor lock-in" definitely seems to have been their motto here, very clever & great observation!
Well, yes. That's the thing about AWS. It's a very feature rich & sophisticated platform, which is hard to replicate elsewhere with the same harmony without spending a great deal of investment.
I won't be surprised if someone writes a generic lambda library which given a cloud provider generates relevant mappings/code. Will take care of some of the vendor lock-in concerns ?
I think this would be the solution. I guess lambda is basically IFTTT at scale with more configurable "T" portion.
Anyway, libcloud seems to be leading the way in this kind of standardization, so that's good news. There's also providers that have drop in AWS-compatible APIs for some services. Then there is stuff like apache mesos for creating that infrastructure, which is less relevant to smaller companies.
But I suspect that the last thing Amazon wants is to turn into a commodity, so it's in their interest to release as many differentiators with non-standard APIs as they can.
As someone who is non-technical, how much code/infrastructure would this save? I'm trying to understand how locked in this would really make you, and how difficult it would be to replace this on some other IaaS provider?
Any use of non-standardized service will only help you lock in further. Though a lot of companies/start-ups do not care if it saves time/cost and perhaps they are already deeply invested in the ecosystem.
It seems that this system puts together all events generated by Amazon services to trigger new events. This is usually not that complicated to code, but the catch is to make these (usually) scripts/programs highly available, which Amazon provides.
I'm guessing that this Lambda functionality is built on the new ECS (EC2 Container Service) which is built on Docker. Therefor, it should be reasonably doable to recreate it on-premises and escape the AWS lock-in. "should" being the operative word there. :)
It's no different from stored procedures and triggers in a database, or a shell language on an operating system. At some point you will have to invest time creating logic, for your purpose, on somebody else's system.
