aws lambda - some words

To get these out of my head so I can stop thinking about them...

At re:Invent last year, Ben Golub was up on stage singing the praises of Docker. The masterminds at AWS had arranged for a solid 20-30min of Docker love-in before making the day 2 technical announcements. Ben said that [one of] Docker's goals was to free developers from having to worry about production and delivery (or something like that, see his keynote). Then Werner comes on stage, describes Lambda, and more or less says that while others are trying to free developers--Lambda actually does that. Pretty amusing.

Lambda will drive some usage away from other AWS services. I've already seen experimentation and real usage start amongst high end AWS users (not just Netflix). You could view it as cannibalization, but it's much smarter. Presumably AWS has figured out how to price Lambda in an accurate way such that the cost of all the underlying and adjacent services consumed is priced in.

Lambda might be a "true" PaaS in the sense of being a pure runtime where you don't have to understand the underlying mechanics or implementation of compute, storage, database, etc etc at all. There are no buildpacks, runtime plugins, etc etc like you have in most PaaSes.

Like Jeff Barr said in his blog post: "You don't have to configure, launch, or monitor EC2 instances. You don't have to install any operating systems or language environments. You don't need to think about scale or fault tolerance and you don't need to request or reserve capacity. A freshly created function is ready and able to handle tens of thousands of requests per hour with absolutely no incremental effort on your part, and on a very cost-effective basis."

Although it has constraints, like only being Node and only allowing up to 1GB of memory consumption per function (last I checked), etc--it's a completely abstracted runtime environment. You give it code and a few variables. It does the rest.

It completely removes Ops. Why DevOps when you can just Dev? It's more like Google App Engine than anything else out there. But GAE won't let you have long running functions (more than a few secs, last I checked), so in its limited way it's already a step ahead.

Where a Docker container gives you theoretical portability because your entire app is packaged in a way that's independent of what it's running on (but not really). Lambda locks you in because you have no idea how your code is running or what it takes to run your code. The only thing you could conceivably move to is GAE, but you'd have to rewrite bits and metadata in order to do it. Oh, except that GAE doesn't do Node. So nevermind.

It's brilliant. 

It's also dangerous. If you never learn how the thing below what you are doing--what you are downstream of and rely on--works, then you become intrinsically dependent on the provider of that service. Great when that service is an actual commoditized utility with multiple providers in a competitive marketplace. Miserable when it's a monopoly. Creating that dependence is good gameplay on AWS's part. Not providing equivalent alternatives that conform to the same interfaces is bad gameplay on everyone else's. Becoming hooked is a poor decision on our part, unless we do it with eyes wide open and willingness to do the work of unhooking ourselves in the future.

---

Or, as Nick Weaver puts it:

what aws is not

In 2004, SQS and AWIS beta-ed.

In 2005, MT beta-ed.

In 2006, S3 and EC2 beta-ed.

From there, the pace of releases has skyrocketed (something we should put value on). AWS started by turning basic computation services into utilities. They've since done the same to a wide range of technology capabilities--dozens of services, hundreds of options, a combinatorial explosion of capabilities. So far so that we could reproduce all the functions and services provided by any data center anywhere.

That's where AWS is. AWS is not a commodity, though specific AWS services may become commodities. AWS is not basic computation services. AWS is not just for startups or web2.0 or mobile or small shops or transient projects or marketing or unregulated.. etc.

AWS is the successful utility-isation of ever more, and ever more valuable, technology services.

They are building the AWS of next year or further out through utility-ifying whatever it is that their ecosystem (customers included) is telling them (through behavior) is worth paying for. 

To really compete, you'd have to: match the ecosystem play and exert margin pressure. The former you could do through co-option--which would require taking over the service supply chain--or through drawing your own ecosystem to some core differentiation (e.g. live migration on GCE or seamless public/private experience on Azure). The latter can only be afforded by a few organizations (Google and Microsoft).

Hat tip: Most of the thought above is a direct result of, or informed by, Simon Wardley.

communication in the service and api supply chain

Another thought about “the service and api supply chain” —how do we know what an API provider or servicer can do? It’s unlikely that any given servicer of an API will service the same subset of that API as any other servicer or be able to keep up with all the changes that are introduced by the API originator.

Can you ask an API endpoint:

• Hey, what can you do? 
• What APIs do you originate and provide? 
• What 3rd party APIs do you service? 
• What subset of those APIs? 
• What are your SLAs?
• Etc.

Can the API endpoint tell you:

• I’m running out of capacity to service X?
• There’s a degradation of service Y?
• You can send these calls to these other endpoints I own?
• This is how much I charge per call for Z?
• Etc. 

We could use a (roughly) global language with some basic terms for services that describe what they do, what they service, how they do it, with what kinds of commitments. An analog to Wolfram Language for distributed services. 

We could use a (roughly) global protocol for handshakes and mutual understanding so services can talk to each other, advertise and discover what they can do, what they can service, how they do it, with what kinds of commitments and interrogation mechanisms. An analog to ethernet autonegotiation for distributed services.

Plenty of API providers don't want this to exist. But the competitive advantage that could be generated by programatically dealing with an API should draw a significant ecosystem. So I wonder why this hasn't been done, especially be near-first tier providers like GCE and Azure. I can only guess it's because they haven't figured out how to do ecosystem-based strategic gameplay for cloud services yet. And of course, AWS has no need to do such a thing (yet).