As application moving becomes an everyday occurrence, Hashicorp helps to abstract away the pain of lift-and-shift

I am the first to admit I am not really sure how Hashicorp works - I’m too old to learn new tricks! - but I can understand the need for it, providing tools that help businesses move applications around their often expanding environments. 

I also understand that it sets out to meet a growing need. Large enterprises have had a need to move applications for a while, but they have tended to be one-off jobs, where equally large systems suppliers not only supply the kit and software, but also manage the ‘rocket scientists’ who carry out the move – and tend to tell the customer to ‘leave it to us and don’t ask questions’.

But the cloud has changed all that and moving applications has not only become acceptable behavior, but also a growing requirement. Yet actually doing it is still not easily achieved, certainly not if that needs to be an everyday experience. 

That is the market Hashicorp is targeting. It is no longer just large enterprises that need to move applications and data, and it is no longer a one-off job. Widespread use of cloud services now means the majority of businesses can – and will - do this many times a month. This is, increasingly often, where ‘business transformation’ leads.

That nearly always requires them to take on board two fundamental changes to their traditions of operation. One is not just the migration of legacy applications to the new environment of the cloud, but the continued movement of applications and data to different environments as and when appropriate. The other is the understanding that business agility – that markets, products, production methods and the like can, and will, now change rapidly – will be their key business driver from here on. The technologies they deploy therefore will now need to be up to the job.

A recent one-day Hashicorp conference in London gave some of its customers the opportunity to dive a bit deeper into the ‘hows’ and ‘whys’ of the problem. Two of those users are leading telecom services vendors in the UK, BT and Vodafone. Both are businesses facing massive and on-going transformation in a marketplace that is recreating itself by the hour as new technologies offer new service possibilities that customers are keen to use as soon as they are available.

Vodafone and niche markets

For example, Vodafone has mixed the need for moving data and applications to different cloud services as appropriate with the requirement to maintain compliance within a highly regulated environment as its Principal Cloud Architect, Diego Olerni observed:

There's quite a few telco frameworks that are in that fight for the smallest niche of customers. So, getting features out quickly and effectively can be the differentiating factor. They can win or lose that revenue. The vision behind this platform is to also to abstract complexity - developers or software engineers often don't want to know about the underlying infrastructure. It is not their job and is not where their value is best spent. 

We work in multiple countries which all have their own regulations and therefore one approach doesn't fit all. In a country like Germany, where you have one AWS region, if you want a change and go multi-region, you cannot limit yourself to AWS because the data is saved in-country in German. Other countries don't even have a cloud region, and have requirements for data to stay in-country.

Code reusability is now a key goal to avoid the cost of recreating the same solution in slightly different ways, again, and again. This is still, at least in part, a reality at Vodafone and the target is to move away from that. Part of that plan is to keep a very sharp focus on containers. The aim is to bring Vodafone up to speed with current technologies, but also integrate this platform with its existing code repositories. 

It also means taking a positive view of working with SaaS in order to deliver services to end users. For example, the company needed a new relational database, and could have followed the traditional model by downloading the software, deploy it, manage for scale, and the rest. But Olerni noted: 

It would have taken us weeks, maybe months of planning to the site, the scale of the database, clusters, etc. Or we could just integrate with the SaaS product and pay as we go.

To help speed the design and development processes needed for regular moving applications and data, Vodafone also wanted to achieve a faster development cycle by adopting the Secure by Design mantra, whereby its security team architects have become an integral part of the original design phase, rather than a post-design add-on. The goal is fewer surprises when it comes to approving designs going into production.

BT’s ‘fun challenge’

Meanwhile at BT, the issue it faced was the top level decision to close and redeploy its primary CV data center, with completion just one year from the launch of the project. This, according to  Tom Davies, the company’s Platforms Manager, has been seen as a `nice, fun challenge’:

But it also gives us a good opportunity to look at how we're doing those appointments, and see if there's any improvements we can make to that process as part of this task.

This is a classic case of moving important data from venerated legacy systems, in this case on-premises large enterprise, VMware-based systems dating back to 2006, that the company is starting to move to containers. This has meant moving everything, including 15 year-old ‘temporary fixes’, as well later CV-related services that have been running on AWS. 

As Davies observed, this would normally be an incredibly complex task involving loading Java and struggling with engineering and infrastructure teams that have never had to deal with cloud before. There is also a lot of low-level boilerplate details that need to be considered, such as what goes onto which VM, or how they handle existing AWS credentials, especially if they need to be rotated. There is a significant opportunity for things to go wrong or for rules that are needed to get excluded, and it is highly likely there will be holdups waiting for specialist staff to become available. 

The goal therefore has been to provide developers with pre-approved templates that both satisfy security requirements and enable developer teams to get up and running quickly. This reduces the TCO by leveraging economies of scale whereby different teams use the same tools, cutting implementation times and costs for customers, rather than have them pay different providers, different local sellers, for the same tools multiple times.

The time of Terraform

For both Vodafone and BT the basic solution has been similar, and one that probably fits most others facing similar issues; it is to build a new platform to abstract away a lot of the complexity for engineering teams without implementing an entirely new platform. One of the key tools Hashicorp provides for this is TerraForm. 

This defines all elements of an infrastructure as code, allowing users to re-define the infrastructure an application needs to run on and fits it to the physical environment selected for the task. The cloud and on-premises resources can be defined using human-readable configuration files that can be re-used, versioned, and shared as required. This allows consistent workflows appropriate to the application to be created and deployed as the application is moved, creating a ‘write once, use many’ set of workflows consistent across whatever compute resources are selected. 

This in turn provides the foundation for orchestrating complex business processes that can be relocated as required without engineering intervention. Tasks such as overcoming vendor lock-ins, deploying and provisioning tasks to any part of the network estate to make the most of hybrid cloud investments, and creating self-service tools for onboarding new users to SaaS applications, can be abstracted away for everyday use once they are created.

My take

Business transformation is obviously a big issue for large enterprises, and the end result could well involve a need to move applications and data around a large and distributed infrastructure on a regular basis. So, tools that can abstract away the technical complexities look like a winner. They may not end up being very famous, however, for this role will tend to lie deep in the services development process. That would be something of a shame, for it seems clear that the need to move applications – even if only between different third party cloud service providers – will be an important capability for businesses of all sizes and capabilities. Even small businesses are likely to find the ability to move applications and data to different resources, depending on cost vs workload vs time pressure, a great advantage if they know it can be done without recourse hiring serious technical expertise.