Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon


Cloud Migration Cookbook: A Guide to Moving Your Apps to The Cloud


Special Guest Speaker: David Linthicum

Are you thinking about moving your business apps to the cloud? You’ve heard all the buzz around the cloud and it has got you curious. Which apps do you move? How do you define the requirements for the migration? Moving the wrong apps could result in huge, expensive projects that do not meet expectations. However, failing to move the right services could mean lost opportunities. You don’t want a nightmare on your hands and you aren’t quite sure how to get started.

The process of building new apps or migrating existing apps to a cloud-based platform is complex. There are hundreds of paths you can take and only a few will make sense for you and your business. Get a step-by-step guide on how to plan for a successful app migration.

About David Linthicum:
David S. Linthicum is a SVP at Cloud Technology Partners and an internationally recognized industry expert and thought leader.

Note: Webinar recording quality may be distorted. For full slide deck please visit:

We'll cover:

  • The technology benefits of leveraging cloud computing for certain apps

  • How to host a new or existing app on a cloud or clouds

  • Best practices on how to migrate your apps

Full Script

Cloud Migration Cookbook: A Guide to Moving Your Apps to The Cloud
Abner Germanow: Good morning. Welcome to our webinar on cloud migration. My name is Abner Germanow. I am with New Relic. I'm absolutely overjoyed, today, to be joined by David Linthicum to talk through the issues and what happens when you think about cloud migration. I've been reading David's articles for years. He's one of the more prolific authors on cloud computing. He's been writing about cloud computing before it was a thing, before it was called cloud computing.

Even better, he spends a lot of time with customers. He's been all over the industry. Lately, he's been spending a lot of time helping companies re architect their software for a world where people don't shift TVs around, but rather they have SaaS services. They are moving towards applications that change their businesses and they're doing that in the cloud.
With that David, I'm so happy to have you here today and why don't you take it away.

David S. Linthicum: Thank you very much, Abner. I'm excited to give this webinar because this is the question I get from everybody is how do you migrate applications, data systems to cloud based platforms?

What is the proper methods, techniques, steps, things you need to actually understand to make the proper decisions to migrate these applications and databases to the cloud?

Rarely, it's a typical complex problem where it depends. It depends on your application, it depends on your enterprise, it depends on your security, it depends on your compliance and all those sorts of things.

It gets complicated very quickly. What we are going to try to do in this presentation is break it down into steps that you can follow a cookbook, if you will, to make the migration for you.

First, let's talk to you guys. Let's go ahead and put up a poll. Let's ask you the questions that I think maybe on your mind. The poll is open now, and please go ahead and respond.

Abner: One more housekeeping note as you are taking the poll. If you have questions along the way, feel free to pop the question into the question's panel on GoToWebinar.

David: Please do that. Let's go ahead, and close the poll and put up the results. Could you read the results, Abner?

Abner: Cloud wash, we have 63 percent are dabbling in the cloud and not really doing a whole lot of modification to apps, 21 have adopted some cloud services but they're not feeling like they're fully optimized, 5 percent say they're optimized, and 11 percent say they're full on cloud native already.

David: We're seeing those kind of results out in the field right now. Funny the "Cloud native" part. I guess we'll talk about that, what actually "cloud native" really means, but most people really get into the cloud, initially, especially at the enterprise level, by taking a cloud wash approach.

What they do is move enterprise applications into private clouds. Some move them into managed service providers and, in essence, call them "Cloud." There's advantages to doing that, but obviously there's some disadvantage in the fact that you're not necessarily getting the benefits of cloud computing.

Going forward, if you look at what we need to do to move into the cloud, it looks something like this. This is the way we define the methodology.

We have defined when we actually take inventory as to our applications and where they need to go, what they are, what they do, what the data is doing all these things that are really, really important to make sure we understand what the application's purpose, security, compliance all those things, before they actually move into the cloud, or the potential moving into the cloud.
Next we develop. We figure out the way in which we're going to do it. It could be no code modification, some code modification, complete code modification. Test and optimize, we validate. We make sure that we're moving into the cloud correctly, optimizing the applications for the cloud.

