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
Jun 10, 2021

Desilo DevOps: The power of bringing all your tools and data into one view

DevOps
When discussing value stream management (VSM), our resources talk a lo ...
Read More
Jun 07, 2021

"How do I get started?" Key steps to improving your end-to-end DevOps process

DevOps
There is an extraordinary variety of DevOps solutions available on the ...
Read More
May 24, 2021

Integrate your DevOps toolchain, simplify your life

DevOps
Organizations can view the entirety of the tools and platforms they us ...
Read More
May 17, 2021

Why Companies in Competitive Industries Adjusted Better During COVID-19

DevOps
As we continue to assess the dramatic effects of the global COVID-19 p ...
Read More
Contact Us