Cloud Native Application Architectures Part 1: What infrastructure?

New challenges for the Infrastructure guy

saltnpeppaAs a seasoned Infrastructure Architect (directly contributing to the salt and pepper seasoned hair colour…) I have seen  changes over the years that have impacted on the infrastructure landscape, but I think we are now in the midst of one of the most disruptive periods that I can remember.

Trying to keep track of evolving technology trends, while also trying to see where the organisation I am working for could exploit it, feels a little like the game where you put mundane objects in a bowl of jelly and have to work out what they are whilst blindfolded.  A sort of messy groping game while bystanders throw in helpful (or not) comments from the sidelines.  Eventually you get there but not without looking a bit stupid and getting covered in mess in the meantime.

This post may fall into the mess category!  Having reread the post a couple of times before publishing it occurs to me that sounds like a bit of moan; ‘its hard, everything is different’.  I’m sure that I’m not the only infrastructure guy who is having to readjust to the changing nature of infrastructure provisioning, so this post is as much a cathartic exercise to articulate the challenges that I (and I’m sure others in the same boat) are having.  I’m hoping to create a series of these blogs, I’ve definitely identified three so far and the next couple will certainly be more upbeat in terms of addressing these challenges head on.

Modern Application Architectures

Cloud Native Application (CNA) Architectures and the platforms that are being typically adopted to host them, represent a fundamental shift in terms of designing and deploying infrastructure and platform services.  The name cloud native gives the game away in terms of where they were born.  A new application design approach was required in part due to the fact that in Public cloud providers like AWS you don’t have dedicated VMs, you have instances and those instances may not be available all the time so you cannot rely on the underlying hardware to provide resilience for your applications.  Therefore these distributed applications were ‘built for failure’ so that in the event that any component of the application stack is unavailable, the service is maintained.  Another attribute of a cloud native application is for it to scale in and out on demand, in order to have cost scale in line with actual use, rather than maintain ‘the capacity peak’ as you would have on premise.  This is important because if you move traditional applications to a public cloud provider and the apps can only scale up and not out, then you effectively have to build for peak at an inflated cost and this is where I have seen projects come unstuck as the cost to host this on a public cloud provider becomes cost prohibitive.  There is a lot of noise about micro-service architectures being used as a mechanism for enabling these distributed and highly scalable applications.  I think it would be fair to say that as an architectural pattern it is proving popular, but that it is not the only way to deliver these kinds of applications.  For those interested the 12 factor app is a great place to start reading up on this. 12 factor App.

So the challenge is how do I get from here, to over there, where I’m promised application layer availability, super agile setting-up-new-challengesdelivery and systems that are almost agnostic to the underlying infrastructure platform?.  Take a normal enterprise like the one I work for;  Windows Servers, a smattering of Linux, highly virtualised environment.  Most applications are of the commercial off the shelf variety including the core line of business application.  More of these are moving to SaaS type consumption and hosting models, but a high percentage are installed onto Windows operating systems.  Development typically focuses around integration between applications, with an ESB acting as a broker.  The organisation is starting to apply more rigour to the integration, removing tightly coupled integration and adopting a loosely coupled API centric model.  This is not that unusual with a lot of organisations that have an IT legacy to manage (or heritage IT as Joe Baguley @ VMware calls it), usually with whole business processes dependent on it.  It is a world away from Cloud Native!.

Infrastructure and Platforms to support this new world

I’ve looked at the infrastructure and platform technologies which play in this space in varying degrees of depth; Private Clouds with commercial software like vCloud Suite, or open software like Openstack,  or a container based technology platform using Docker or Kurbernetes.  From a pure infrastructure perspective there is hardware, with a hypervisor or similar allocating some dedicated resources, some degree of OS either shared or dedicated and then some apps deployed on top, with potentially some management, whether config or monitoring etc.  That is maybe a little over simplified, but the layers are essentially the same across the different stacks.  However there are far more differences than similarities between them, especially when it comes to the right use cases to make best use of them.

Warning-zoneIt has also occurred to me that my infrastructure bias is tempting me to focus on the wrong end of the conundrum.  If it really is all about the application, then I need to understand the applications and why they might favour one hosting platform over another.  So should we be looking at these new platforms and working out how the existing applications fit, or are we building applications for these platforms from scratch to make best use of them.  Moving from traditional models of application architecture design and going cloud native should drive the platform choice and not vice versa.

This is where the juxtaposition between a vendor or expert telling us that the market is moving in a particular direction, versus the inherent inertia that needs to be overcome to engender change in a typical enterprise, is starkest.  It also seems to me that the Infrastructure guys are getting some unfair flak as well.  I am not personally seeing a wholesale shift from developers or development shops suddenly demanding to build their enterprise Line Of Business applications as Cloud Native Architectures.  They are contending with their own traditional 3 tier or MS .net legacy applications that don’t really seem to fit in this new open source public cloud world either.

It seems the best I can do at the moment is grope around in the jelly, take on board the best suggestions of the bystanders and see what I end up 629px-suspend-an-object-in-jello-introwith until I get to take the blindfold off.  Its fair to say that this trend away from infrastructure and towards better understanding the application architecture starts to move me outside my comfort zone, but that is good as we grow when we are stretched.


Part 2 covers my current thinking in terms of a VMware centric view of provisioning the infrastructure and platform services (IaaS & PaaS) to host these new applications.  It relates to the fit for my current organisation and does not necessarily reflect other deployment options or aspirations.  It is VMware biased in nature but for VIO and Photon feel free to substitute your own flavour of Openstack or Container technology.


Share this post:

Leave a Reply

Your email address will not be published.