Microservices, Docker and the Death of the Workflow Tool

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!

Related Posts

Leave a Comment

Your email address will not be published. Required fields are marked *