Finally, executing, which means deploying and getting the systems up and running. Then, monitoring, at the same time we have to deal with the data and deal with metrics, in terms of how we're going to monitor and make use of data that's being spun off of the operations in the cloud and then also platform - Microsoft, Amazon, Google - those are the top choices we're seeing out there.

But what about the managed service provider? IBM platforms, other private clouds, things like that things you really need to consider if you start moving applications in the cloud.

Let's go right into define. What we're doing now is focusing on existing applications. We're typically migrating applications that may exist on a LAMP stack within our enterprise, could even exist on a mainframe, could exist on distributed computing systems that we built over the years.

It could be 2 years old or 20 years old, and it could be using very structured data or very unstructured data depending on the generation of the application. What we need to do is go through a workload profile.

What are those applications doing, and how are they doing it? What kind of workloads are they experiencing? Are they data intensive? Are they process intensive? Who's using them? How many users are on them?

Performance profiles, network impact, all those things need to be understood. You need to deal with the application architecture. How is it architected?

Is it very tightly coupled with a Monolithic application where the data is directly bound to the system, or is it loosely coupled where all these various systems can exist in a distributed environment easily? As well as the data that's decoupled, it would be ported to the cloud easier.

Business case, in other words, is it viable to port the thing to the cloud? In other words, are we going to make a huge mistake by doing it, because the ROI's not going to be there? We may move into the cloud because it's cool, and we do cloud washing, so to speak, but not necessarily get the business benefit from it.

If the business benefit isn't there, then you're not necessarily serving the needs of the business, which is the primary goal, objective of IT. Validate the application, and then finally select the applications for migration.

We typically look at hundreds of applications at a time, when we look at a large Global 2000 company. However, all of those applications don't necessarily need to move to the cloud.

What you need to do is do a triage, and assess who you see here, and make a conscious decision based on the business case, the technical case, the cost case and all these other things to see if that is something that should be moved directly into the cloud.
Not everything should be moved in the cloud. Here's in essence an investment of value analysis. This is a real life analysis that I did for a client. They estimated application migration resource levels, 9000 applications looking to moving in the cloud.
This is the kind of value that they can realize based on the spend and investment that their making. FTEs, Full Time Employees, up to almost 1200 over several years. The investment obviously goes up with the FTEs.

However they look at the value that they can experience, in moving those applications into the cloud, and they get to huge amount, as you can see on the bottom. $800 million that they're going to save, adding value to the company in terms of cost savings, in terms of agility, in terms of the ability to perform better.

Ultimately this is what the application migration projects look like. These are the kind of values that they get. It's not always a one to one investment. It's not necessarily a knock out of the park like this is.

Typically, if you look on average, the number of applications that move into the cloud, versus the investment you're making, and versus you measuring your value that comes back in terms of agility, in terms of cost savings, it's typically going to be indicated that you make the move.

You move a good majority of the applications to the cloud, but not all of them. The application architectures change when we move into the cloud. We have traditional application architectures. You know, scale up, monolithic, stateless.
All these things are what we find in legacy applications that exist in the Global 2000. If you're going to change them, with the cloud aligned application architectures, you need to deal with things such as distributed stateless, elastic capability, latency tolerant, loosely coupled.

All these things that are not necessarily built into the legacy systems out there. One of the fundamental decisions that you need to make, if we're going to move these applications into the cloud, then are we willing to change the architectures to make them more cloud native?

...specifically architected to take advantage of the cloud platform. Are we just going to do a lift and shift, where we don't make the code changes, we put them up in the cloud and maybe do so later?

When you're getting to changing the architecture you're getting to change the code, and that's with the money and the risk and all the other thing really comes in. Fundamental to this presentation, fundamental to what you'll see out there as people are migrating applications to the cloud, is lift or shift, or refactoring.

In other words, should I just port the code to an analog of the platform, that's going to be up in the cloud and running, typically without a lot of testing, without a lot of forethought, just make the moves and run the code, or do I go to a complete refactoring? Means changing the core application, redesigning it, and make it more of a cloud native system where we're actually able to run it more effectively, efficiently, cost effectively where it's really built to the cloud environment.

