Modernizing with AWS: Replatforming

Fundamentally, organizations modernize existing applications by moving them to Amazon Web Services (AWS) in order to optimize everything from performance to reliability to customer experience. For the business, the goals and measurable outcomes are typically some combination of the following: 

• Improve the customer experience with better reliability and performance 
• Reduce operational cost and effort 
• Accelerate time-to-market for new features 
• Develop and enhance technical and business agility 

While modernizing existing applications can take several different forms, this white paper focuses on the replatforming approach, also known as component modernization. (For an introduction to the six approaches to application modernization on AWS (retire, repurchase, retain, rehost, replatform, and refactor), read our new ebook The Enterprise Guide to Continuous Application Modernization.)  

While rehosting involves moving an existing application to AWS without changes to the business logic, replatforming requires something more; namely, optimizing the application by modernizing one or more components of the application. Components are essentially an endpoint, something that the application interacts with via a standardized API, such as a web server, relational database, or messaging system.

Somewhat riskier than rehosting, yet less complex than refactoring, replatforming can be categorized as a modernization “middle road” when it comes to risk and complexity because modernizing components usually involves some level of changes to the code. Nonetheless, how do you know when the replatforming approach is the right decision? Which applications are best suited for this approach? And, more important, how can you further reduce project risk while streamlining the effort and maximizing all the benefits of a replatformed application on AWS? 

Here’s a hint: data and best practices. This white paper presents the knowledge and experience of New Relic working closely with AWS and discusses how you can make informed decisions to optimize your efforts and outcomes.       

While rehosting is a lift-and-shift approach with no code changes whatsoever (moving your application essentially as-is to AWS) replatforming takes this approach a little further. Based on observations about the application, you make an informed decision to change one or more components of the application, and in doing so, achieve additional optimizations.   

To be clear, changing a component does not change the business logic. It does, however, require changes to configuration, set up, tear down, and administrative practices. For instance, coding for a data connection or an API could change, but the change doesn’t impact the business logic of the application. Any component change you make as part of a replatforming project should follow this rule. On the other hand, changing an application from using a relational database to an object store requires business logic changes, which makes it a refactoring project, not a replatforming one, because it fundamentally changes how your application behaves.

Let’s review a few examples of replatforming on AWS: 

• Changing to a managed relational database service such as Amazon Relational Database Service (RDS) or moving to a metered database such as Amazon Aurora

• Using AWS Elastic Beanstalk to deploy your application

• Moving from self-managed Apache Kafka (on-premise, AWS, or some other SaaS Kafka) to Amazon Managed Streaming for Apache Kafka (MSK)

• Leveraging AWS Certificate Manager instead of running your own certificate infrastructure

• Moving from a self-managed Kubernetes environment to Amazon Elastic Kubernetes Service (EKS)

What these examples have in common is that the code is interacting with components through a fairly standardized API. While the API will likely need to be tweaked, the business logic should not be impacted. 

Why undertake a replatforming project? The benefits will depend on which component you’re changing, but they can and should include outcomes such as: 

• Improved scalability to accommodate business growth

• Improved reliability and performance for a better customer experience 

• Reduced costs for software licensing and resource usage 

• Reduction of the total security surface area of your application

• Reduction in management efforts and associated time and costs

• Improved ability to make informed decisions

In any project, understanding the risks involved is the first step in minimizing them. While the risks for this type of modernization are relatively low, there are certain ones you may encounter when you replatform applications. These can include:     

• Failure to understand application dependencies and/or overly aggressive and complex project goals 

• Lack of cost savings due to automation not being implemented or improved during the replatforming change (manual efforts are still required to operate the application) 

• Negative impact on the customer experience due to poor performance or availability caused by unexpected errors

• Project time exceeds original plans because of unexpected errors and/or dependencies 

• Failure to identify application incompatibility with the new platform.

These risks and others can be avoided or minimized by using best practices that are informed and guided by data derived before, during, and after the replatforming project.

It’s critical that you carefully evaluate your existing application, its structure, and business requirements to determine compatibility with the new target platform. Considerations could include factors such as:

• New database service not supporting same requirements as the previous one

• Application not being compatible with the available operating systems on the new platform (in this case you may need to think about using a container replatform strategy)

• New platform not meeting security requirements of application or business (HIPAA, FedRAMP, GDPR, etc.)

Ensure you identify and establish compatibility for all relevant application factors that relate to your application and its business requirements. Incompatibilities may indicate that the application is a candidate for refactoring rather than replatforming.

