In a recent Cortex, I bemoaned the fact that as buzzwords go, Digital Transformation is excessively vague. There is yet another buzzword of our times that is suffering the same fate: Software-Defined.
Rare though buzz-adjectives may be among the pantheon of buzz-nouns and the occasional buzz-verb, Software-Defined (SD) has become remarkably pervasive. In fact, it ties together many different, quite disparate concepts into what has become a vague mishmash.
It’s time to bring some clarity into the big picture of SD – what it is, and perhaps even more importantly, what it is not.
The Many Uses of Software-Defined
The most concrete use of the SD adjective is perhaps in the phrase Software-Defined Networking (SDN). SDN separates network equipment’s control plane (where routing instructions and other metadata go) from the data plane (where the data being routed go), and then shifts the entire control plane to centralized software.
The network, however, is only the beginning. We have SD infrastructure (SDI), SD data centers (SDDCs), SD wide-area networking (SD-WAN), and more. Each of these approaches follows the lead of SDN, shifting control of various pieces of hardware (or virtualized hardware) to centralized, software-based management and configuration applications.
SDI (which includes SDN), in fact, is at the core of cloud computing. Clearly, there’s no way to scale a cloud data center if people had to run from server to server making changes.
Furthermore, Network Functions Virtualization (NFV) from the telco world also falls under the SD banner. With NFV, telco service providers shift all control to software, so that the underlying hardware is entirely generic. No more dedicated switches, routers, and specialized telco gear – all the hardware consist of generic, white-label boxes.
Software-Defined: Beyond the Network
While the network-centric context of SD in corporate networks, cloud data centers, and telco infrastructure forms the home base of the SD movement, SDI is also an essential enabler of continuous integration and continuous delivery (CI/CD), core elements of DevOps.
In order to achieve the velocity that CI/CD promise, the ops part of the story must be SD. Instead of ops people managing servers individually, the DevOps team must be able to deploy and manage software automatically via centralized software control. In other words, the immutable infrastructure principle behind DevOps is nothing more than SDI.
In fact, now that virtualization has matured, all the infrastructure from hypervisors down to bare metal is SD.
At the application level, however, the SD story gets more complicated.
Using software to automate the tasks involved in deploying software is nothing new. Developers have been using runbooks for years – scripts that tell various parts of the environment to execute a series of tasks in a particular sequence.
As DevOps has matured, the notion of the mundane runbook has taken on new life, as DevOps vendors automate increasingly broad swaths of the software development lifecycle (SDLC) with ‘recipes’ or other scripting approaches.
As applications and the environments they run in get more complicated, however, the world of DevOps automation finds itself in a Catch-22: the automation scripts or recipes themselves become increasingly complex software applications in their own right, and thus must go through an SDLC of their own, with all the testing and governance that go along with it.
As a result, we’re back to square one, manually creating, managing, deploying, and versioning software.
Does Software-Defined Mean Declarative?
To address this Catch-22, some DevOps tools take a declarative approach. Instead of scripting the environment step by step, the declarative approach enables the user to describe the desired behavior, and then the tool interprets such a description and takes the necessary actions to implement such behavior out of sight of the user.
In fact, in many contexts, when most vendors say SD, they really mean that they take a declarative approach, separating configuration from the underlying implementation. There’s more to SD behavior than simply following a declarative approach, however.
For example, HTML (and markup languages in general) are declarative. And while we could certainly hand-code a web page by pecking out HTML, we’re far more likely to use a visual tool for that purpose.
When we build a web site using such a tool, we’re essentially working with models. The model is a visual, configurable representation of the page that the tool can convert into HTML for browsers to render into the page itself for users to view.
In this example, therefore, we have three different ways of thinking about the page: as a visual model, independent of any particular technology implementation of the page; as the HTML markup for that page; and as the action of the browser itself, an application purpose-built to render HTML into visual pages.
Architects and other shrewd readers will recognize the pattern above as being an instance of Model-Driven Architecture (MDA), or its common implementation, Model-Driven Development (MDD).
Does Software-Defined Mean Model-Driven?
MDA is an Object Management Group (OMG) standard for creating metamodels that represent platform-independent models (our visual model, above) and platform-specific models (the HTML markup in the example), as well as an abstracted approach for turning the former into the latter.
Models, especially visual ones, are in broad use today, but MDA and MDD’s best days are behind them. The reason: they didn’t deal as well with change as MDA’s creators had hoped.
In the MDD world, a developer might build a (platform-independent) model of an application in a model-driven tool and then push a button and out would pop the (platform-specific) source code that represented the working application.
However, if developers wanted to subsequently make a change, they would either need to change the model and regenerate and redeploy all the code (an onerous and time-consuming task), or tweak the auto-generated code itself, thus making it inconsistent with the model.
Round-trip tooling that would take tweaked code and automatically update the model – the holy grail of MDD – has proven impractical.
If we combine some of the principles from MDD with the declarative approach, however, we finally see some light at the end of the tunnel. Instead of the code-generating context of MDA reminiscent of CASE tools of yore, the platform-specific representation for a declarative model consists of a metadata representation of a configuration.
In practice, tools that take this approach create such metadata representations in JSON, XML, or a domain-specific language appropriate to the task at hand. Developers occasionally have reason to view such metadata, but rarely if ever have call to monkey with it directly.
Instead, users – who need not be developers – simply make changes in the model, typically via direct interaction with icons or other visual elements, or by selecting appropriate configurations. The underlying platform takes care of the rest.
The Intellyx Take
The round-trip code-generation vision of MDD proved unworkable, but the visual model to declarative metadata representation to immutable deployment vision is in essence what SD is all about.
The secret to making this approach practical, and thus the key to understanding why SD approaches have become so prevalent, is the word immutable.
Once we get an SD approach right, we no longer have to touch the deployed technology whatsoever. Instead, to make a change, update the model and redeploy.
The most important takeaway from this Cortex: this core SD pattern is fully generalizable. It works with networks, data centers, DevOps-based deployments, and as I’ll cover in part two, it’s also at the core of the Low-Code/No-Code movement.
It’s no wonder, therefore, that Software-Defined Everything (SDX) is rising to the top of the buzzword heap – but SDX is no mere buzzword. It describes the central technological principles behind Agile Digital Transformation.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Tim Adams.
Comments