Home

Wikitip

Application Release Automation - Buy or Build?

Deployment Automation, Application Release Automation (ARA) and DevOps

Application Release Automation, DevOps, Deployment Automation"I spend my life on the road visiting customers talking about Deployment Automation, Application Release Automation (ARA) and DevOps. What has struck me over this time is the belief within many organizations that what they do is unique – that somehow their environments are different to everyone else’s. What I would like to do in this blog is to explore this idea – how much difference is there really between organizations’ IT infrastructures? Should they be so different or are they just trying to do the same thing but in different ways? This is a key question since if organizations are all doing variations on ultimately the same thing then there is a much stronger case to buy a tool that supports this capability out of the box. The market perception has certainly changed in the last eighteen months. Up until this point, as a vendor that provided release automation tooling, we found ourselves predominantly competing against home grown scripted solutions. Today this is much less the case – I would say there are more organizations that accept the need for tooling to address this problem, although I believe at this point the market as yet is not convinced which is the best tool for the job. Your Environments Are the Same as Everyone Else’s!

If I had a dollar for every time I was told “our environments are unique” then I would probably not be writing this blog today. I find it bizarre to say the least that in either a pre-sales or consulting capacity over the last four years or so I have discussed Deployment Automation / ARA with hundreds of customers in Europe, North America and APAC – and often find myself in discussions with sysadmins who have been working at the same organization for years that tell me what they do is unique. I find this bizarre as having worked with so many organizations to apply a manufacturing approach to their middleware, messaging and database automation, what I see is they are all trying to achieve the same thing. They may have some specific security, network, procedural differences, etc. – but how many ways does there need to be to install a product, create a cluster, deploy an application, etc? – And if there are best practices for doing this (which I believe there are) does it mean that many of the bespoke implementations are flawed in themselves? Best Practices for Application Release Automation

The answer I would of course say is that there is a best practice that can be applied to application release automation and very few home grown solutions fit this mould. It is easy to establish a pattern that fits your organization to install WebSphere or MQ or Message Broker or WebLogic or Oracle, etc., etc. Likewise for configuring or deploying Queue Managers, Clusters, web servers, databases, etc. Of course we need to handle the fact that the configuration of these targets will look different – not only between organizations but between the same applications in different environments within an organization. You’re Taking the Fun Out of it…

An unspoken criticism of tools like ours (RapidDeploy) is that the best part of being a tech resource that manages an infrastructure estate is the scripting. Developers who have replaced a lot of their requirement to script using tools like Maven and Jenkins have a different motivation – they have a desire to remove these elements from their working life as their job is to write business applications. The more of this overhead they remove from their life, the more time they have to do the job they were paid for – to develop. On top of this, they do not believe that removing this overhead makes their job any less interesting – on the contrary they will likely prefer to write java, C# or whatever it is they are writing than a build script. A Life Less Interesting?

Infrastructure resources on the other hand believe their job will be less interesting if you remove the need to write scripts – and in many cases they could be right as this is an interesting part of a sysadmin life. Reinventing the Wheel?

Having said that it is probably more interesting carving wheels to put on your cart than it is to work in a Ford factory managing a manufacturing process that makes thousands of wheels a day that are all at the required size, standard, cost and throughput. Besides the fact a manufacturing process can also be scaled to handle increased demand. If you use a tool like RapidDeploy for your ARA there will unquestionably be less requirement to write scripts – but this new world has plenty of new skills that need to be learned. I Am Too Important to be Replaced by a Machine

Whether it is your senior tech resources believing this or the managers or project managers that they report to – if you have individuals within your organization that are single points of failure for components of your infrastructure this is not a good place to be. It is all too common for organizations to be reliant on Steve for their On Line Banking project or Mike for their CRM system. A manufacturing approach to ARA removes these bottlenecks – no longer will you be required to get an individual to deploy an application or configure your Portal – any skilled resource in your chosen tool can do this, whether they are on your project or not! Deliver More, Faster

Sticking with the manufacturing theme – ARA and DevOps infrastructures still need skilled resources to design and implement the multiple working parts that constitute the system. In the same way a traditional factory has conveyor belts, moulds, robotic arms, etc. that produce vast amounts of product with a relatively small number of people – the same applies to a modern highly automated IT infrastructure. There are skilled engineers that design, troubleshoot and on board new components – and a lower skilled set of resources that can keep the machinery running (provisioning new clusters, deploying applications, introducing configuration change, etc.). This model should be particularly desirable to organizations that are trying to lower their cost base by maintaining a smaller highly skilled onshore capability that is supported by a lower cost offshore function to keep the factory producing goods. Provide Management Visibility

Dashboards are a key component of advanced ARA tools that provide management teams visibility of how their organization is running (number of builds / deployments per day / month; number of environments; what versions of products and code are deployed; are environments even being used, etc.). Combine this insight with the ability to decommission and re-provision at will also allow organizations to massively increase the utilization of infrastructure, plan more effectively for provision of new infrastructure and accurately predict to your consumers how long this will take (and all going to plan it should be a lot quicker than if you were not using an Automation Tool). The Goal Posts Have Moved

At the start of this post I mentioned that up until around eighteen months ago at MidVision we saw a lot more people asking the question “Should I buy or build a solution for my ARA needs?” The value proposition from vendors like MidVision and others used to be “We can provide you with automation frameworks that remove all or some of your requirement to write scripts”. We had the headache of handling future upgrades, supporting new product, etc. However, the goal posts have now moved. Yes, we still provide the base underlying automation to install, patch, configure and deploy to middleware environments – but now we provide a great deal more. Tools like RapidDeploy can import the configuration of an existing environment, clone it to create a new one, write it to source control to maintain, automatically detect configuration drift, provide fine grained access control and audit capabilities for managing infrastructure; provide self-service release capabilities to project managers / developers; workflow approvals for releases, etc, etc. It is no longer just about replacing your scripts with ours – there is a much richer set of use cases supported by the commercial tools than you could ever write in house. If you don’t believe me – drop me a line and I will show you ;-)

http://www.midvision.com/cms/2012/application-release-automation-buy-or-build/

View Another Wikitip

Featured Case Study

Financial giant goes green

The corporate IT group of a very large, worldwide financial organization with 100,000 employees, has initiated an ongoing “greening” process. This is focused largely on reducing energy use both to decrease the corporation's carbon footprint while creating a net savings in operational costs over the lifetime of new, more energy-efficient equipment, including new storage systems.

read more...

Featured How-To Note

Planning a Green Storage Initiative

Fluctuating energy prices have heightened electricity and energy consumption as a major issue within the technology community. IT is a significant consumer of energy and IT energy costs have been rising disproportionately because of continued investment in denser IT equipment. Estimates from the EPA and others indicate that IT will account for 3% of energy consumption by 2012.

read more...