/// Modernizing Your.NET Apps: A PATH TO PIVOTAL CLOUD FOUNDRY

Transcription

1 WHITE PAPER /// Modernizing Your.NET Apps: A PATH TO PIVOTAL CLOUD FOUNDRY For companies with a large portfolio of.net applications, modernizing and moving to the cloud can be a daunting task. Pivotal Cloud Foundry (PCF) enables companies to continuously deliver any app to every major private and public cloud with a single platform. If you are leading an effort to effectively modernize.net applications on to PCF, this paper will help navigate the process. Robert Sirchia Magenic Lead Consultant June 2018

2 TABLE OF CONTENTS Overview... 1 Become a Software Defined Business... 1 Levels of Cloud-Native Replatforming and Modernization Replatforming Modernization When to Use.NET Core or the.net Framework... 5 Framework Built for the Cloud... 5 Getting More Out of DevOps... 5 Understanding the Platform... 5 A Practical Way to Modernize Step One: Moving Your App to PCF... 6 Step Two: Decomposing the Application....7 Step Three: Try to Use Existing Services... 8 Step Four: How to Build Microservices... 8 Step Five: Consuming the Microservices... 9 Summary i // WHITE PAPER

3 Overview At the heart of the enterprise data center stands the monolithic application. These systems are a paradox crucial to business processes today, yet a painful obstacle to tomorrow s requirements. While the business demands speed and agility, these systems are difficult to update. And when making changes to an application is cumbersome, the entire business can suffer. Enterprise developers spend much of their time reconciling these two realities; it is not an easy task! But that s where microservices come in, a new approach that s producing results in the real-world. The adoption of microservices among.net teams is part of a larger movement, The.NET Renaissance. Many IT leaders are now asking how do we modernize our portfolio of.net apps? This paper not only offers practical answers to this question, but also: Explains how to analyze and decompose a.net monolith, such as a three-tier web application, and update the app to run on Pivotal Cloud Foundry (PCF). Reviews how to modernize applications into microservices using the Steeltoe framework. Demonstrates how to run these microservices atop PCF. If you are leading an effort to effectively modernize.net applications using PCF, this paper will help navigate the process. Become a Software Defined Business Software is changing the way every business operates. In the past two decades, the market has selected winners and losers based on their software prowess. Those who wield software as a differentiator have emerged as industry leaders. Today, winners are the ones who can not only adapt to the latest technology but do it with speed. The biggest companies aren t the winners the fastest companies are. Under this backdrop, many enterprises have turned to Pivotal and its flagship PCF platform. The platform delivers four key benefits: developer productivity, operator efficiency, comprehensive security, and high availability. Keep these ideas in mind this is the business outcome you should be after! 1 // WHITE PAPER

