Table of contents
1. Preparing for the move
Before you get too far in planning your migration to the cloud, remember that you are making these changes for business reasons. You are more likely to be successful if you know those reasons and can provide the data supporting your decision.
More than one CIO has insisted on a migration just “because cloud,” but that’s not nearly good enough. Your organization should be clear on exactly what you hope to gain by moving your applications to the cloud.
For one thing, it might not make sense to migrate all your applications—some types of internal apps are better candidates than others, and many cloud-native business applications are already available as a service—there may be no need to provide your own. Rather than blindly “lift-and-shift” all your apps to the cloud, you want to carefully consider all your options.
Which applications should you migrate?
Not all applications are good candidates for moving to the cloud. Migrating an application that’s already performing poorly, for example, introduces new variables that could make it difficult afterwards to identify if problems are due to the new cloud architecture or lie in the application itself. Applications that have repeatable, acceptable performance against your service-level agreements (SLAs) with customers, on the other hand, are sometimes called “Green Apps” and are often good candidates for migration. New Relic provides extensive capabilities to define, measure, and report SLAs (see Figure 1), which can help you assess which applications are good candidates for migration.
Other appropriate candidates for moving to the cloud include applications with highly variable throughput (see Figure 2). Applications that experience large seasonal changes in volume, for example, can benefit from the compute elasticity the cloud provides.
Keeping these considerations in mind (and employing the performance and throughput data provided by New Relic), determine which of your applications are good candidates to move to the cloud in their current form. It’s worth remembering, too, that a cloud migration doesn’t “freeze” your applications. You can still refactor or revise your application after migrating it to a cloud infrastructure.
Establish your baseline
When moving to the cloud, New Relic can serve as both your vehicle for visibility and your anchor for control. Start by capturing performance baselines: Use New Relic APM to view your application’s performance trends—page load times, error rates, slow transactions, and a list of the servers running it. Look at your Apdex score (see Figure 3) to find out whether most users are satisfied with, tolerating, or frustrated by your app. (A higher score is better.)
Also, look at your Web Transactions response time (see Figure 4), starting with the list of slowest transactions. Set Apdex for Web and Application performance of Key Transactions—is the response time acceptable? If not, start troubleshooting and tuning. Create baselines against which you can compare performance before, during, and after migration. Likewise, measure error rates so you know if they increase after migration.
Don’t stop with establishing baselines just for what you usually measure, though. Migrating to the cloud will introduce new variables, and performance and transaction behavior that was acceptable when all or part of the application was on-premise may spark performance or cost issues when running in the cloud. Make sure to establish baselines for anything that might be affected, even things that are currently working well.
The goal is that no matter what changes you make in your infrastructure, platform, or application, the customer experience should not suffer—ideally, it should be improved!
Organizations contemplating a move to the cloud are often concerned with the security of their data. Data stored in systems outside of your firewalls must be kept safe and protected.
Before you get into specifics of security, though, it is important to understand that moving from on-premise to the cloud can change the demarcation point for the responsibility of many things, including security.
Every cloud service provider has a demarcation point where delivery of that service ends and a customer’s responsibility begins. That point varies depending on where in the stack the provider draws the line between the service and your code. For example, in an infrastructure service like Amazon’s EC2, the physical infrastructure is the service provider’s responsibility while the operating systems, virtual machines, containers, and the code running on it is your responsibility. That means you are responsible for the security of the OS (updates and security patches), any software you install, configuration of your firewall, and more.
Sound familiar? You have these same security tasks no matter where your servers live.
In a Platform-as-a-Service (PaaS) like Amazon Beanstalk, Pivotal, Heroku, or Azure, on the other hand, the demarcation point lies between the run-time service and your code.
For your provider’s side of the demarcation point, good security questions to ask are:
- Do you have a security team? (If not, that’s a huge red flag.)
- Have you been audited for security by an independent third party? (Such as the Cloud Security Alliance)
- Are there privacy settings built into the service?
By design (due to security, governance, and liability considerations) though, cloud providers do not access or maintain your code. For example, AWS CloudWatch can give you server statistics, but will not report on the health of your applications. That’s on your side of the demarcation point.
With that in mind, cloud-related security issues may include: forgotten instances/services (a developer spins up an instance and then forgets about it), synchronization folders and auto-uploads (make sure you aren’t uploading malware or corrupted files), and data handling (how do you sanitize my data before your throw it away?). Fortunately, none of these are particularly difficult to manage—you just need to remember to deal with them!
Most cloud providers have a good handle on security. Just make sure they provide you with their security processes and best practices (and read them!).
For more insights, check out these two videos:
In this presentation from New Relic’s FutureStack15 conference, Jason Chan, director of engineering at Netflix, discusses how Netflix is able to develop modern software with developers and security auditors working well together.
New Relic’s Chief Security Officer Shaun Gordon explains how to build an effective security program.
Cloud security and New Relic
New Relic is committed to the security of your application’s performance data. We use a variety of industry-standard security technologies and procedures to help protect your information from unauthorized access, use, or disclosure.
When you use New Relic, you have deep control over what, if any, sensitive information you send to us. When you deploy our agents, by default, our security settings and regulatory compliance exceed industry standards, and all data is encrypted in transit. Learn more at trust.newrelic.com.