Skip to content →

APIs and the “Technology Mix”

Today I would like to recall a really nice conference I saw last January: “Infrastructure in the Cloud Era”. This presentation was performed at O'Reilly Velocity Conference 2009 by Adam Jacob (Co-Founder at OpsCode) and Ezra Zygmuntowicz (Co-Founder at EngineYard).

They cover the theory of how you should be thinking about building a Fully Automated Infrastructure classifying their analysis in the following areas:

  • Bootstrapping: Corporate Approvals, Agile Approvals, Cloud.
  • Configuration: Manual, Ad-Hoc, Infrastructure as Code.
  • Command and Control: Manual, Ad-Hoc, Framework.

They conclude, in the context of a Cloud Infrastructures, that the appropriate way to answer the issues an challenges on each of these categories is: Cloud (IaaS), Infrastructure as Code and a Framework for Command and Control.

There exist a clear positioning around Open Source on the hole talk. In fact, they mainly propose Open Source Tools for an Open Source Environment:

“You need an API is the underlying message. You need an API to cover these three layers and manage your Infrastructure as a hole.

They mention more tools that you can find on the OSS ecosystem like Fabric and Func. I can't remember if they were pointed out, but, depending on your particular scenario, you could also consider a few more: Cobbler, Augeas, Eucalyptus, Nebula, oVirt/libvirt, etc.

Nevertheless, I missed a wider market perspective: beyond the Open Source solutions there is much more. In my opinion, openness is important, may be key in some situations. But, I consider the Technology Mix a more relevant factor. A Mix that delivers economic value: Productivity, Sustainability, Dependability, Security and Global Life Cycle alignment. May be the Technology Mix that matches these Strategic Goals is a combination of Commercial and Open Source Software.

I do agree with the main messages: IaaS, Infrastructure as Code, a Framework for command and Control and  an API to glue it all. But, the fact is that standards make solutions sustainable. Unfortunately, each of these tools (and many others) have different degrees of Maturity, and Life Cycle Uncertainty. This is also true for some Commercial alternatives as for certain current Cloud propositions.

To make things even “better”, Technology is not the only player in this game: the Human Factor and Complexity Levels are key. Complexity determines the expertise required; how much does it cost you to cope with Asynchronous-and-Diverse Waves of Changes over time and how easy is to bring together Technology and People to the next step, whenever is needed. Here, again, is where I return to my previous thinking:  the Big Game is about a Technology Mix that matches these Strategic Goals and not about solutions because they are “Open” or “Fun”.

Of course, how do we care about these concerns heavily depends on our role on the Cloud Market: Consumers, Integrators, Services Providers, etc. As Consumers and Integrators we need to be ready to switch from one Cloud Supplier to another as quickly as we joined to the first one. So, if we care about Managing our Risks, then we care about Architecture, Implementation and so forth. Welcome, again, to the “Technology Mix” way of thinking… ;-)

Anyway, this is a terrific debate and this is a great conference. I wish you enjoy it as much as I did. Have fun! :D

APIs and the “Technology Mix” by Carlos Veira Lorenzo is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Published in Architecture Automation IT Infrastructure System Management Technology