DevOps Orchestration – the Morpheus tool integration platform looks interesting

I’m a huge believer in DevOps – or, rather, Biz-Dev-Ops – and the removal of silos between Business, Development and Operations. This is fundamental, I think, to the operation of a constantly-evolving mutable business – which needs an efficient, very timely, feedback loop from business and customer expectations to the design of business automation (not just between coding and delivery).

Key to this is the automation of software and service delivery and deployment. This automation is, in essence, the coding of the software and service delivery processes – linking together all the tools you use with software APIs – giving you a “software-defined infrastructure”. There are, however, at least 3 potential issues to worry about:

  1. The automation code for tool orchestration has the same quality requirements as any other code. If you code DevOps orchestration as unmaintainable spaghetti code, your DevOps initiative will slow down, become error-prone and, eventually, fail;
  2. This orchestration coding can be non-trivial and, in particular, not all tool APIs are equally high-quality. The business of an organisation is usually in the building of automated business outcomes, not in being expert in tool integration and automation;
  3. There are few greenfield sites left. DevOps is a journey from what you have now, which is presumably good enough (and liked well enough by your customers) to a software-defined nirvana. It is important that you don’t compromise service levels, and perhaps even go out of business, on the journey.

What these issues mean, in general, is that trying to do it all yourself is a high-risk strategy – and a distraction from your business objectives. So, I was interested to come across Morpheus, which is a DevOps tool orchestration platform, supporting over 75 third-party tools with one out-of-the-box automation engine. It supports self-service provisioning for developers, and claims to accelerate application deployments by orders of magnitude.

It is more than just a glue to hold tools together. It lets you visualise your operational development-to-deployment processes on paper, for continual improvement, before you risk impacting the operation of the business. Continual improvement is a key to DevOps maturity.

Morpheus doesn’t force you to rip out any tools people are already using effectively, so it supports vital configuration management tools such as Chef, SaltStack, Ansible, or Puppet (Morpheus gives you, in addition, fine-grained role-based access to cloud provisioning, networking configuration, monitoring, scaling, and so on).

It’s most recent press release announces expanded integrations for VMware NSX, Zerto, Ansible Tower, and so on. So, Morpheus isn’t standing still.

An AstraZeneca case study suggests that Morpheus scales well (as AstraZeneca has more than 16,000 virtual and physical servers and 2,700 applications across 27 global locations):

Today, Morpheus automatically orchestrates every ServiceNow user request across AstraZeneca’s compliance, networking, access, quality and control, operations and capacity management tools and platforms. Server builds are fully automated and standardized across on-premises and public clouds. The entire service delivery process takes a mere 27 minutes with the previous, labor-intensive manual process having been replaced by a few automated steps available from a SysAdmin friendly GUI or a Developer friendly API.”

Overall, I liked Morpheus. According to Brad Parks (its VP of Marketing and Business Development), it’s based on four pillars:

  1. Visibility/discovery (so that you can find what tools you are currently using and may not know about);
  2. Governance guard rails (so you can demonstrate your control to all of your DevOps stakeholders); and software tool orchestration (which implies fewer mistakes and re-use of process);
  3. Monitoring (so you know how you are doing – “no surprises”); and,
  4. Continual improvement (the key to maturity).

There are alternatives to Morpheus, of course, but people should make sure that they address all of these four areas – you certainly can’t run DevOps effectively with just manual tool invocation, but automated chaos (with multiple different, and hand-maintained, scripts) is not a good alternative.

David Norfolk

My current main client is Bloor Research International, where I am Practice Leader with responsibility for Development and Governance. I am also Executive Editor (on a freelance basis) for Croner's IT Policy and Procedures (a part-work on IT policies). I am also on the committee of the BCS Configuration Management Specialist Group (BCS-CMSG). I became Associate Editor with The Register online magazine – a courtesy title as I write on a freelance basis – in 2005. Register Developer, a spin-off title, started at the end of 2005, and I was launch editor for this (with Martin Banks). I helped plan, document and photograph the CMMI Made Practical conference at the IoD, London in 2005 (http://ww.cmminews.com). I have also written many research reports including one on IT Governance for Thorogood. I was freelance Co-Editor (and part owner) of Application Development Advisor (a magazine, www.appdevadvisor.co.uk, now defunct) for several years. Before I became a journalist in 1992, I worked for Swiss Bank Corporation (SBC). At various times I was responsible for Systems Development Method for the London operation, the Technical Risk Management framework in Internal Control, and was Network Manager for Corporate group. I carried out a major risk evaluation for PC systems connecting across the Bank’s perimeter to external systems and prioritised major security issues for resolution by the Bank’s top management in London. I also formulated a Security Policy for London Branch and designed a secure NetWare network for the Personnel Dept. Before 1988 I was an Advisory Systems Engineer in Bank of America, Croydon in database administration (DBA). on COBOL-based IMS business systems. Before 1982, I worked in the Australian Public Service, first as a DBA in the Dept of Health (responsible for IMS mainframe systems) and latterly as a Senior Rserach Officer 2 in the Bureau of Transport Economics. Specialties: I have the ability to extract the essence of significant technical developments and present it for general consumption, at various levels, without compromising the underlying technical truth.

Have Your Say: