Philip Leaper, a Talos product developer for Tech Data chats to Ajay Amrite about developing Talos toolkits.
Talos is a really effective tool for managing middleware configurations for WebSphere Application Server, Tomcat, WildFly, F5 Big IP, and many more. It is also a framework that can be built upon and extended by anyone who sees an opportunity to create something that adds value to their customers and others in the software development community.
Arqino studios are one of our technology and reseller partners. They have extensive experience in WebSphere MQ and saw an opportunity in Talos to create something that would make the lives of their customers much easier. To talk about how they went about creating their own Talos toolkits, I sat down with the architect Ajay Amrite. . .
PL - Could you just tell me about yourself?
AA - Ajay Amrite – Co-founder of Arqino Studio, dealing with architecture and product development.
PL - So what was the main driver for creating the MQ toolkit for Talos?
AA - I think it’s fair to say that IBM WebSphere MQ is one of the most successful pieces of enterprise software in history. Lots of versions are in use in many financial institutions and different places. Obviously as new versions come along, older versions are going out of support, so one of the biggest challenges to IT infrastructure is how do you migrate the older versions to the newer ones and how do you support people using older versions. I guess that’s where the Talos MQ Toolkit was born – in helping organisations migrate from one version of MQ to another. Also IT departments have requirements to replicate reference configuration, repeated in different environments – Dev, Test, UAT,Production, etc – here the MQ toolkit is going to be helpful also.
PL - So you saw opportunities to create something within Talos that didn’t exist elsewhere or that could be done better?
AA -Yes, so there are tools available like IBM UrbanCode, but with that you need to write everything for your migration and deployments. With Talos everything is built in to the toolkit itself and it integrates with other DevOps tools like Jenkins, Ansible and even IBM UrbanCode itself. All that integration is taken care of by the Talos platform and the toolkit provides components just specific to MQ. Similarly there are other toolkits for WAS, DataPower, etc. Typically, in an enterprise you won’t just have one middleware, you will have a suite that you need to manage. Talos lets you manage each of these in a normalised way.
PL - So when did you start looking at Talos toolkit development, and then when was it you started in anger in creating the MQ toolkit?
AA - So we got to know about Talos around two years ago, and since we have a lot of expertise in MQ and the integration space, that’s when we decided to take on the task of building the toolkits for MQ and IBM Integration Bus (IIB). For the moment we are focusing on MQ, as MQ 7.5 is going out of support very soon. Many clients will be trying to migrate from MQ 7.5, probably to MQ 9, the latest version.
PL - So what’s the ROI timescale do you imagine? How long before you get back what you’ve invested so far?
AA - We’re hoping for the first quarter next year. We host regular workshops, the next one is in fact on Wednesday 20th September. “How to migrate from MQ 7.5 to a newer version?”. We hope that September’s workshop leads to one sale, of say 10 licenses. If that happens within the next 6 months, we’ll have our investment back.
PL - And what would you say is the biggest driver for companies to adopt the MQ toolkit? Is it time saving, resource reduction, reducing human-error?
AA - Well, yes, all of those really. One thing the MQ toolkit borrows from Talos is that it gives you a uniform view and a similar UI for all toolkits, whether you’re dealing with WAS or MQ or IIB there’s no learning curve for the users to learn one thing for MQ, something else for WAS, etc. And so you have a single environment for all products – most likely if you have a Dev environment, it’s going to contain WAS, MQ, DataPower and you’ll need the same stack in UAT and Production – Talos handles all of that for you in the same product.
AA - Another advantage is in the templating, so when you move from one environment to another you may want to change values for certain variables port numbers for listeners, passwords, sizes of queues, things like that. All these are values that might change from one environment to another. Templating allows you to select these values and easily populate the new values in another environment.
PL - So, can we dive into the toolkit a little, how does it work? Can you walk through it?
AA - So the way it works is that the Toolkit asks basic questions about the infrastructure – things that you would expect administrators to know off the top of their heads – the IP address or hostname, standard installation paths, username and password for connection, etc. Then the toolkit establishes an SSH connection to the target machine – as a platform. Talos transfers some of the code on to the target machine, it runs some activities to gather information about the target machine and any configuration details and then transfers it back to the server.
PL - Right, so it connects using SSH and pulls back topological information, in terms of getting the actual configuration, what’s happening there?
AA - It uses standard WebSphere MQ APIs provided by IBM, so it’s not anything proprietary. We’re just managing and maintaining a set of scripts, so users don’t have to. Sometimes we use command line commands as well to gather more information. Once it’s in the UI, then we can create templates. For example if you need to change a port number for a target server, you just create or update that template and add to the target middleware. Talos can take care of updating the values.
AA - Many of these things are demonstrated in the workshops we run – it’s easier to show than to explain. There’s going to be a hands-on lab where the users can walk through an example of moving configuration from one system to another.
PL - And did you hit any challenges in the creation of the toolkit?
AA - Not really, it’s quite straightforward to build the toolkit, probably the biggest challenge has been in finding the people and time to test it and make sure it’s bulletproof. There was a lot of time spent finding the information from IBM websites and documentation to programmatically do all the things we wanted to. Also because we are dealing with so many different versions – the main aim being to be able to migrate between versions – we might be talking about differing Java versions too. Ensuring it worked migrating between all these different versions, in different configurations, took a lot of time.
PL - Yeah, so finding all those mappings between different versions where perhaps an API changes or there are some other differences?
AA - Yes exactly – there are some configurations for example that aren’t there in 7.5, but are in 9. So we had to find clever ways of dealing with those kind of differences.
PL - And what about the structure of a toolkit in general, is it pretty intuitive, easy to understand? You have to create UI elements, Groovy-based activities, logic for the read and write of configuration – is all of that well laid out for a developer?
AA - Yeah, so like with everything, there is a bit of a learning curve, but once you have it then it’s really logical and intuitive. You just start small and gradually build more and more on top of it. All the other toolkits work in the same way, so you can always reference the other toolkits for inspiration.
PL - OK, and were you able to obtain support from the guys at TechData for anything that wasn’t immediately obvious?
AA - Yes, absolutely – we were working closely with a couple of developers who provided great support both from an architectural and deep-coding point of view. Generally we didn’t have to wait more than half an hour or so to get an answer to a question.
PL - Obviously in the process of development you never get to 100% immediately, you aim for a kind of 80% mark and go from there, with the rest being addressed in bugs / requests. So how long did it take to reach something that was good enough for a public release?
AA - One of the struggles we have had with this toolkit is having several people working on it while conducting their day jobs at the same time and keeping them synced up. Probably – in terms of elapsed time - most of the year, but in terms of man hours, maybe 3 months.
PL - And finally, what tools did you use for development and testing?
AA - Mainly Eclipse – that’s our IDE of choice – and Maven for building the toolkit. As for testing, Virtualbox (because it’s readily available and free) – if we needed to get a package over to a client for testing or demo, we could package up a VM and send it over. Ubuntu was the OS we used primarily, but it works on other flavours of Linux.
PL – Thanks very much for your time and good luck with the next workshop, I hope it goes really well and there are many happy customers in the future.
For more information about Talos MQ and any other toolkits, get in touch with the team at firstname.lastname@example.org