Successful modernization projects require deep visibility into your applications, customer experiences, and business outcomes. This means having comprehensive data at your fingertips so that you can make informed decisions about which applications to replatform and which candidate components to change. Data is also essential to help you reduce overall project risk, streamline the project, and measure and prove success. 

To take an “informed replatforming” approach, as we call it at New Relic, you need to begin gathering data about the applications you are considering replatforming prior to taking any action. You will continue to track data during and after the project. In general, you should gather data about: 

• End-user experience

• Application performance 

• Application dependencies 

• Application issues

• Resource usage

• Existing components 

To identify candidates, you will review application endpoints, their versions, and their performance impact on the application. You’re looking for applications with clear APIs to specific functionality that is “black boxed.” The connections that depend on the component are critical to your success; It’s important to identify them all by finding the dependencies using New Relic. 

A great place to start is with a service map of your application. New Relic service maps are visual, customizable representations of your architecture showing connections and dependencies, including applications, databases, hosts, servers, and out-of-process services.

With data in hand, you can then begin working through the steps of an informed replatforming project: 

1. Identify candidates using service maps, end-user experiences, and application performance data.
2. Analyze the application for known issues.
3. Install the component on host integrations to get deeper visibility into component performance.
4. Choose a limited set of components to change.  
5. Apply AWS Well-Architected Framework best practices. 
6. Deploy, test, and transition using automation.

Gain a Deep Understanding of Your Components

Develop a deeper understanding of existing componentry using New Relic host integrations on AWS, which let you filter, analyze, and query data about your AWS services. For a complete list of AWS integrations and to learn more, visit our documentation page.  

Data is not only imperative for the decision making and planning of your project, it’s also the best way to gain the confidence and insight to successfully change components in your applications. That’s because maintaining visibility into the application, infrastructure, componentry, end-user experience, and business success throughout the project gives you multiple advantages. With the right data, you can accelerate your efforts without increasing risk, anticipate and avoid problems, minimize complexity, and maximize optimization of the application in the AWS environment.   

Here’s how to use data at each phase of the replatforming project:  

• BEFORE: Begin monitoring candidate applications in your current environment with New Relic to understand application performance, end-user experiences, resource consumption, error rates, application uptime, and other critical KPIs. These measurements will serve as baseline metrics for comparison during and after the replatforming. This data also allows you to create a plan for addressing systemic application issues that you’ve identified. Use the information you gather to understand the existing profile of the component you are looking to replatform and its current issues. Then prioritize the candidates based on the potential positive impact on business goals.

• DURING: As you begin the replatforming project, it’s important to test your applications to make sure the transition isn’t introducing any problems or slowdowns. During replatforming, use New Relic to check the performance of application code and external services and compare it against the pre-replatforming baselines you established in the “before” phase. This will give you an apples-to-apples comparison.

• AFTER: Once the replatforming is complete, use New Relic to prove and measure your success and identify opportunities to further optimize applications for performance gains, efficient use of resources, and ease of operation.

One way to measure and track replatforming success is by using New Relic combined with the best practices in the AWS Well-Architected Framework. The Well-Architected Framework consists of five pillars: performance efficiency, cost optimization, reliability, operational excellence, and security. The framework was developed to help companies build secure, high-performing, resilient, and efficient infrastructure for their applications.

Don’t Underestimate the Importance of Infrastructure-as-Code 

A strong infrastructure-as-code DevOps practice allows you to experiment quickly. That’s because the ability to quickly set up and tear down environments in isolation lets you rapidly determine whether you will see a benefit in moving to a new component or service.

Read about AWS CloudFormation to learn more about codifying your infrastructure.

A best practice around the first pillar of the Well-Architected Framework is to monitor and measure the efficiency of resource usage before, during, and after your replatforming project. You can use New Relic to review how resource usage has changed. How much efficiency have you gained?   

While your replatforming project may not be triggered by performance improvements, you still need to understand the impact on your end users. Are you making things better? Did the change have any impact on the outcomes being driven by the application, such as more click throughs or conversions because pages load more quickly? Gaining visibility into this information is critical to assess the impact of your efforts on revenue-generating systems.

Apdex is an industry standard to measure user satisfaction with the response time of web applications and services, which helps you see how satisfied users are with your application. Use New Relic to compare your Apdex to the costs incurred by the application. Is this an appropriate level of investment for the role the application plays? What should your targets be for the end-user experience? Your goal is to balance these with the costs, meeting your end-user experience objectives without breaking the bank.

