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

Lori MacVittie

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

Related Topics: DevOps Journal

Blog Post

Automating with APIs vs Scripted Configuration Pushes | @DevOpsSummit [#DevOps]

Architectural debt is the costs (the interest) incurred by architectural choices in the network over time

DevOps: Automating with APIs vs Scripted Configuration Pushes

Architectural debt is incurred when you don't consider the implications of your choices today on your needs of tomorrow

You may recall a previous post which discussed the notion of architectural debt incurred by the network being a significant contributor to the reality that the bulk of IT budgets are spent just keeping the lights on.

Register For DevOps Summit FREE (before Friday) ▸ Here

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.

arch-debtWith 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.

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.