Cloud Management and Code Switching
#devops #cloud Operators will likely need to become polyglots to manage modern architectures
For those of you who've ever lived in a household with non-native language speakers (whatever that native language may be) you probably experienced code-switching.
Code-switching is a linguistics term that refers to the act of switching between two or more languages in a single conversation. It's like starting off the conversation with a greeting in one language, switching to English for most of it, but using elements of the other language throughout the conversation. When our girls were learning English this happened quite frequently, with a sentence often beginning with "осторожный" (careful) and continuing on with an explanation of why some action was dangerous and ending with "ладно" (okay)?
Code-switching generally occurs in a sentence where it grammatically aligns. Thus the use of interjections and stand-alone phrases in one language to get the attention of a child make perfect sense.
CODE-SWITCHING in the DATA CENTER
Right now, if you're managing resources in an on-premise cloud (or traditional data center elements) along with an off-premise (aka public or virtual private) cloud you're probably doing a lot of "code-switching". Not just management systems, mind you, but even the languages used to interface with those systems.
Even if you're not using an off-premise cloud, but simply trying to automate systems in the data center (whether in a cloud or traditional) you may be code-switching as means to automate a process involving one or more data center infrastructure elements, say a firewall, a web server, and a load balancer.
For example, if you're using Apache you might be using Apache ODE, which requires you speak WS-BPEL 2.0 (which further requires you speak SOAP and XML). Your firewall and load balancer likely speak a SOAP/XML variant as well, but increasingly you may be required to speak a REST / JSON dialect to communicate with elements in the network.
Today, more than 73 percent of all APIs listed on the Programmable Web use REST, according to ReadWriteWeb. SOAP, on the other hand, holds a meager 17 percent of Programmable Web APIs.
In order to deploy an application completely you will most likely need to speak a variety of not only languages but dialects, as well. XML is highly flexible and the schemas used with SOAP are quite verbose while those used in conjunction with REST are fairly straightforward and comprising far fewer elements (literally and figuratively speaking).
And that's just three simple network elements in the data center. Add in even one off-premise cloud (and most enterprises are using two or three at this point, when counting SaaS) and the number of languages and dialects required for operators to automate a single deployment process increases significantly.While Amazon supports both SOAP and REST APIs for managing EC2,
The problems arising from this are not only in the skill sets required for operators to engage in devops, but in the maintaining of the tools used to automate the processes across multiple languages and systems. Irrespective of the language - be it RUBY or PERL or PHP - there may be specific libraries or modules required, depending on the version of the language you're using. For example, native XML support in PHP4 was fairly weak, but significantly improved in PHP5. And while RUBY includes XML support, it's noted for being horrendously slow (not an uncommon complaint of XML in general, depending on the size of the XML file and the parsing method used).
In other words, there's going to be a speed-bump somewhere along the way, no matter what directly you go. At some point, you're going to be required to speak another language in order to fully automate some process, somewhere.
This is one of the core arguments supported a standardized framework, for support of some cross-domain, cross-environment "stack" (think OpenStack or CloudStack) that can abstract aware from implementation and provide operators with a consistent means of managing not only network elements but applications and environments, as well.