#DevOps
Architectural debt is incurred when you don't consider the implications of your choices today on your needs of tomorrow
For those who don't recall (and can't bear to leave this post to consume it) let me sum up: architectural debt is the costs (the interest) incurred by architectural choices in the network over time. That includes things like operational overhead, licensing, downtime due to maintenance and patching, etc... That's not counting the impact on future choices which can be significantly impacted by architectural decisions today.
With that in mind, and with the reality of software-defined technologies breathing down our throats, let's consider carefully the methods by which we are going to automate and orchestrate our networks. Because the choice matters, a lot more than you might think.
There are two ways to view infrastructure as code. The first is through the lens of the scripts and code that drive infrastructure provisioning and configuration via an API. The "code" are the scripts or programs built that use the API to provision and configure network services. The second lens is through scripts and programs that push configuration files to various pieces of infrastructure. It may be the case that the infrastructure is not API-enabled (I know, right? How crazy is that?) or maybe the guys who manage the infrastructure aren't quite ready to jump feet first into the wonderful world of RESTful APIs and HTTP status codes.
Both are equally viable means of configuring devices automatically.
One, however, will incur more architectural debt than the other.
APIs are designed to provide remote, programmatic access to configuration, yes. But they also serve as an abstraction layer; a layer that sits between what you want to do and how it's actually implemented. Ostensibly this offers protection against changes wrought by upgrades or patches that change the way the configuration "under the hood." When implemented and supported correctly, APIs insulate external scripts and programs and any other integrated system from changes that happen internal to the device.
This is not always the case with configuration files distributed via scripts. Configuration files often change from version to version, some so dramatically as to render them incompatible with previous versions. Configuration files can't easily be separated out into discrete groups of functionality, to be scripted individually as one might do with an API. Instead, configuration files must be merged and compared and carefully controlled to ensure all necessary changes are included. Changes to the configuration file still occur manually, with all the associated risk of fat fingering a directive and causing downtime. It's just the "push" that's automated, which isn't really the bulk of the time spent on the task in the first place.
Automating with scripts that push configuration to a device incur a larger share of architectural debt than do APIs. APIs enable greater flexibility in how individual tasks are broken up (and executed) and allow for reuse of scripts that perform discrete tasks across multiple provisioning processes. Consistency and predictability become second nature when the same script using the same steps is used to provision and configure some task. Repeatability of that process becomes a given.
Automation and orchestration of the data center, driving toward some ephemeral "software defined" model, are just really starting to pick up steam. The choices you make today with respect to that architecture will have a significant impact on your future capabilities as well as how deep in debt you will end up.