Microservices, DevOps, and ITSM for an Antifragile Business

05/03/2017 by: The SunView Team



Microservices are a software architecture that creates antifragile systems by breaking monolithic applications into smaller microservice components and making these small components easy to deploy and robust against failure. Microservice components are also designed to expect, and gracefully handle, the failure of other microservices they depend upon, offering customers a partially-working application rather than a spinning wheel of death or the dreaded HTTP 500 Server Error message.

Coupled with DevOps, microservices can improve the ITIL change, configuration, and release processes, which leads to:

1.Longer mean times between failures

2.Shorter mean times to repair

3.Increases in application feature velocity for competitive advantage.

By combining Microservices with DevOps and adapting IT service management (ITSM) to take advantage of this new architecture and deployment methodology, a business can get the best of all worlds – moving from being an unchanging, robust business to a high velocity, always changing and antifragile business.

What are Microservices?

Perhaps the definitive work on microservices is by Martin Fowler and his excellent article includes this succinct picture which compares microservices to monoliths:


Source: Martin Fowler, Microservices

If you imagine an online banking application as being one, large monolithic application – deployed in one Web application ARchive (WAR) file – the challenge is that to change one function you have to redeploy the whole application (with the associated change control, release process, and availability concerns).

By breaking the monolithic WAR file into using a microservices approach, your banking application functions are separated into separate microservices that each focus on doing one thing well. For instance, one component might represent displaying your balance, another managing payments, and another ordering a new check book. And to change one of these components is a much smaller, and less risky maneuver, than in a monolith.

Learn how ChangeGear supports DevOps and ITIL Change Management.

Microservices, DevOps, and ITSM

Microservices and ITIL come from quite different communities – and ITIL-process-focused service managers will probably have different experience, attitudes, skills, and focus to the software-architecture-focused developer community for microservices.

However, regardless of these community differences, microservices impact ITSM because they change fundamental ITIL processes such as change, configuration, and release management:

  • Changes are made to individual microservices, not the whole service at once. This can mean 24x7 uptime and zero planned maintenance change windows. The service is also up, though it can be partially (and gracefully) degraded.
  • Microservice configurations use “Immutable Infrastructure as Code.” Microservices can be deployed as immutable, “baked” virtual machine images. Maintenance is applied, such as upgrades or patches, by replacing the individual service image and not updating in place.
  • Releases can be made at a much smaller size and much faster velocity. New features can be introduced to gain a competitive edge for online services, or to fix security problems, with just one microservice component.
  • Microservices are designed with disorder in mind. The failure of one component has been designed such that the entire service will continue operating or at least offer the user a graceful degradation in service. There’s no “system down” errors because of one failed component.

Robust vs. Antifragile

ITIL is often perceived as managing robust, mature systems while DevOps is considered to be at the opposite end – managing fragile, naive systems. Rob England – the IT Skeptic – has an excellent visual for this from his SlideShare Kamu: reconciling DevOps and ITSM/ITIL

Source: Rob England, Kamu: reconciling DevOps and ITSM/ITIL

And, from the DevOps community, Jez Humble’s words express things well:

“The problem with robust organizations is that they resist change. They aren’t quickly killed by changes to their environment, but they don’t adapt to them either – they die slowly.”

Finally, the characteristics of these different systems are well summarized by William Yang in Antifragile, Microservices and DevOps – A Study (albeit slightly modified for this blog):








Medieval castle






Attitude to change




Response to change




Rate of change

(Ideally) Never



Change initiator

CEO approval







The Reality Is... You Need Them All Together

Ask a business what it wants and the stakeholders won’t say “ITIL” or “DevOps” or “microservices.” What they will want though is “business value,” “speed,” “availability,” and other non-technical, non-jargon business outcomes.

The reality for those delivering IT and business services today is that they need to consider all available architectures, methods, and frameworks to find the combination that delivers the best business outcomes. And today, this is likely to be a combination of monoliths, microservices, DevOps, and ITIL.

It’s a real mixed bag out there – it’s not ITIL vs. DevOps or microservices vs. monoliths, it’s ITIL *and* DevOps, microservices *and* monoliths.

ITSM Practitioners who are “more SM than IT” will welcome Microservices and DevOps because that combination eliminates a lot of undifferentiated, valueless IT-focused service management whilst at the same time improving business-focused service management outcomes. 

Ready to try ChangeGear for yourself?

Get Started

| DevOps / Change Management