Beyond the maze of software-defined data center buzzwords, there lies a very important idea: integration -- the concept that all of the discrete parts that make up a data center network shouldn't remain quite so distinct. After years of increasing abstraction at all layers of the stack, we now want our disenfranchised exes -- networking, storage and compute -- to come back together as friends.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The API-as-savior argument is born from our utter dissatisfaction with the state of our network and infrastructure tools.
To get all of the disparate pieces to play nicely together requires a way for them to communicate that obviates the need for heavy-handed, manual intervention by highly skilled minders. We need communication, automation and teamwork … ostensibly with less "team" in the middle of the process. We need open APIs … or so that's been the theory.
APIs allow us to do many things, if they're well written. We can write software to automate movements of storage LUNs or virtual machines, define real-time QoS on network flows, attach policies to applications and servers that are respected by all of the involved systems, or even write our own giant ball-o'-automation for everything we own. But open APIs also require us to have a new level of skill and a massive amount of time to invest in programming and developing.
What's more, while open APIs appear as the answer to many questions in the modern data center network, they are actually the proverbial "42" of the modern IT world. Like the protagonists in Douglas Adams' famous books, we need to know what the question is that we're answering. We need to define what we're trying to accomplish.
Open APIs are great, but vendor cooperation is better
The API-as-savior argument is born from our utter dissatisfaction with the state of our network and infrastructure tools. Search online and you'll find complaints about almost every GUI or CLI from just about every manufacturer. "This GUI doesn't support HTML 5!" says one person. "This GUI isn't available on the operating system I like," says another. Still another tosses out the ever popular, "Real men use the command line." Sound familiar? The belief has become that, if we only had access to the inner workings of all our systems, we could write a better CLI, GUI or suite of automation tools.
More on the software defined data center
Is software-defined data center ready for mainstream?
Software-defined storage: Reality or hype?
The VMware software-defined data center: What's missing?
Is there a downside to software-defined infrastructure?
But even in a perfect world where we all had the skill and time necessary for this kind of programmability, and where all APIs were open, documented and well-written, the level of effort required to unite an entire data center of disparate systems is unfathomably, mind-bogglingly large. This is why we require not just open APIs, but a level of participation and commitment to integration on the part of our vendors.
I think we should demand that manufacturers provide programmatic access to the devices we buy. But the bigger problem we're tackling is one of teamwork and cooperation. We want all of our devices and systems to talk to one another in a way that allows us to ameliorate risk, lower our cost inputs to the business and increase network productivity, but we don't necessarily need to do this work ourselves.
What we need from our vendors is for systems to come off the shelf ready to talk to each other. We need our storage and compute resources to know how to tell our network what they need, and we need our networks to listen. That requires common protocols and tools. But it also requires a will to compete on merit rather than relying on vendor lock-in for future business. That's not about an API.
About the author:
Lifelong and professional network engineer, VMware programmer and Unix geek; whiskey taster; longtime practitioner of the art of beating computer and telecommunications systems into submission; brain hacker; student of everything; cancer survivor; lover of stuff that does stuff, and other stuff; freelance writer. blog.packetqueue.net. @SomeClown