Hybrid Cloud Blog

RSS

This blog post was authored by Shawn Gibbs, Senior Program Manager, WSSC.

I’ve recently been working with many customers who find themselves at a crossroads when it comes to legacy applications. They have several hundred or thousands of applications running in what was once a modern approach, but in today’s world lack the ability to gain all the benefits available in modern architectures. In the customer engagements I’ve been working on, I’m starting to see paradigms. Like with any journey it is important to understand the destination before you set off. The destination may be a serverless microservices pattern in which applications are architected to offer the greatest flexibility in scale and repeatability at high speed. The goal in a modern approach is to be able to iterate against the components without impacting all the services that depend on them but allow for new business functionality at a rapid pace while increasing the ability scale easily.  Once we have a destination, we need to map the possibilities and process required to achieve short-term objectives that gain some of the benefits of the more modern approach. Moving to a devops approach is necessary, in order to take full advantage of the benefits.

The basic steps I find work well for customers are: 1) Document the destination; 2) Map the journey and find low hanging fruit; 3) Validate the different stops in the journey; 4) Take the first step

Document the destination

The final destination or architecture doesn’t need to be complete or an in-depth architecture but there are some very basic questions to answers. First, it’s necessary to determine what you’d like to use as a starting point, is Windows Server 2016 with a container service enough to get you started? Is your project more elaborate in nature and would benefit from using a platform as a service? A starting point is to consider your depth of capabilities and design a pattern that will utilize this knowledge base. For example, your operations team may be focused and excellent at managing Linux and your development team may be made up of primarily .Net developers. We then look at modern application patterns like microservices and serverless development and decide, how and if the applications should be architected in this way. As part of this design and implementation exercise some packaging and deployment options will be required and containers may be a fit for the microservices we will develop and allow us the ability to increase scale and agility of our continuous integration and deployment process. There are other considerations to look at like the actual tooling that will be used and if other solutions like messaging or documents storage make sense.

Map the journey and find low hanging fruit

These early low hanging fruit can be greater scaling capabilities, faster deployments, and guaranteed consistency between dev/test and production environments. We find that customers are not always looking to rewrite existing applications and that the organization’s priority before starting to build new applications is to gain some of the benefits of newer design models in legacy applications. While it can be easier to start from scratch with a new architecture, it’s sometimes not cost effective or not an option and requires you to start with your existing applications and re-architect them to a more efficient architecture. Once the destination is mostly mapped out we need to get the delta from where we are today and where we would need to be to gain the greatest amount of benefits from a modern application pattern. As the delta list begins to take shape, there is now a requirement to rewrite the code base due to things like breaking out individual services and supporting the .Net Core framework development. If this is a journey and we consider the stops along the journey as the incremental steps we can take to modernize we may see that we can gain certain benefits from lifting and shifting the application to a more portable and repeatable architecture. In this case we may port to a container and deploy ‘as is’ in a container orchestration cluster which now allows the app to be deployed quickly and easily along with scaling automatically using the orchestrator.  We will also evaluate the merits of leveraging PaaS services for portions of the application and these can be delivered from Microsoft Azure directly or from Azure Stack on-premises.

Validate the different stops in the journey

This is typically where we can perform a series of proofs that test the ability to containerize the application as is, as well as analyze the portability of our existing code base to .Net Core . In some cases, we may find a monolithic application with its own internal API’s can be converted to a microservices architecture easily. For example, we may have a Web front end that talks to a few API’s that are part of the same codebase deployed as a single application running in a web server. We may deploy the same code base to a number of containers and mark each container as the entry point for the individual API’s and front end. In this phase, there can be a fine tuning of tools and processes that will be required for the destination but more importantly ones that can be used at individual stops along the way. The goal would be not to use an interim set of tooling for these middle phases of the journey that doesn’t translate into the end result which could be costly and not required. It’s also important to understand that microservices architecture and/or containers is not for everything. In some conversations, I’ve been asked ‘how do I back up my container?’, a sign that organizations haven’t quite caught up with the new way of doing things.

Take the first step

This is where the project will realize some of the benefits mapped out in our journey. In most cases the journey includes a lift and shift of an existing code base into a more modern model which was tested in earlier stages. In some cases, these may be the final destination for example, a containerized microservices architecture where only the code base and type of containers may change. As part of the journey you can formalize the final CI/CD process to maximize the benefits afforded by either containerizing, code refactoring, or both.

The changes in app patterns and the rise of containers is the kind of paradigm shift that happens every decade or so.  This is definitely a big shift for the industry, but it holds a lot of potential benefits for organizations to move faster and respond better to a changing competitive landscape.  After having worked directly with dozens of organizations on these very changes, I’m a firm believer in what’s possible with this new technology and I’d encourage you to find an app in your portfolio and get started with the process today.