Escaping Henry Ford’s IT with Programmability
Henry Ford (did or didn’t) famously say “You can have any color car as long as it’s black.”
Without getting into the debate over whether he actually did say that, it’s attributed to Mr. Ford and his assembly line primarily due to the fact that it accurately represents the constraints placed upon manufacturing by the move to automated assembly.
The reason for this is the standardization (one might say commoditization) behind the automation associated with making the assembly line so successful. Lean manufacturing principles (the ones that result in faster delivery of higher quality by reducing variability) still tell us that eliminating wait times improves efficiency but reducing variability (through standardization) promotes stability, i.e. fewer defects.
That’s certainly a desirable outcome for today’s digital assembly lines, a.k.a. the production pipeline. Who doesn’t want faster assembly of the various parts and pieces (network and app services) that we need to deliver fast, reliable, and secure apps with fewer errors?
The problem is that the process of standardization almost always starts with commoditization. That is, everything is decomposed into its most basic, standard parts. No matter who provides those parts, then, they are all the same. The same nuts, bolts, and connectors (options, algorithms, and APIs) are supported by everyone. For example, instead of twelve different load balancing algorithms you limit the options to three industry standard ones, and restrict the configuration options available. All services get stripped down to the basics, making it easier to assemble because one size really does fit all then.
But just as we aren’t limited to just black cars, today, we are not limited to “just the basics” when we automate the digital assembly line. That’s because increasingly infrastructure is moving from an imperative (how, APIs) to a declarative (what, templates) model that enables a more robust set of options, configurations, and algorithms across all network services. The standardization (abstraction) is presented to the user; to the developer or admin responsible for managing the infrastructure and provisioning services. Another layer of abstraction is offered to the provider of those services, to the vendors who are operating under the influence of the other API economy in which programmability is a key factor in playing well with others.
The difference may appear pedantic, but I assure you it is not. It is a significant change in the way services are provisioned and ultimately provided. In the imperative model, a heavy API tax is paid on execution. Each step of the configuration process requires a separate and distinct API call. That means a significant amount of technical debt is built up either on the developers of the cloud stack or, if you’re rolling your own, on you. The choices you make early on will determine flexibility in the future.
A declarative model still relies on an API, but that reliance is only as a transport mechanism to deliver a template (or policy) describing the service. It is then up to the provider of the service to determine how to execute the configuration of the desired service.
The thing is that the declarative model is still standardized. A single template or policy format is used to describe a given service. But because the actual execution is now the responsibility of the service, additional options (colors!) can be supported.
I can employ advanced features in a load balancing service if they are available using a template or policy format, but doing so in an API-driven model is more difficult, because those features may require explicit API calls that simply aren’t “standard” across all load balancing services. Increasingly, we’re seeing the insertion of domain-specific orchestration system as a sort of “service gateway” between the core abstractions offered by a data center orchestrator and the actual services themselves. This intermediary is responsible for integration with the data center orchestrator and for executing provisioning and configuration of a more robust set of services than is possible with a commoditized, imperative model.
It is templates (policies, if you prefer) that will enable organizations to enjoy the benefits of standardization without sacrificing the competitive advantages of more advanced customizations. A template-based, declarative architectural approach to automation and orchestration will ensure that you can, in fact, have any color car you want.