Two schools of thought there. Number one, go ahead and port the application without making a change and then, later, you can make localization efforts and redevelopment for the cloud platform, or go ahead and spend the money initially as you move it into the cloud and make it cloud native and specific to a cloud architecture as you make the move.
Note on this slide the number of things that have to change if you effectively move something into the cloud and take advantage of the core systems. All these things soft hilling, automation this then sends out to me the cost. All these things are really going to drive some changes to this core application.

The common methods and approaches we have replaced. We'll be able to replace the application with a SaaS service. We have reused. We have refactored. We have re platformed. We host, retain, we spot retire. All these things really are there as categories as to where you need to put the applications you're looking to move into the cloud before you make the move.
Should they be replaced with a Saas system such as Are you willing to make huge re platforming and refactoring changes as you move to more of a cloud aligned technology and platform services? Is this just a lift and shift re hosting mechanism? Are you looking to just retain the application as is and not make the move?

That could be the best path for some applications. Is this application at its end of life and needs to be retired? A lot of times, when we go through these triage for application migration, we do find a tremendous number of applications that are, in essence, outmoded and outdated, not necessarily providing the value anymore that need to be retired.
At this point it's OK to go ahead and point them to end of life and either find a replacement that may exist in the cloud, or eliminate the application altogether.

When you do the application modernization and migration estimates, this is what you typically would look like.
Doesn't necessarily have to be this kind of a spreadsheet or this kind of a chart, but you need to figure out the complexity. You need to figure out the duration. You need to figure out the number of architects it's going to take to change the application. You need to figure out the the client's code. You need to figure out the data layers.

You need to figure out the changes that are going to be required. Is it going to be 5 percent, 10 percent, 20 percent? The SLAs that are going to be required, performance requirements, time you think it's going to take, the people you think it's going to take as you start moving things forward.

From the very simple application it may take one person less than a week of time, where a very complex application could take as many as 50 people with as much as 24 months within the application to go ahead and make the change.
These things vary based on skill sets and the true complexity of the applications, the architecture of the applications, but this provides you with a preset determined way to gather the metrics that you need to make sure that moving the application is going to provide the value, and you know exactly how many resources we're going to spend in making the application move.
These are decisions you need to go through. As you triage your application, understanding the resources that have to be picked, have to be leveraged in order to make the application move, the risks, the complexities, the time/duration, things like that. It's very, very important that you go through this analysis.

I understand it's boring. It doesn't take that long, but we have a good determination and the ability to go back and get budgets and make things happen versus just diving into it, getting the applications ready to be migrated and realizing you haven't made the right resource estimations, and therefore, you're going to have to go back and get more resources to make the move.
That's typically not a good move in global 2,000 organizations at Global One, the government, so this is the way not to do that.
Develop. You can figure out your options. Number one, moving to cloud native. We talked about that. Cloud native means different things to different people, but to me it means that I'm going to, in essence, localize an application or refactor an application so it takes advantage of cloud specific features.

I've been on Amazon. It takes advantage of the scaling features, the distribution features, things that it provides me that are not native to the platforms in which the application came from. The tradeoff is the application functions more effectively and efficiently, and we're able to take advantage of the cloud specific features.

We're also losing portability and we're also spending time in actually changing the application, so that's going to cost us money. These tradeoffs need to be considered. Many instances, people choose to port an application lift and shift into an environment such as Amazon, leave it as is, and run it.

Then observe it over time to see how its efficiency is running and how well it's using the resources of the cloud, and all these sorts of things we want to monitor and manage. Then, based on what they learn, they may want to change the application to make it more cloud native, or they may not, based on how successful the cloud is running on that environment.

You need to make these decisions based on the application needs, based on the security compliance performance, all these sorts of things, and really, the importance of the application. We have to deal with data. We have to deal with application security. We have to deal with application governance such as micro services orchestrations, deleted governed resources such as storage.
We need to figure out a way to approach testing. We need to figure out a way to select a cloud platform, and we need to select a development platform. How are we going to build it? Is it going to be built within a SaaS environment? Is it going to be built on native tools that come with the platform? These decisions need to be made. Cloud native application architectures, as we just talked about, they really work with cloud aligned applications we have to deal with scale out distributed. Basically, what specifically needs to be changed as we move into the target?

