In the age of a proliferation of cloud services, the preference for the vast majority of new applications designs is naturally cloud native. Breaking an application into multiple component parts allows developers to take advantage of the multiple services available on popular public cloud platforms such as serverless, containers, and object storage. What you end up with is is a product that is both flexible and elastic, allowing for a rapid pace of change and the ability to scale quickly according to cost and demand. This has led to a desire within the enterprise to modernize existing applications and make use of the advantages of cloud computing.
The Cloud Migration Challenge
The term “lift and shift” is used to refer to the practice of moving existing applications and their respective data from an on-premises datacenter into a public cloud and making no changes to the underlying architecture. This has gotten a black eye as practice as it offers no value to the business in terms of operations and and can add significant cost in some cases. Most often, lift and shift is seen as a strategy used to appease a mandate to “use the cloud” by decision makers unfamiliar with the nuances and consequences of simply moving a legacy application onto a cloud service.
A more palatable strategy to some is to “lift and shift, then refactor.” The idea being that migration of the existing application and data is only a first step in an overall re-architecture. From there, data can be stored in the appropriate type of storage, be it block, object, archive, etc. and services can be broken out as appropriate in order to make use of the elasticity and flexibility of the cloud. The idea has merit as means of moving existing applications into the cloud and eventually making use of the many advantages that exist with a cloud native model, but how practical is it?
Building a Truly Hybrid App
Most IT practitioners, be they in development or operations, have seen an existing application or system that a business depends on and has been deemed “hands off” due to fear that changes will result in bugs or outages that cannot be afforded by the business. In cases like this, can you afford to change the entire application architecture from an all in one monolith to a cloud native application and risk the chance that the transition from old to new will disrupt business operations? Making the transition from monolith to a refactored application gradually would traditionally be difficult, but I was recently briefed by a company named Solo.io that is making such a task possible.
Founded in 2017 by Idit Levine, Solo.io is focused on building products that allow businesses to that are dependent on their existing legacy or monolithic applications to adopt modern cloud technologies such as microservices and serverless. This is accomplished in large part with their Gloo API gateway. Powered by the open source proxy Envoy, Gloo can act as the application delivery mechanism for an enterprise’s existing application as it exists and allow use of new or refactored functions that utilize modern application technologies such as microservices built on Kubernetes or serverless functions running on AWS Lambda. Enterprises can transform the monolith into a hybrid application and eventually cloud native if they wish on their own schedule.
Also available from Solo,io are an enterprise version of Gloo (GlooE) which brings additional functionality such as source control integration and governance and Sqoop, a GraphQL frontend built on Gloo. This is just a small sample of the multiple open source and enterprise products being produced by the growing and efficient team at Solo.io.
Upon hearing the phrase “lift and shift, then refactor” most developers and engineers are likely to react with skepticism, and rightfully so. The idea that you can simply start tearing out and replacing services and functions within a monolithic application is optimistic at best and foolhardy at worst. However a thoughtful, measured approach that allows an enterprise to build a truly hybrid application in the least disruptive way possible is strategy that should be advocated for anyone seeking to modernize the applications and infrastructure.