More On Cloud Middleware
Sinclair’s recent post Cloud Middleware: The Language Shared by Network Engineers and Developers posits that the cloud space has seemingly maintained a bias towards infrastructure offerings (IaaS) and is now at an “inflection point” where a common layer – the cloud middleware layer – will be required by developers and network managers alike to, as Jeff Kaplan puts it: Bridge the Great Divide in Cloud Computing. I’d like to expand on this theme.
I help ISVs with their plans to move to the cloud every day. I work with dedicated SaaS teams made up of developers writing code simultaneously with IT staff planning for app rollouts and operations. I’m fortunate in that they’ve chosen SaaSGrid as cloud middleware, and as such, have already chosen to bridge the “great divide” for their project. However, what I find very interesting in particular, is how keen ISVs are to avoid making permanent decisions when it comes to infrastructure and hosting – especially early on in the project. ISVs habitually tackle “easier“ problems first, and familiarity on the development side means that their developers take on the role of the hare, while IT staff takes a slow and more calculated tortoise-like approach. ISVs I’ve worked with spend a disproportionately large amount of time laboring over the specifics of the infrastructure on which their app(s) will run, even while their development teams move forward swiftly. Developers are eager to get rolling, while network managers maintain furled brows. It makes sense when you think about it – they’ve all been a part of software companies that know their specific problem domain well. Developers are already comfortable innovating in their space, the cloud is just a new arena. Where experience fails these ISVs, and where they become overly thoughtful and even guarded, is in deciding how to become a service provider – how to host an application as a service.
The tendency for ISVs to think of development and deployment serially (“Keep writing code, we’ll know how to deploy it by the time it’s ready”), exposes them to costly deploy-time unknowns. Allowing this disconnect starts a technical debt timer that runs the course of their project’s development phase. I’m not saying that ISVs should accelerate their decisions on infrastructure to match the speed at which they develop – I’m saying that they need a buffer in the form of linkage between development and deployment that is present from day one of their project.
Unfortunately, across the industry this is also currently where they experience the largest gap. The trouble with many current cloud offerings and managed hosting services is that they require host apps to speak their language. Or, worse yet, they require the host apps to maintain knowledge of the cloud infrastructure itself – “Which hypervisor am I running on?” is not a question an application should have to ask at any point in it’s development or production lifespan; and 99% of the time it’s an unanswerable question on day one. These requirements just add to the pile of work already on ISVs’ plates and essentially require that they make awkwardly timed deployment decisions (which they are hesitant about) at the onset of their project’s development. And while some ISVs can manage (and maybe afford) the added workload, there is still a lingering trepidation – a hesitance to commit. Most likely the fear is that baking infrastructure knowledge into application code hinders portability and removes any agility. In response, I find many teams asking these cloud providers and even their own IT personnel “Why can’t the infrastructure speak my language?” As Sinclair points out, the answer lies in a common layer, a way for application architecture (developers) and infrastructure (network ops) to speak a common language; a way for the two largest pieces of a SaaS project to move forward in unison – this is cloud middleware.
Becoming a successful service provider mandates a symbiosis between application architecture and hosting infrastructure – but that doesn’t mean developers need to learn infrastructure or IT staff must learn architecture. Instead, we have technologies such as SaaSGrid to “bridge the great divide”.
If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!