It's different from Amazon. It's different from Google. It's different from Microsoft Azure. It's different from MSPs such as RackSpace and such as DataPipe. All these things out there, these platforms, have specific features that they offer that you can leverage or not. A big decision is, how much of the application's going to need to change to move in those environments?
As we talked about during our poll questions is application maturity. Is this going to be cloud washed? Is it going to be a force fed run in cloud environment, resource not optimized, no horizontal scaling? Are we going to do a cloud adopt approach? Is it resource not optimized? No automatic elasticity.

Some modifications done to the cloud deployment to a tier, to the cloud principles. Basically, not much is done, but we're putting on the cloud and we're making as few changes as possible. Cloud optimize. Resources being optimized where horizontal scaling is possible. Elasticity on the instance level. Measure modifications done to be cloud compliant.

We're doing a lot of modifications that I would say a complete refactoring, but heavy modifications to the application and to the architecture, or being done to the application to make it cloud optimized. Finally, cloud native, which is a fully cloud aware system, can communicate with cloud management layers to start or shut down instances itself.

It can fire up resources. It can put away resources. It can move itself off of instances. It can be self healing. It can be designed for failure. It can move actually to another physical data center if for some reason it fails, where typical applications can be able to do that in aid to themselves. Then it's elastic and resource efficient, which means that it's going to cost you less money.

The idea being is how much you want and how much you need to pay in order to modify the applications to make them specifically designed for the cloud platform. There's arguments that it should be just lifted and shifted. Pay as little as you can to get it on the platform localized, get it running, get it tested, and get it into production as quickly as you can.

That's the best path to value. Or it needs to be completely rewritten. The reality is it's always decisions that have to be made on an application by application basis. There's no hard and fast rules where you lift and shift everything, or you make everything cloud native.

You have to look at the value of the application, what it is, what it does, what you need to do to live up to the needs of the business.

We go through some application portfolio analysis. We go through breadth analysis, depth analysis, migration planning, Agile application migration. We have the application portfolio classification, the target endpoints in terms of where it's looking to go, application endpoint mapping, so where are we looking to take it? That's the breadth of it.

The depth is the cloud readiness assessment, the platform config analysis, key metrics, its scalability performance, migration effort estimation, code mediation, and code remediation and recommendations. Once we understand the applications, figure out a way to migrate it and figure out the best way to make it happen.

Then also, take a look at the newer methodologies for development in Agile and DevOps, the refactoring, the ability to use DevOps infrastructure, the ability to automate a lot of testing and migration, and the ability to automate a lot of things that we had to do necessarily by hand, and, in essence, take a lot of the inefficiencies out of doing the application development, testing, localization, deployment, and operation.

These are the steps you need to go through as you move your applications in the cloud and, at the same time, look to improving your infrastructure. I'm not going to spend a ton of time on this slide because DevOps, lots of stuff out there in DevOps to do that.

But continuous delivery with continuous integration, DevOps to the cloud, the ability to put in an automated infrastructure which is going to, hopefully, allow developers to make changes, and have those changes tested, and have those changes integrated, and have those changes deployed, and have those changes into production in the cloud and operating in the cloud with the least amount of human intervention and, therefore, latency needs to occur.

The idea, if cloud is going to be a central way to deploy the applications, then our ability to set up a living, breathing mechanism to allow the changes to the applications to be made by the developers not necessarily have to go through a waterfall of things that have to occur before it goes into production.

We get out of the 1.2 and 1.3 version number methodologies into, "When something is broke or something needs to be changed, we fix it." The developers hit a button. It should go through some rigorous testing, some rigorous analysis, some rigorous integration before it's deployed and put in operation mode in the cloud.

That's something that you really should have on the top of your list as you make these changes as well. Keep in mind that identity and access management is key. This is not a security presentation, but federated identity management in cloud computing really go hand in hand. At the end of the day, cloud is a large, widely distributed, complex system.

The way in which we want to maintain it and we want to secure it is to assign identities to services, and identities to people, and applications, and data, and all these sorts of things, and have a mechanism to manage these identities centrally through some sort of centralized trust, or distributed federated access methods, and identity managements, and all these things that need to occur.
Build these things into your system. Either it's going to be outside the domain of the applications, which means it's not necessarily going to be tightly coupled and not as effective, or it could be within the domain of the applications, which means that the applications are aware of the identity and access management systems.

