Paul Hammant's Blog: Thinking About Serverless Again
There was a blog entry yesterday - Serverless: The New Way of Thinking (Alen Komljen) - that I felt was making a good attempt to outline why you should aim at serverless but was a little incomplete. In my previous serverless post last year I talked about the fact that you’re not dealing with domain names, IP addresses, ports, sockets or processes of participating parts of the stack. Alen didn’t talk about this things.
The bad old days of EJB
If we cast our minds back to the (ultimately terrible) Enterprise Java Beans (EJB), and Sun forming a committee of vendors to specify that in early 1998, we remember that we were able to deliver applications where services were spread out over multiple machines and that leveraging that was the ‘simple’ act of locating those services via JNDI, possibly CORBA (or perhaps RMI), then some clunky error handling for wire-invocations of services, and otherwise not knowing how far away the implementation of the services. Actually, all of it was clunky in use. Massively so compared to the transparent and fabled ‘Voyager’ technology that was around before the EJB spec homogenized the alternates. EJB 3.0 brought in some elements of Dependency Injection to EJB. Aslak Hellosoy (famous today for Cucumber) and I got some credit for from the spec lead Scott Crawford:
…
EJB 3.0 eliminated some of the clunkiness, but didn’t go far enough (should have done dependency Injection). Anyway, EJB being a “for Java” thing was definitely a homogenous computing thing, as the CORBA capability to interoperate with other non-Java ecosystems was beyond a tasteless joke.
So what if the serverless way of working was the same aims as EJB, but heterogeneous (and principally in the cloud rather than on-prem only as EJB was at least initially). In serverless you have a way to depend on other computing functions, possibly in alien languages and techs, but again be given some tools to take away the complexity of acquiring the dependency for the sake of invoking its services. Where EJB only gave you those clunky tools to acquire dependent services, Serverless has gone much further to delivering it - terser more elegant APIs for that (even if they vary slightly per vendor platform and language within a single platform).
The DI way
I am reminded of another ‘cause’ though. One I was haranguing people on constantly from 2001 onwards (before I joined ThoughtWorks)- Inversion of Control. It again came with clunky lookup mechanisms. Well, at least Apache’s Avalon framework did (type 1 IoC as I was calling it back then). IoC said nothing at all about remoteness and marshaling. Indeed it was perhaps against that really, as it was fascinated with in-process dependency resolutions for components not services*. Aslak and I were bugging Scott about Dependency Injection. Specifically Constructor Injection (former type 3), which super nailed the need for declarative specification of the needs of a component. The EJB 3 team went with Setter Injection (former type 2) instead. How far does serverless go towards that - declarative dependencies for dependent services? It is great that serverless solutions can be heterogeneous (versus EJB’s homogenous), but maybe it could go closer to declarative aspects of DI. The Amazon Lambda documentation mentions DI but only I think as an inside-a-single-FaaS-service consideration:
Yeah, our PicoContainer (like Guice/Dagger but before Guice/Dagger) doesn’t get mentioned so much anymore.
So, as I wrap up I wonder if the truly declarative aspects of the DI (and Inversion of Control) get spooned into the FaaS world some more over time. Certainly this StackOverflow advice on how one service depends on another doesn’t look very declarative. The old Avalon had components shipping with XML manifests listing their dependencies, and constructor injection as PicoContainer did it dispensed with the need for that. Would FaaS benefit from something like that? Perhaps it has it already and I am too post-technical to know.
- Services (to me) have connotations of remoteness, marshaling. Components that don’t, I think. Never mind ‘decompose’ and all that implying something more general than same-language-family and same-process that I think it’s about.