Skip to main content
DevOps icon showing cogs

This post is from the XebiaLabs blog and has not been updated since the original publish date.

Last Updated Nov 20, 2014 — DevOps Expert

Microservices, Docker and the Death of the Workflow Tool


The days of The Big App are over - at least, for the forseeable future. Sure, there will still be tons of large, monolithic beasts around, just as we still tend to our mainframe and keep that COBOL application running, the one with the critical business logic that nobody understands. What we are moving towards, certainly for new systems and also as a migration path for our Big Apps, is a landscape of many lightweight, interdependent components - some in your clouds and datacenters, but more and more increasingly "out there", on mobile devices, in your coffee machine etc. Whether we want to call this SOA, microservices or Internet of Things, doesn't matter from this perspective. Neither is it all that relevant whether the "server-side" components run in Docker, Mesos or some other container technology, or are simply small Jetty-based Java programs, or apps running in a public, private or hybrid PaaS or another yet-to-be-invented runtime. What is essential is that there a) will be many, many components and that b) individually, they will be pretty simple. Simple, especially, to build and deploy. Getting one of these lightweight components running will be pretty trivial: in most cases, a one-line command or API call. This doesn't mean that application deployment complexity goes away, unfortunately - but the nature of the complexity shifts. The challenge is no longer "how do I describe and execute the 10,425 steps that are required to update Big App", it's: "How do I easily deploy 47 components into a landscape of 763 microservices coherently? How do I know which components are dependent on which others? Which running services will be impacted by the new components? Have the new versions of the 47 components actually been tested together? Have they been tested against the versions that are currently in production?" In other words, the complexity moves from the deployment of individual applications to visualizing, predicting and executing changes to a complex graph of interdependent applications1 (In fact, we are simply moving all the challenges we faced with build-time dependency management towards runtime, but that's a subject for a different blog post.) What does this mean? No more and no less than the end of the workflow approach to application deployment. The idea of giving you an enormous canvas because you need tremendous flexibility to put together a process consisting of endless steps in all kinds of combinations and permutations is based entirely on the old reality of The Complex Big App Deployment. In the application landscape we all are moving towards, workflow canvases for the manual design of complicated deployment processes will be about as relevant as a floppy disk drive. Picking a workflow-based app deployment tool today is a choice for instant legacy. Well, at least you'll be able to automate the deployment of that COBOL app!
  1. Stay tuned for a bunch of related features in upcoming versions of XL Release and XL Deploy!

More from the Blog

View more
Ascension Launch Banner
Apr 26, 2022

Get ready for peak performance with’s newest AI-Powered DevOps Platform Ascension Release

Today, is excited to announce our latest AI-Powered DevOps ...
Read More
Jan 24, 2022 Value Stream Delivery for SAFe®: The key to amazing business outcomes

The Scaled Agile Framework (SAFe) is the world’s leading framework for ...
Read More
Dec 09, 2021

How SaaS and cloud-based solutions helped the U.S. Department of Veterans Affairs achieve digital transformation

Modernizing legacy systems was an ongoing goal for the U.S. Department ...
Read More
Nov 29, 2021

Increase velocity and reduce risk with AI and machine learning

Artificial Intelligence (AI) and machine learning (ML) have proven use ...
Read More
Contact Us