It will take advantage of it, and, therefore, your applications are going to be more secure, specifically in a cloud environment. Keep in mind that everybody is scared to death of cloud security, but if you look at the hacks and breaches that have occurred over the last couple of years, the ones that made the nightly news, cloud is not anywhere near them.

We've been doing a pretty good job. That's because security is typically a priority. We also have new and more modern tools, such as identity and access management, that we can leverage within the environments to make them more secure.

Cloud governance, security, service portfolio, the ability to gather these services and deal with them, IT organization design, vendor viability, contractual agreements, all these things need to be considered. Cloud governance, at the end of the day, is the ability to work with a security system to set up policies to define who can access what and what they can do with what resources.
It could be a storage system. It could be a database. It could be a simple microservice. It could be lots of things that we, in essence, want to configure so they're utilized correctly. Governance systems aren't necessarily restricting. What they do is they protect you from people who are going to saturate your resources and from security breaches.

They look for patterns. They restrict use. You may be able to get by the security system in some way, shape, or form, but you can't get by the governance system because you're going to go out of bounds of the policy that's set for the utilization of some resource or some service.

Consider cloud governance as something that's systemic. You should consider leveraging cloud governance directly from your applications. If you can't, you can certainly put them outside the bounds of your applications. It's not as effective, but it may be the best value for you as you move into the cloud.

However, there should be some sort of governance planning, and governance technology planning, governance selection of the technology, and the ability to manage these things, centralizing effectively as you move it in the cloud.

Cloud testing. You do your functional testing, bandwidth latency testing, load performance testing, stress testing, regression testing. Automated testing tools such as those that are sold in the DevOps environments are there for you to utilize within your Agile architecture as you move applications into the cloud and go through these sorts of testing kind of things.

It's very important that you understand that testing is not just the function of the system. It's testing the impact on the network. It's testing the load on the platform. It's testing the number of cycles that it uses, the number of storage units that it uses, the number of objects that it uses, the number of database blocks that it uses, and the ability to stress it to make sure that it doesn't fail.

It's very important that we test things in the cloud. We have a tendency to overlook that because you think that a cloud is going to provide the resiliency and scalability. Therefore, we're not going to have performance problems. We're not going to have stability problems.

But the reality is that you have the same issues in moving applications to the cloud as you do on other platforms. You should test for them to make sure that they're not there.

Picking a cloud. This is an example of an analysis that was done in an organization, a Global 2000 company, that had to select a cloud: AWS, Microsoft, Google, HP Cloud, IBM Cloud, Rackspace, Terremark, the usual suspects.
Look at what's important to you: storage provisioning, management governance, network compute, security and then assign certain weights to them in terms of their ability to solve the problem.

You have to examine the clouds in detail and do a lot of research in terms of how does AWS do storage, versus Microsoft, versus Google, versus HP. Then assign them a ranking and assign them a weight to the category, such as below. You see the disruptive vectors, storage provisioning, management down there with a percentage.

Then it'll come up with the winner based on the importance you've given the rankings and the importance you've given to each of the categories. Such in this case, AWS was 3, and Microsoft was 2.7, and Google was 2.9, and so on and so forth.

But if you run your own requirements on this particular spreadsheet, you'll find you'll come out with your own unique ranking based on the weights that you provide it, that you've give it, which are objective, and then the weights that you give to each of the capabilities, and this is what we call the disruptive vectors, which are based on your requirements.

Validate. Optimizing tests, performance stability, use, and gathering metrics are the most important things to pay attention to. Optimizing tests means that we're looking at the architecture. We're looking at the automation. We're looking at the cloud ongoing design support. We're looking at the project management.

Cloud's scheduled change support, cloud performance and validation testing, cloud operations audit, cloud knowledge transfer, all these things are very important because we're trying to get the value of cloud into the organization. We're not only just moving applications into the cloud.

We're changing the organization, and hopefully the knowledge of the organization, and how they leverage this stuff. If you're going to optimize the use of cloud computing, you have to create a cloud ops organization and a dev organization that understands how to make use of cloud.

