Businesses today are in the process of augmenting or even shutting down their data centers, and moving into the public cloud. As customers move their services into Azure or other cloud providers, they quickly confronted by a breadth of questions some of which are listed below.
- How do we most effectively move our services into the cloud?
- How do assess what we’re moving?
- Will we lift & shift our infrastructure?
- Will we rehost or refactor our applications?
- Will we choose to rebuild our applications instead?
- How do we optimize our applications for the cloud?
The answers to those questions are driven by what brings many businesses to the cloud in the first place. Perhaps your datacenter contract is expiring in a month and you needed to relocate yesterday. Or you may have run out of capacity in your data center and need to stand up new systems rapidly. You may just be looking to slowly exit the data center ownership space to reduce the capital expenses associated with running your applications as part of a long-term strategy. Whether you are taking the slow path or the fast path, your business still has applications and services that need to be available and running consistently for your customers.
Most organizations have a wide variety of applications out in the world today. Some may have been written last week and others written twenty years ago or more. They all bring value to the business, but they are built in so many different ways with so many different tools it’s become nearly impossible to manage them.
These challenges are never more apparent than when we look to move our applications to a new home. Our applications and operations teams begin the usual forensic processes:
- What is this application?
- Who wrote this? Do they still work here? Does that company still exist?
- What language is this? Do we have an installer?
- How is this application configured?
- How do we stand this up in a newer operating system?
- Etc…
For many modern operating systems, we can initially avoid some of these forensics by leveraging tools like Azure Migrate and Azure Site Recovery to quickly lift & shift our existing servers, as is, into the cloud. But what do we do with our legacy software? That rack of systems hidden in the back of the data center that are still running applications on old operating systems. What about those applications our teams are confident could be rebuilt for containers if they could only rewrite some of the code?
Instead of spending resources rewriting our applications, let’s take the forensic work our teams need to do anyway and use it to repackage our applications for portability. We can enable our teams to achieve this with Habitat. Let’s look at a couple of examples.
Migrating Legacy Applications
We recently worked with a large manufacturer to take a high-value Commercial Off the Shelf (COTS) application that had been stuck on a Windows Server 2003 instance and moved it into a modern system. Not only was this application stuck on a past end-of-life operating system, but updates to this application would take 3-5 days to complete.
This application was originally written in circa 2000 in Borland Delphi and was in Portuguese to add another layer of complexity. It is high value to the organization, as they are required to use this application by one of their largest customers. We worked together to repackage the application with Habitat. The customer spent a few weeks with a couple of our engineers uncovering how their app was deployed, and capturing that process in code.
By the end of the engagement, the customer team was able to deploy new instances of their application in less than 10 seconds. Their newly packaged app is also now able to be deployed into the latest versions of Windows Server, and could even be deployed to their new cloud environment.
In a few weeks’ time, they were able to modernize their legacy application for the cloud era.
Portability
Being able to move our applications into modern operating systems is a great way to reduce the footprint of risk in our organizations. Another thing we look for when we move to cloud is the optimization of our resources. Optimizing for risk is one way, but we also look to optimize our utilization in the cloud. Whether that is moving into containers to leverage smaller systems or leveraging Platform as a Service (PaaS) applications in Azure to replace components of our applications.
Once you’ve packaged your application in Habitat, you can export it such that you can run it on a virtual machine, or even upload container images to an Azure Container Registry, and run them in Azure Kubernetes Service. Applications that use a database can either package that database with Habitat, or move the database into an Azure database service and then have their application package connect to that database service. These solutions quickly accelerate your ability to optimize your cloud deployments to be as efficient as you need them to be.
Next Steps
Come and learn more about migrating applications into Azure with Habitat during our Automation, Audits, & Apps Tour. We’ll be stopping by a city close to you in the near future.
If you can’t make it, or you’re looking to get started sooner, here are some things to take a look at now:
- Read the blog post: Packaging COTS Applications for Windows
- Download the State of Apps Infographic
- Download the white paper: Modernizing Legacy Applications for the Digital Age
- Learn Habitat – https://community.chef.io/tools/chef-habitat#learn
- Learn more about Chef and Azure
- Learn more about DevSecOps