There's still a ton of creating zip file artifacts of your lambda payloads (instead of pushing to a magic git repository that amazon controls, say), so there's a bit of "build monkey"ing to do instead of "devops"ery. But I think a lot of shops will be happy to make that trade, as "build" is closer to their core experience than "devops".
You gain vendor lock-in. You are now tied to the Amazon platform. If they shut down or suspend your account, for any reason, you are out of business. You are also paying premium for the platform, with the cost of devops built in.
I'll take an open ecosystem that gives me options to migrate my business anytime over a proprietary solution.
http://recode.net/2015/03/18/amazon-will-shut-down-amazon-we...
I think the open ecosystem approach will work well for apps/systems that are more established and have a predictable and sustainable user base and related revenue stream to maintain the system.
But for new ideas, early stage startups, the open eco-system approach will be a lot more work than using the high-level services providers like amazon are developing ...basically a no-stack approach can help one quickly find some product / market fit. Once some level of baseline level of utilization is understood then switching to a more difficult, but less-locked in approach would be smart.
all that said, there's probably a middle ground here too (but arguably not) -- where one deploy's using docker containers, private registry & image repo, s3 for static immutable storage and some open database like PostgreSQL on RDS. All that could be layered on top of AWS and other providers -- but it will still be a PITA to move the whole thing.
BTW -- take a look at the elasticbox product -- they really have an interesting approach to cloud that sort of obviates the lock-in issue by allowing one to build apps across clouds from the start using their "boxes" metaphor.
Edit: well, unless you run your php script in a PaaS like Google App Engine.
The smaller the scheduled unit of code is, the more densely they can pack the workloads and make more efficient use of their system ...squeezing out the pennies at their scale makes a lot of sense.
I've seen some vendor lock in comments here -- but certainly the big 3 or 4 service providers will have these features figured out soon - and seems to me some open source to schedule functions across compute will appear in no time that could be used by the smaller providers. replicating all the other features is much harder -- this is a great moat amazon has built.
As shown in another thread here, this service does not infinitely auto-scale (the recommendation was to use Kinesis), so you still have to know which services to choose, which is pretty much a full-time job with the number of different services offered these days.
They say after all:
"and then unit and load tested it, all without using any servers."
...with a title of "Microservices without the Servers" when what they mean is
"without provisioning any servers yourself" which is obviously much less attractive.
My curiosity was peaked by the title the title, inserting "w/o provisioning" would have not gotten me anywhere near as interested in the topic.
Serverless implies that a server is not required after an installation step and that you only need your local device. Or perhaps too that you only need a collection of like clients to do something P2P.
Just because you as the developer don't have to think about the server doesn't make it serverless.