If you are one of those organisations that run any sort of middleware like JBoss / Wildfly, WebLogic, Tomcat, WebSphere, etc. (either on-prem, IaaS, EC2, Azure, wherever) you will have invested in a Continuous Integration/Continuous Delivery tool to support your development and operations.  And if you have, there’s a good chance this includes Jenkins.

Jenkins is almost certainly the most widely used CI/CD tool with 70% of the market share in the space (https://goo.gl/5Cnt2f) – this is not an accident, it’s a tool that does its job excellently.  I’m sure you’re aware the name Jenkins is supposed to give the impression of a servant or butler (slightly less well known is the fact that it came originally from the butler in Scooby Doo -(https://goo.gl/BXCPGi)


This name is perfect – it describes the function.  Jenkins works tirelessly for you, performing those essential tasks in exactly the way you define, over and over and only comes back to you when something out of the ordinary happens.  Freeing you up to sip Cognac in front of the fire.

However, this tool cannot be used in isolation, a full DevOps solution must contain many facets – source control, an artefact repository, and infrastructure / configuration as code (You will also have needed to do some people/process change, but that’s a blog for another day).

Jenkins is also a bit of a multi-purpose beast, there are well over 1000 official plugins (and at least as many unofficial ones) to do all sorts of clever things – like configuration management.  There are Jenkins plugins that will allow you to perform some limited configurations of the most popular middleware, but using Jenkins to perform your configuration management is like asking your butler to do the gardening.  Sure, he might be able to do it, but it would take him longer, he wouldn’t make a great job of it, it would distract from his regular duties and you’d probably have to get involved way more than you should need to.

So, where you have CI/CD requirements, Jenkins is your man – he will run jobs, perform rollbacks if necessary and report on the health of your builds and deployments.  But where you have configuration management, environment build-outs and artifact deployment requirements, it’s always better to use a tool specifically designed for the job.

Talos is a middleware configuration management tool which lets you discover or create middleware in your environment, maintains configuration across multiple environments, allows you to compare environments and ensure consistency, stores your infrastructure and configuration as code, as well as providing features for translating to different middlewares and creating container images.  And does all this with deep integration with Jenkins, so when you create or discover a middleware in Talos, a Jenkins job is created which allows you to act upon that environment (build, rebuild, configure, deploy) in a standardised way.  This will reduce release/deployment times and allow more frequent deployments, allow you to create new environments or scale existing environments more quickly, reduce error rates in build/deployment and reduce overall cost of change.

Jenkins is great, but pair it with Talos and your estate will be managed by two of the best servants in the business.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: