This post is one of a series of previews of companies presenting at Cloud Field Day 3, an invitation-only event in Silicon Valley, taking place 4-6 April 2018.  For more information, see the dedicated CFD3 events page https://blog.architecting.it/events/cloud-field-day-3/.

When processes get too complex and time-consuming, there’s a temptation to stick in another layer of abstraction and paper over the cracks as a way to increase productivity.  I’ve seen this happen many times in my work experience, with both positive and negative results.  Storage virtualisation was one idea that was meant to make it easier to abstract physical from logical resources.  I’ve seen organisations use products like IBM SVC (Spectrum Virtualise) to create a mess of confusion that would rival a game of KerPlunk for the unexpected consequences of making changes.  As a Systems Programmer, I implemented Netview, which for new operators, removed their understanding of how to answer basic console messages.  When Netview fails, the operators don’t always know how best to respond.

Now, I’m not saying automation or abstraction are bad things.  Done right, automation tools remove the administrative burden from highly paid developers who should be focusing on the software being developed, rather than the infrastructure supporting the development process.  The questions to ask are both how and why automation is being implemented.

Morpheus

And so we lead on to the discussion of Morpheus Data (or simply Morpheus from now on).  The company was formed as a spin-out of an internal team inside Bertram Capital, a US private equity firm based in California.  Bertram Labs developed a cloud management platform in 2010 to provide DevOps functionality to the company across a range of heterogeneous cloud environments.  This resulted in the launch of the Morpheus start-up in 2015, now with eight years of experience in the market and some interesting customers such as McDonalds and HSBC.

So what does the company actually do?  As the graphic here shows, quite a lot.  Effectively, the Morpheus platform offers end-to-end management and deployment of applications in a DevOps model, covering components like discovery (what am I deploying, what is my infrastructure), through designing templates and policies for application deployment (governance) to implementing features such as scaling and migration.

Abstraction to Complication

With such a large set of features, two inevitable issues arise.  The first is one of complication.  A solution like Morpheus will touch so many areas and introduce huge numbers of dependencies that have to be understood and managed.  The risk with bringing in such a centralised infrastructure is one of the tail wagging the dog; keeping up with the dependencies of the Morpheus platform may require constant infrastructure upgrades and patching for little benefit than keeping up with the platform itself.  On the opposite side of that coin, upgrades to core infrastructure might be delayed due to lack of support in the platform.

The second issue is one of understanding.  This level of abstraction requires rigid discipline to maintain good practices around deployment, standards, naming, tracking against ownership, object lifetimes and so on.  Without someone (or a team of people) focused on standards enforcement, the result can be another amorphous mess that solves nothing.  IT organisations may need to deploy this kind of software using “super architects” that have the ability view the infrastructure at both a high and detailed level.

The Architect’s View

I’m looking forward to digging into the Morpheus technology, as I’ve already had a little taster on the company from Brad Parks, formerly of HPE and VP of Marketing and Business Development at Morpheus.  Brad and I managed to catch up at AWS Re:Invent last year in Las Vegas.  What specifically would I like to see?  Perhaps how the Morpheus platform can have so many touch points without impacting existing operations and how design, implementation and upgrading are managed.  I am an infrastructure guy, after all.

Comments are always welcome; please read our Comments Policy first.  If you have any related links of interest, please feel free to add them as a comment for consideration.  

Copyright (c) 2007-2018 – Post #E614 – Chris M Evans, first published on http://blog.architecting.it, do not reproduce without permission.

Written by Chris Evans