If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

Escaping Henry Ford’s IT with Programmability

assembly lineHenry 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.

provisioning models

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.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.