There's a number of ways to look at this. But, in essence, you want to change the thinking, change the culture, change the skill sets. You only are able to do that through the success of the deployments you're able to make.

Monitoring metrics. You need to look at a tool, such as New Relic, to guide you in terms of what the operation's doing at any given time and how things are trending. The data that tools like this are able to spin off allow you to optimize and tune spot issues before they become complete problems.

Ops tools, and the ability to gather metrics, and the ability to utilize data from these metrics effectively and efficiently to maximize or optimize your operations is absolutely essential. Keep in mind that the infrastructure is with somebody else. We're paying them to run our applications.

The ability to monitor how those platforms are actually performing has huge amounts of dividends when you figure you're able to get ahead of problems, and actually improve the performance, and improve the way the applications run.
Execute. Final step. We move into production. We've picked the applications. We figured out how we're going to refactor them. We figured out if we're going to do lift and shift. We figured out whether it is partial refactor. We figured out the business case. We figured out the approach. We figured out security. We figured out governance. We figured operations, figured out operations planning.

All these things have occurred. We're ready to make the move. What do you do? Application deployment or hosting the application on the public cloud. Basically, you move the application, put it into production. It's tested, ready to go, and into an operational state. That's just it. Making the move and doing it. Then application operation, the process required to operate the newer migrated application.

What changes have to be made in terms of operation planning? Operation lump stack in our local data center versus operating on a AWS instance in the AWS cloud, who's going to operate it?

What kind of operational plans are there? What happens if the application goes down? What kind of SLAs are you going to support? Who gets called if that particular application needs support?

Application monitoring, means that we monitor the various application components to determine current, past, and the future health of the cloud based application. If applications run and function constantly monitoring the system and constantly monitoring these applications enables you to determine a great deal.

One of the things that I would recommend with anybody making a migration into the cloud is to leverage some system that gathers operational matrix and is able to turn those matrix into real life data you can analyze and make sense of as to looking at the health, and looking at the performance, and looking at the consistency and stability of the application that exist.
We can do a couple of things. One, we can make a decision as to whether or not we should further mediate or are we stuck to the application to make it more coordinated based on the information we're gathering or figure out if nothing is to be done. Everything is running optimally, we're doing good.

We don't need to spend any more money on this particular application based on the side of the business. You only can tell that through a very robust and sophisticated monitoring routine. I'm going to turn you back to Abner.
Abner: I am going to talk about New Relic and how we fit into the whole cloud migration trend. One of the things that we see a lot of is this cloud software team where the focus is on enabling developers, there's a need to migrate existing apps. Once you are up and running, you have to experiment to transform.

I want to talk about each of this as we go through today. When you're thinking about software and the matrix that are needed to run your software, if you look at a classic three tier app, it looks something like this. Today, you may be dealing a re architecture of it in preparation to move to a cloud service.

You use a number of third party services and APIs. Often, you might have part of the application in public cloud and another part in a private cloud. Historically, if we think about the data that the application and the infrastructure components kick off, this application data is what the developers and Ops people spent their time analyzing and monitoring.
Out in the customer world, you have the marketing people who are interested in customer behavior. You have others who are interested in how various Apps are being used, if your mobile App is being downloaded and used. What we all care about is the business data and the ability to figure out whether the applications are fulfilling the business goals or not.
If you think about the amount of data that all of these things kick off, it's not unusual to have an application kicking off a couple of million matrix a day. New Relic as a whole, we ingest about 800 billion matrix a day. There's a lot of data out there and you have to make sense of it.

From an officer developer career success perspective, one of the things we talked a lot about is this application performance has to be measured in the context that customer experience in business success. If the app is your business, you have to be able to make these adjustments knowing what the impact the end customer is going to be.
Let's start a little bit about accountability in the cloud when you think about those data types.

If you think about the application performance, the cloud service provider has some accountability for keeping the infrastructure running. You need to keep them accountable for that. For the other pieces whether it's a customer experience about how the customers are engaging, or how is the business doing, that's where you're accountable.

One of the things that we see a lot of people doing is using data to make sure their teams are accountable for what ever it is they're trying to run in their application.

