APIs and Alan Moore Characters

It was originally intended to be a straightforward conversation about APIs, but thanks to Ian Murphy of Enterprise Times several Alan Moore characters managed to enter the discussion. Magic is certainly something we can all use in organizing our APIs and automating our processes.

Failing that, it’s important to cut ties with the past and implement best practices for an API first design approach, to ensure the APIs provide the service the consumer needs and wants. Just wrapping existing code with an API is unlikely to cut it, although this is a tempting shortcut. Generally in this area however, you get what you pay for.

It’s also a lot better to take security into account from the start, rather than having to redo things and remediate potential vulnerabilities just as you are about to deploy to production.

And it’s very intersting that we are basing our APIs on REST now – understandable, of course, but interesting that the best practices for HTTP (which embodies RESTful principles) evolved from a completely different stream of technology development than WSDL-based Web services and traditional middleware.

As unexpected as it might seem, if you think about it, Alan Moore’s dr & Quinch characters are a good fit for the kind of chaos monkey style of resiliency testing helpful to improve the stability of APIs.

And – thanks for this one Ian – who initially thought of Mina Murray as the best one to impress upon independent minded developers the need to follow a common purpose, just as she did for the League of Extraordinary Gentlemen. I’m just as sure she would be capable as I am that some API dev teams would benefit from such leadership. This is a constant challenge with dev teams, of course. Just not sure everyone really needs a vampire to lend a hand.

Anyway , it was great fun to approach the topic this way, and I hope Ian won’t mind if I mention that he told me he has actually seen one of Alan’s spoken word performances. I’m sure that was really cool, and potentially disturbing.

Now, I only wish old Moore titles would increase in value the way DC and Marvel title recently have, since he is by far the best writer in the field today. Maybe this has something to do with movies…

It’s not just about the pizza

Before I begin this, let me note I’ve broken another rule of blogging, which is that I promised to write a new entry soon… Anyway here is a new entry. I will not say anything about the next one 😉

In the world of microservices, the term “two pizza team” has a specific meaning – i.e. the right size of a dev team is one you can feed with two pizzas. The group structure and responsibilities of development teams is, if anything, more important than the technology they use.

In a previous blog post, I wrote about the influence of commodity server infrastructure on system software and application design, in particular how microservices evolved as the best way to design applications for deployment on modern IT infrastructure.

But the common misconceptions about microservices go beyond that. It’s not just about new technology and techniques. It’s also about changing the development culture. And of course the pizza that fuels it.

I couldn’t find Jeff Bezos’s original post anywhere, but I found this post that contains it, and describes a lot of the things the Amazon developers had to learn to implement SOA successfully. Of course Bezos’s 2002 memo is famous for mandating SOA or API-first development for the Amazon Web site, a course they have successfully followed in building a platform and creating a website that can be updated literally hundreds of times a day.

In Jeff Bezos’s world, the two-pizza team is a key principle of productivity. For the SOA and API first approach the two-pizza concept constrains the size of a development team. Larger teams are less productive. Marry this with the SOA and API first directive, and you end up with a lot of small teams building individual components of the application and deploying code without disturbing other teams, since everyone is adhering to the SOA principles of strongly governed interfaces (you don’t deploy incompatible changes to the interface, basically, without getting agreement from other teams dependent on those interfaces).

From talking with Amazon developers, I understand the dev teams take complete responsibility for the function (or functions) they deliver to the Website in the form of microservices. Including support – the dev team wears beepers in case a production problem occurs.

Part of this is because of the way the commodity computing works. It’s the “pets vs cattle” analogy, among other things. When you are dealing with servers as “cattle” you have to automate the system administration function. It’s simply not possible to manually administer hundreds of thousands of PC based computers. AWS has posted a good definition of DevOps as the merger of the dev and ops functions. This represents a significant culture change for traditional “scale up” IT environments, since there is no longer a separate Ops team and Dev has to provision all the infrastructure (data stores, messaging, networks, etc.) using APIs.

Even MORE APIs you say! Yes. So let’s conclude by revisiting a key part of this discussion – API governance. Why haven’t more companies followed Amazon’s lead? They have proven the API first SOA design approach to be very successful, if not essential in modern computing and digitization.

Mark Settle in Forbes argues it’s because of the governance, or lack thereof. Yes, it’s incredibly hard to change the development culture to two-pizza teams developing microservices with strongly managed interfaces. You need someone like Jeff Bezos to mandate it. Or at least have the organizational will to change the development culture.

The Amazon Web site Death Star from 2008! Showing the microservices landscape, essentially.

What everyone gets wrong about microservices

Martin Fowler has collected a lot of good information about microservices, but does not understand their origin as the “right size” unit of work for commodity data center infrastructure. This is apparent from his advice to start with a monolith and decompose it, as if the target deployment environment had no bearing on design.

I suppose that’s the way he and many others would naturally approach it, given the frame of reference is the traditional 3-tier application server model and the abstraction of Java from the hardware and operating system it runs on. This leads him and others to view of microservices as an evolution of development practices to facilitate rapid change, rather than a fundamental shift to design for appropriately sized units of work.

I give Martin a lot of credit for identifying and defining development best practices, including helping establish the agile method. But microservices did not originate as a development best practice in the 3-tier app server environment. Nor did it become popular because people were deconstructing monoliths. Microservices are a creature of the infrastructure they were designed for – the commodity data center.

I don’t think Martin and others viewing microservices as a development trend takes into account the strong relationship of the deployment infrastructure to the origin of the microservices design pattern. I give Martin a lot of credit for including Stephan Tiklov’s clear rebuttal to the monolith-first silliness though.

Google invented the commodity data center infrastructure about 20 years ago, and this has become the de facto infrastructure for IT since then. It is the most cost effective IT infrastructure ever built. Pretty much all Web companies use it, and most pre-Web companies are planning to adopt it. Their original servers are in the computer history museum for this reason (photos below).

Commodity data center infrastructure offers a compelling range of benefits in addition to cost-effectiveness, such as auto-scale, large data set capacity, and automatic resiliency, among others. In order to achieve those benefits, though, software has to be engineered specifically to run in this environment, which is basically where microservices come from. Some core design assumptions allow a very high tolerance for hardware and software failures, but these assumptions are very different from the assumptions on which the traditional IT infrastructure is based, and applications have to be broken into smaller units of work suitable for deployment on PCs and connected via network into larger units of work.

I can understand a view of development best practices unconnected to deployment infrastructure considerations – after all, the traditional IT industry has been on a path for years to “write once, run anywhere” and it’s easy to assume that language and operating system abstractions will take care of harware infrastructure mapping considerations.

But in the case of microservices, it is a big miss to ignore the target deployment infrastructure as the origin of the design pattern, since both the hardware and the software on which they are intended to run has such different characteristics.