Skip to main content
DevOps Image

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

DevOps

workflow-is-a-floppy
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!
Footnotes
  1. Stay tuned for a bunch of related features in upcoming versions of XL Release and XL Deploy!

More from the Blog

View more
Mar 04, 2021

Getting key stakeholder buy-in for changes perceived as risky

DevOps
Organizational leaders must recognize that change is vital for the sur ...
Read More
Mar 01, 2021

Discover the change management practices that are ripe for optimization

DevOps
Change has become the most important part of modern digital product cr ...
Read More
Feb 22, 2021

Reckoning DevOps’ role in the enterprise value stream

DevOps
If you’re a software or digital solutions company, you may use DevOps ...
Read More
Feb 10, 2021

Customer spotlight: Schneider avoiding bumps in the road with DevOps adoption

DevOps
Everyone wants to deliver software faster and more reliably. Companies ...
Read More
Contact Us