How New Relic fits into this is we have some products for application performance. APM is the flagship product that New Relic started on so you can see everything that's happening inside your application.

We have servers which allow you to monitor servers in the cloud. That service is currently free and supports Docker. Plug ins for things that you can't deploy a [inaudible 37:40] onto, we can plug in to various APIs and pull those matrix into our platform.
For example, most of the cloud services Rackspace, Amazon, IBM Bluemix, and a few others, allow us to port their data into our dashboards.

These colored APM servers and plug ins are opinionated pieces of software, so they'll tell you what we think is the issue with your software. Inside is at heart query tool and data store, and dashboard and tool that allows you to pick matrix out of your software that are important to you and your business.

Most people like to have a balance of both of those. Same on the customer experience side, whether you're monitoring mobile Apps, reach browser Apps, or you want to have a synthetic monitor of your Apps, or you want a robot to check out and see if your ecommerce card is working on a regular basis. You can use insights to pull all those matrix together in order to figure out how your App is performing from a business perspective.

That's all fine and dandy. How does New Relic help a cloud migration? One of the things that we see a lot of is that there's this old assumption that if the server is working, the application is fine.

That made a lot of sense when sever monitoring was much easier than application monitoring. It also made sense when the majority of the money you spent and the time you spent with building your own infrastructure. This new assumption is the application behavior is the first thing I care about and the infrastructure behavior is the second.

I care about the infrastructure behavior mostly from a cost and accountability standpoint with my cloud vendor. New Relic allows you to monitor your applications regardless of where they are. In this case, we have New Relic running on the front end, we have some other monitoring tools that's an on cam tool that might be holding your application back.

Sometimes, you move your front end into a particular cloud service. If you decide that you want to move everything, or if you want to leave it where it was, and monitor it with New Relic, you can do that. When I talk to people about how they use our tools, it comes down to reducing the migration risks at the beginning.

That's where people start. When you're thinking about assessing and bench marking an application, and understanding what happened after you migrate, we work well for that. When you do a migration, there's a lot of politics involved.
This could be a great thing for your career or it could be a career limiting project. Around cloud migration, there's a lot of expectations. Anytime you move anything, whether it's from data center to data center, or from your private infrastructure to a cloud infrastructure, whatever changed must be the problem.

That playing game intensity rises. Assuming you do everything well and you get things there, there's a pressure to declare victory on multiple front. Those are everything from, "Hey, we had a performance improvement. We're starting to see some dollar stating."

Everybody wants to see that money. Because of those high expectations of moving to the cloud, what they want to see are new applications. When you think about moving to the cloud and the applications you are using to get yourself there, you want to get those performance and cost improvements, but you also want to think about how you're going to improve your overall ability to deliver software better, so you can get the new Apps and the new functionality that your business is expecting.
In terms of what you might buy from New Relic to reduce the risk of the migration, you can use APM, synthetic servers, and the cloud plug ins. Once you're there and you start building new customer experiences, that's where people start to use our mobile monitoring, our browser monitoring. That's when they start looking in very customized ways of viewing their software.

Next steps, we'd love you to go see a demo and try it out where they need you to try out. I also wanted to give you a heads up on to what's coming up next in the follow up email from this webinar which is a link to a recording. We've taken a lot of what David's talked about and put it in a white paper and that will be coming out soon. There's some other resources at the URLs for whatever you inquire. With that, I'd like to open the floor up for questions. We've got a couple here and you can see our twitter handles there as well. The first question is, "Are mainframe apps migrated to the cloud as well? Any examples?" David, I want you to take that one.

David: We've done quite a few mainframe applications. The examples are few and far between because those are very difficult to find kind of platform analogues put them in the cloud, but there are mainframe operating systems you can use and manage service providers and some cloud providers that support Mainframe systems. You have to assess them. What we find is 75 percent of them are not good to migrate, 25 percent of them are. People save money and time, and it will shut down extensive mainframe systems, and shut down parts of data centers which is the objective. Cobol DB2 is the ones that we run into. VCMIs and SAM are a little bit difficult to migrate. Don't give up hope. Start looking for the tools. If nothing works now and it's not economical now, wait a couple of years. Cloud providers are starting to pay attention in that part of the market. More tools and more technology is going to be coming down the road soon.