4 Levels of Cloud-Native When considering migrating an application to the cloud, there are four different levels of Cloud-Native maturity: Cloud Ready Applications that are Cloud Ready leverage a few of the core cloud capabilities. There are two important requirements for being Cloud Ready: no permanent disk access and each application should be self-contained. At this stage, the process of setting up continuous delivery of the applications being deployed to the cloud should be started. Cloud Friendly At this stage applications are implementing part, if not all, of the 12 Factor App methodology ( These applications can leverage the ability to scale out both vertically and horizontally, while also leveraging the platform s security and high availability features. Cloud Resilient Allowing an application to fail gracefully and stop a failure from cascading to underlying systems builds resiliency. If an application is trying to communicate with a service that is not working, then it should respond to the client without calling the underlying system continuously. This response should be a known condition and not an exception. In this state the application should frequently, but not continuously, check to see if the service is available and resume normal functionality. This new design monitoring will reveal potential issues and help scale to services that are under higher than normal demand. Cloud-Native From the technical sense, Cloud-Native applications fully leverage a microservice architecture. This should be the first consideration of designing any new application and should be the focus of any modernization effort of an existing application. At this stage, the application should be following all the principles of 12 Factor App methodology. Additional concepts like DevOps and continuous delivery can be achieved at the Cloud Ready stage but should be fully embraced for a Cloud-Native application. Replatforming and Modernization With hundreds of.net applications each with a unique architecture and business value consideration should be taken for each app on what level of investment to make. There are two common patterns for moving a legacy application on to a modern platform like PCF: replatforming and modernizing. Most companies that have a large portfolio of.net apps will need to consider a mix of both options. Because your choice for each app will come down to one or the other, it s crucial to know the differences between each option. 2 // WHITE PAPER

5 Replatforming Commonly referred to as a Lift and Shift, replatforming is the simple migration from legacy client-server infrastructure to a modern platform like PCF. This is a good option when the app: Is relatively simple (like a form-based app). Can be deprecated in a reasonable timeframe. Replatforming will usually yield these positive outcomes: Hardware optimization size the container correctly for the application. Application availability. Increased security ability to patch with zero downtime. Considerations and caveats should include: Lack of third party framework support if these frameworks are not compatible with running on PCF. Workload cannot be moved directly to PCF. For example, a Windows service that is installed on to the OS would need to be modernized. Replatforming an application can be relatively quick. It is best to do it as a stand-alone initiative with no other code or infrastructure changes. This avoids any confusion on where a potential issue might be coming from. Common applications, such as web applications and REST APIs, tend to be straightforward. But with most.net Framework applications there may be some other required changes to get them to run in the platform. Some changes can be smaller - like changing where logging is going or the use of the local file system. Occasionally, some changes are a little more in-depth like access to the registry or the use of COM+. These changes are necessary for successful replatforming. Replatforming should also include the setup of the continuous integration and continuous delivery pipelines (CI/CD) for code delivery. Most.NET companies choose Team Foundation Server or Visual Studio Team Service. Other CI/CD tools, such as Concourse and Jenkins work as well. These pipelines should be configured to every environment from development to production with a formalized process of how changes are promoted. The basis of replatforming focuses on making sure the application can run within PCF and changes can be promoted through each environment seamlessly. Modernization Modernization is redesigning and reworking an application to being truly Cloud-Native. This approach helps you realize the full benefits of PCF. 3 // WHITE PAPER

6 This is a good option when the app: Has a high level of complexity the app has multiple back endpoints that span across different domains within an organization. Cannot be replatformed apps such as Windows services cannot easily be replatformed and can be better suited to be modernized directly. You can then expect these outcomes: Application resiliency the application can handle failures gracefully. Better application monitoring and metrics this comes with the PCF platform. Application optimization scaling up services when your app needs them and scaling them back down when they are not in use. Considerations and caveats should include: Can be a time-consuming process complex applications generally take longer to modernize. Business value needs to be communicated clearly. This process decomposes an app and then reassembles those pieces in more of a microservice architecture. This isn t done as one fast swipe across the application but rather smaller, repeatable steps. Each modernization effort has its own cost-benefit considerations. The staged replatform and staggered modernization approach allows for stops and changes not in the original scope. It also provides a softer schedule for IT departments and can make functionality changes as needed. WHEN TO REPLATFORM OR MODERNIZE REPLATFORM Short lifespan the application is not expected to remain in use for the next few years. MODERNIZE Longer lifespan the application use is indefinite. Not business critical the application is still in use but not vital to operations. Business critical the application has a high business value. Lower architecture complexity the application is smaller and can run with very few changes when replatformed. High application architecture complexity the application has a large set of functionality that span across a few different platforms. 4 // WHITE PAPER

7 When to Use.NET Core or the.net Framework PCF supports.net Core (on Linux and Windows), as well as the.net Framework. Modernized applications can continue to leverage existing frameworks and code bases in the.net Framework. Otherwise, they can move to Microsoft s next generation framework,.net Core. There are tradeoffs for using either framework. With.NET Core, you save on OS licensing. Conversely, if.net Core lacks a supporting library you may need, while the.net Framework has it, stay with the.net Framework. For most instances, it is recommended to use.net Core where possible and the.net Framework only when necessary. Framework Built for the Cloud A few different cloud-supported frameworks enable a quick go-to-market strategy. Cloud frameworks are not required to go to the cloud, but using these frameworks can help get there faster. When using PCF, the go-to choice for.net Core and the.net Framework is the open source Steeltoe framework. Steeltoe is not only driven by the open source community but by Pivotal as well. In November 2017, the Steeltoe open source project joined the.net Foundation. Steeltoe provides the quick and proven implementations of core cloud concepts like circuit breaking, service discovery, and config server. Because it is open source, the community provides up to date documentation and code samples on how to implement the features it offers. Getting More out of DevOps For some companies deployments can be a long and arduous process. From deployments being a manual process to requiring application down time. Deployments are done after testing is complete and the release is signed off on. Pivotal embraces the speed of delivery and efficiencies. PCF helps with operator efficiency with a highly automated platform and provides support for the operating systems. DevOps comes from the close pairing of development teams and operators to meet the needs of the organization. This close pairing helps teams deliver faster and test in ways they were not able to before. Understanding the Platform PCF, and the way it runs applications, is a departure for most.net application developers used to deploying a web application to a shared IIS server. Taking the time to test applications locally on PCF Dev when adding new dependencies, for example, can save time and effort before deploying to the development environment. 5 // WHITE PAPER

8 A Practical Way to Modernize For most companies, replatforming applications isn t enough and modernizing can take a considerable amount of time. In this instance, replatforming first then modernizating makes the most sense. With an understanding of replatforming versus modernization, companies can decide how much they want to modernize. This also sets the stage for modernizing your application along with adding new features. This approach is broken down into a few steps. As previously noted, the first step is to replatform. Once your app has been replatformed, the next step is to analyze the functionality of the application. This will determine how to decompose the application into smaller units. These units will build a list of functionalities to be moved to smaller microservices ready for use by the application. Step One: Moving Your App to PCF Replatforming the application to run on PCF requires a lift and shift. The lift deploys the application directly to PCF. With the CF CLI, pushing applications to PCF can be done without modifying any existing deployment pipeline. For this part of the process, manually deploying is acceptable. At this point the application probably won t run without some necessary changes. The shift is the modification of the application to get it to run on PCF. The shift is not a small undertaking and it is recommended that all changes needed to get the application running are documented fully. Application configurations should be moved at this time from the app to the environment. The applications will need to be modified to pull its configuration from the environment. Once the application is stable in PCF, Continuous Deployment pipelines should start deploying to PCF. It is recommended to move one component at a time (if possible) then see what needs to be addressed. This gives you the ability to replatform sections of an app and focus on getting that into PCF. For example, consider a three tiered web application (fig 1.0). The web UI should be moved first, then the other web API services should start moving in subsequent phases. This approach gives you the ability to replatform and address a small set of changes at a time. 6 // WHITE PAPER

9 Windows Server Pivotal Cloud Foundry Pivotal Cloud Foundry Web API Windows Server Web API Web API Windows Server (Retired) PHASE I PHASE II PHASE III fig 1.0: Replatforming applications in stages The externalization of configuration values is one of the tenants of a 12 Factor App Methodology, but it is not necessary to replatform an app on PCF. Making this change during replatforming will help when you set up the CI/CD and it saves time-changing values in your configuration. Most.NET developers are used to storing configs values in the traditional web.config. These configs are stored in source control with in the app. For this example (fig 1.1), instead of having the config files deployed with the and the Web API, have PCF serve the configs. The apps will need to be slightly modified to pull the configuration from the environment rather than locally. The Steeltoe framework allows this change to be done relatively easy. Pivotal Cloud Foundry Pivotal Cloud Foundry Configs are stored in the apps Configs are supplied by PCF fig 1.1: Moving the configs from the application level to the environment level Step Two: Decomposing the Application In the migration process, analysis of the application and how to break down its functionality is required. This is crucial to getting the application migration path fleshed out and visible before making any code changes. Since this process breaks down functionality into silos, look for cross-cutting functionality that can span more than one area. This might require refactoring the application; the idea is to define the breaks where the functionality can be siloed. 7 // WHITE PAPER

10 During this process, stakeholders should review to make sure all functionality is still needed. This ensures that you avoid spending time and money on legacy functionality that isn t necessary. With this level of analysis, all features of PCF should be taken into consideration to leverage as much of the platform as possible. If you use agile or scrum while doing this process, listing the functionality out as user stories will save a lot of time. As this document outlines, there is no set standard on how the decomposition of functionality in a monolithic.net application should be done. It is complex and should be revisited throughout the migration progress. This comes down to many factors, such as the type of functionality, business, and other architectural considerations. The general rule of thumb is to group by a logical section of functionality and then move that to its own microservice. The outcome of this process is a list of functionality that should be compared to other apps that have gone through this analysis. This will help identify functionality that is used by more than one application. This can drastically reduce the time it takes to modernize and, more importantly, save the cost of modernization. Step Three: Try to Use Existing Services In some cases companies will have functionality that crosses multiple apps. These will need to be modernized with care. If a microservice exists that does what you need it to do, then look to use that microservice. Sometimes it takes no changes to use this microservice. Think about a service that sends straightforward and probably will not need any changes to use. But if you think about a service that updates user preferences, this might need to be modified. In most cases that microservice will take a little modification to consume. This evaluation should be straightforward and take in to consideration any other applications currently using it. Step Four: How to Build Microservices The actual building of microservices was outlined in the Decomposing the Application step. For existing applications, the functionality moves from the current application to the new microservice. This should include some time to look at the best way to build a particular microservice. These new microservices will have to be able to handle workloads for multiple apps. It might make sense for a new service to use a message queue where it didn t before. Taking the time here to do this level of architecture review will save time later. It is also good to look at some of the options offered up in the Pivotal Services Marketplace. The Pivotal Services Marketplace offers up comparable services readily available for use, most of which support.net Core or the.net Framework. This not only will help with speed of delivery but will also provide a deeper level of support than implementing the same type of service manually. 8 // WHITE PAPER

11 The beauty of microservices is the word micro. The service should be small, paring teams that tackle a micrservice down to two or three developers. Too many people rarely speeds up delivery. A new microservice shouldn t take more than a few weeks to complete with testing. If you find your service is taking longer than that to write, then you should reevaluate the functionality in it. If possible, the functionality should be tested in parallel, comparing the results from the original application to the results of the new microservice. After testing to ensure the microservice is returning the expected results, sizing the container should be completed. The platform can show some metrics on things like disk, memory, and CPU usage. These metrics can set a baseline when deploying your microservice, making sure there isn t any over- or under-allocation of resources. Step Five: Consuming the Microservice Once a microservice has been developed and tested, the original application will need to consume it instead of using the built-in functionality. This is called the Functional Flip and should be done after each new microservice is built. Because PCF allows multiple deployments of the same application, comparative testing is required throughout this process. And your CI/CD pipelines can be setup to do this. Thorough testing will ensure the results are consistent with original functionality. Additionally, this will reveal any performance degradation. Testing should take place where an existing application runs alongside the next iteration, then compared. It should focus on the changes the next iteration is making. It isn t recommended to do more than one microservice at a time as it can cause confusion on where potential issues are coming from. Testing should also enable a baseline for how many instances your app needs to run. This can then be configured when the app is deployed. 9 // WHITE PAPER

12 Summary For companies with a large portfolio of.net applications, modernizing and moving to the cloud can be a daunting task. These legacy apps, ranging in size, functionality, and architecture, require a practical path to modernization. Key determinations must be made replatforming or modernizing,.net Core or.net Framework, which level of Cloud-Native that can drastically change your approach. However, if the steps in this guide are followed closely, you should be able to make the migration process painless. Additionally, you ll be able to reap the rewards of PCF quickly, and fully leverage the benefits of running in the cloud as soon as possible. //////////////////////////////////////////////////// About Magenic Magenic is the digital technology consulting company built for speed. We have the right digital strategies, the right process, and the right people to get our clients digital products to market faster. Visit us at magenic.com or call us at to learn more or to engage Magenic today. This document is for informational purposes only. Magenic Technologies, Inc., makes no warranties, express or implied, in this summary. Other product and company names mentioned herein might be the trademarks of their respective owners Magenic Technologies Inc. All rights reserved. 10 // WHITE PAPER