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

  • Very clear bro
    Anyway, some things doesn’t fit my brain at this times… I should go to bed
    Tomorrow I’ll see the video and make additional comments
    Goodnite

  • Carlos:

    Extremelly interesting post… lots of things to think. The idea of the Technology Mix is a powerful one. And Human Factors should be taken into account, as you say.

    I think we’re living interesting times, with changes that are making us to question established technologies (i.e., all the NoSQL debate). Many things could be ending being crap, but the ones that survive could shape Enterprise Architecture in the following years.

    As an OSS advocate, I think that the advantege of these solutions is one of agility. Commercial Enterprise Software are more risk-averse, and they tend to experiment a lot less.

    All in all, I think that we need to have a clear, evolving global view. That will be our main challenge in the next years.

    • Hi Tino :D

      It’s a pleasure to read you here!

      I am also an OSS advocate: one of those trying to give something back to the community. Being an “outsider” (sort of OSS + M$ advocate) is not an easy job :P.

      I do believe that “all this” belongs to a collective learning process. The whole ecosystem evolves with everyone’s interactions and learnings.

      Even the “Technology Mix” concept is not an static one: could mean different things in whatever combination of time, space and actors.

      I do agree with you: we are living key changes. Let’s see if we can perceive, adapt, anticipate, … How to deal with the “there is no spoon” and be ready for it. :D

      As Ken Robinson states: we need to be prepared to be wrong inside a culture that refuses failure… Definitely, no everything will be about Technology… :D