This post is from the XebiaLabs blog and has not been updated since the original publish date.
Why a Workflow Approach Doesn't Cut It
One of the most popular features of XL Deploy is its model-based approach, which focuses on the components you want to deploy. Most other deployment automation tools use a workflow-based approach, which focuses on defining the steps you need to execute in order to deploy the components.
In XL Deploy, you describe the object you want to deploy, be it web content, files, or a web application. You separately describe the environment. Once you model the components, you only need to specify what you want to deploy and where, at the highest level. XL Deploy calculates for you the mapping of your components, the ordering (orchestration) and any additional steps (for example, restarts) based on industry best practices.
If you make a change to a component or environment, that change automatically propagates to everything in the plan. Scaling, therefore, happens automatically. Add a new target, and XL Deploy generates the plan accordingly, but now with the additional steps included. Unlike workflow-based tools, with XL Deploy, you don’t need to search (within your deployment logic) for where to account for this new target and then duplicate the logic to deploy to it.
Why Workflow-based Deployments Don't WorkA XebiaLabs’ customer evaluated a workflow-based deployment automation tool from a large enterprise vendor before they implemented XL Deploy. According to the company's CEO, however, "even heavy discounts didn’t outweigh some significant deficiencies.” He went on to describe the issues:
- Workflow approach is inadequate: "The workflow approach [vs. XL Deploy’s model-based approach] is powerful, but it doesn’t quite do what we want. It looks good on the surface but doesn’t go far enough. So you either need to extend the components – which is complicated – or write a script anyway…which rather negates the purpose of the tool."
- Difficult to change and a maintenance nightmare: "You get wrapped up in the workflow if you try to change it, add a new step, etc. – a regular maintenance nightmare! The more you try to use the available workflow structure, the less it seems to be of any value."
- Insufficient support for microservices architectures: "The tool we looked at does some sort of microservices dependency management, but the process is horrific. Every time you add a new node to an existing microservice, there’s a lot to do."
- Too complex: "Not only was the workflow definition too complex, but also the deployment of the software. It gets very complicated when you look at how many agents can be implemented at one time."
- Prohibitive licensing: "The vendor of this particular tool wanted to license us to death! Because of the license server, it took a week to deploy and get things working. It’s an awful lot of irritating hassle."
- Over-engineered and not modern enough: "XL Deploy has a more modern roadmap and is following where modern application development is going. The workflow-based tool we looked at is over-engineered so much, I’m not sure how the company can move forward on it."
- Agent-based: "Most deployment automation tools are agent-based, and we do not like deploying agents to our 200 nodes! There’s no good way to deploy to that many hosts with agents. It’s a helluva memory suck even if it’s only taking 20-30 MB each."