Abner: Next question is, "What kind of challenges have you faced in migrating application in the federal sector?"

David: Mainly getting funding. The federals started to come on strong in terms of cloud computing, but not getting the money and the funding they need to make migrations happen. The fed ramp were starting to get some traction in space and they're opening up some new cloud based migration efforts that are starting to pop up in procurement.

They're going into the hands of immigrators that may or may not be the best people to make a lot of those migration decisions and move people down that path. It's been frustrating for me because I've seen a lot in need and some very obvious value that can be gained by moving into the cloud. A huge amount of latency, and getting the funding, and getting the procurement in place, and getting us the right skills and place to make the right decision as to where to move the cloud. What I find is most immigrators are looking to migrate into their main service providers and call the cloud. It's not gaining values, it's not shared infrastructure, but things are changing. It's just going to take a long time for the government to be able to find value there. It's going to be 5 to 10 years more or so right now.

Abner: I'll make a couple of comments on that as well. We've seen a lot of net new development on cloud services in the government space. We've seen some high profile re architectures that are needed to be done that ended up on cloud services.
It's very much a new skill set. It's two or three years behind the broader market, but there's a demand there. If you look at some of the US digital service initiatives that Obama has put into place and the cultural effort there is to have services that are more agile and that you think like cloud services in order to iterate on government services. The next question is, "Have you migrated applications where the database is migrated first and then the application server? In that case, what kind of latency issues have you faced?"

David: I wouldn't recommend that you do that unless there is a concerted effort. With that field on architecture on what you're going to, if you're looking to move data into the cloud and still keep the application server local, unless the application has been optimized, so it's minimizing the chattiness. If you are able to make efficient calls and efficient returns, you may have some latency issues versus keeping it local way.

If the data is going to be an issue and it's going to be shared, there may be a business reason for doing that and technical reason for doing that. Unless you share it with other people, you're going to use the database from their application.
If you are coupling it and you're going to migrate the application into the cloud, once the data is there for a couple of years or a couple of months, that would be more problems than its worth. There could be instance where that's not the case, but generally speaking, that would be the case.

Abner: I agree with that. Next question is, "Can you talk about what the impact to a migration strategy could have if you did not have an integration layer like an ESB? Is that an assumption for a large enterprise?"

David: Immigration is always going to be something that's innate to any system whether it's cloud or not. You want to use an ESB, that's fine, but there's other technologies out there to consider. It's going to be important that you have somedate integration layer that you are able to leverage to to move information in between various source and target systems that exist within your enterprise over within the cloud.

It's a matter of extending whatever integration strategy you have, date and integration strategy you have to leverage cloud based systems. Most all of them out there do and know how to do that. It should be an easy thing to do. You do have to deal with latency in some instances, but it's not bad and the integration guys have done a very good job and reworked technology to make them more compatible with cloud based systems.

Abner: Next question is, "For mobile applications where the back end has started out on a small private server and is moving to a cloud service in order to scale, any particular considerations for a mobile app?"

David: Everything I brought up in the presentation. Security governance is going to be important. A number of people are going to be attacking the server because it's easy to figure out where it is. They're probably attacking your server now in a private space.

You're probably already used to how to defend for that. Look at the mobile application development tools out there. Some of the past systems support mobile app tools.

That's the easier part to use and train for everything yourself. Make sure that your applications you designed are not chatty, so you're going to be limiting factor in mobile applications that you want to minimize, the back and forth communications as much as possible.

Make sure there's resilient built within the applications that you're failing over to another instance of the back end system which in the cloud is awesome because you can run instances distributed all over the place and able to not have any outages around your service. The main thing is security governance performance and mobile developed tools, make sure you have a good understanding of that stuff.

Abner: As a follow on to the prior question about moving the data first, what about the opposite situation where the data is kept in a local data center, but the app is migrated to the cloud? What kind of latency issues are seen in this case? That's one that we see quite often.

David: Yeah, I've seen some clients there opting for that right now because they want to protect their data and keep it in a private data center where it's OK where the application is running outside. The same issues pop up in terms of latency because you are reaching over the open Internet unless you are using a private circuit...

Read more

Back to top icon