Keep in mind that cost optimization as part of a replatforming exercise is about more than just license fees. It is also related to the amount of labor cost required to self-manage a component as well as the costs of any production issues or outages related to that component. Therefore, the costs to consider should include: 

• The number of components (including component versions) that are being managed

• License cost

• Infrastructure cost (focusing on the balance between performance, reliability, and scalability)

• Operational cost

• Impact on the security footprint

• Error management and reduction of rework and issues related to the component

Today’s digital businesses have stringent uptime requirements for critical applications. Start with a clear understanding of your service-level agreement (SLA) and uptime requirements. Then compare reliability metrics to see how the application is performing against the SLA. What is your rate of application uptime? How often are your users impacted by errors? 

Also consider that your application needs to scale and be reliable for your company’s busiest day, including expected and unexpected spikes. You need both scalability and reliability, working in concert, to achieve your SLA goals and keep your customers happy. 

To that end, how well is your scaling performing? For most applications, scaling requirements are difficult to anticipate, even when only predicting six months into the future. With a small number of users, you don’t need to worry much about how well the application scales, but at higher numbers, scaling must happen automatically. You shouldn’t be spending time tuning your autoscaling rules. Based on the number of users, are you using the right technologies? How ready are you for an increase or decrease in usage? 

You can get in-depth scaling information on your components using New Relic host integrations. Look at metrics such as refused connections, queue lengths, and shards relocating—all of which are indicators of an undersized system. On the other hand, the component may be overprovisioned, using too many resources to accommodate the peaks, but wasteful during the valleys. When you take advantage of an AWS managed service, much of this work is handled for you behind the scenes.

Keep in mind that this pillar of the Well-Architected Framework isn’t just about measuring your current reliability, but assessing whether you’re using the right technologies to be scalable and reliable tomorrow. Compare your current user base and expected user base to how much of your application is using seamlessly scalable technologies. While not every application will be entirely serverless, with the right data you can make better choices about what you are managing yourself.

Scale Up From a Few Users to 10 Million 

View this presentation from AWS re:Invent 2018 to learn about how to make your applications more scalable, including moving to serverless technologies where scaling is handled for you automatically.  

As you go through the replatforming exercise, you should be looking for ways to increase the amount of automation. For instance, adopting managed services can free up developer time and make it easier for developers to experiment because they can easily spin up a new environment to try out a new idea. Over time, how is development improving? How much more quickly can you deliver features? You should see that you have more time to spend on the tasks that will make a real difference to the business.

If you have code sprawl in relation to a particular component, you should identify all the areas that need to change. Then start monitoring things like:

• Number of lines of code

• How well data is componentized

• Issues related to data in production

• How quickly you can provision an environment

As you componentize the data access layer, you reduce the number of lines of code you need to maintain. Less code means fewer errors, typically more rigorously tested code, and fewer areas that could be potential security risks. To achieve this, you’ll need to start leveraging strong DevOps practices. 

Deploying self-managed components such as Apache Kafka will not usually be as easily scriptable as using a CloudFormation template on AWS. Streamlining deployment and maintenance processes for a component  results in fewer moving parts that you have to manage.

For security, an important metric to understand is how much your organization is reducing the security surface area and effort by using managed services. How many databases do you no longer need to track, manage, and patch from a security perspective? And in addition to the number of databases, how many types of databases (such as MySQL, Oracle, Microsoft SQL Server) and how many different versions (1.2, 2.7, 5.4.2, etc.)? The more database types and versions you need to secure, the more your security challenge increases.

For instance, with Amazon Aurora, many security tasks are handled for you, allowing you to focus on other areas. You still need to provide proper rules to protect the data and control who has access, but the lower-level security concerns, such as operating system patches and updates, are managed by AWS. Because cybersecurity is both a technical and a legal issue, it’s important to understand your organization’s security and governance requirements and how they map to what is contractually provided by AWS.

Application modernization is an iterative process—you’re never really finished. You should be continuously looking across your applications for additional components that could benefit from replatforming. And remember that replatforming isn’t necessarily the next step in modernizing an application. Sometimes the best next step will be to refactor the application (make code-level changes to take advantage of modern cloud services, architectures, and technologies) to achieve new levels of quality, performance, scalability, reliability, and flexibility.

Regardless of where you are in your modernization efforts, New Relic can help you optimize your applications faster, more cost-effectively, and with less risk. As an AWS Advanced Technology Partner, New Relic has been granted AWS Competency in five solution areas (Migration, DevOps, Mobile, Government, and Marketplace) based on our technical proficiency and proven customer success.