Understand why network performance monitoring is critical before, during and after any enterprise IT cloud migration to maintain visibility into end user experience throughout.
2. Network
Paths
Packets
Web/URLFlows
100% capture of the
actual data from the
packets on the network
Web synthetics to
baseline performance
as it changes over time
An active approach to
measuring health and
availability of the network
Who, when, and what
application traffic is
active on the network
4D
4-Dimensional Monitoring
4. How many of you are in the planning stages of
some form of migration project?
Audience Poll
How many are you currently in progress?
How many of you think you’re done and
completely moved to the cloud?
5.
6. Trust but Verify
When apps or app delivery changes, so must the network.
Rolling Migration
The truth of cloud migration is that it’s never done.
A Matter of Distance
Physical and Logical distance introduced for apps.
16. Visibility at every stage of cloud migration
● Before - Baseline performance of existing infrastructure
● During - Troubleshooting/quality control through migration
● After - Maintenance/improvement of cloud environments ongoing
of
all enterprise workloads–including
those deemed ‘mission critical’–will
move to the cloud over the next 12
months.
— Oracle 2019 Cloud Predictions Forecast
80%
17. Thanks for Sticking Around
Giveaway happening now!
Amazon Echo Dot Google Home MiniGift Cards
Editor's Notes
Hi everybody, thank you for taking time to spend the next 10 minutes or so joining us for a quick discussion on cloud migration, my name is Alec Pinkham, I’ve been at AppNeta for over 4 years and I’m the Director of Product Marketing. Before you run for the hills I’ll note that I do have an engineering background.
This will be a bit broader than some of our other presentations today, but when it comes to Cloud Migration we’ve seen monitoring too often left as an afterthought coming into the discussion only after the app experience doesn’t meet expectations.
Tease the how, AppNeta offers 4 dimensions of application and network monitoring that combines active and passive methodologies to help IT teams reduce resolution times and better understand the networks they rely on to serve business-critical applications. I’ll get into these a bit more when we look at the product, but wanted to set the stage a bit by putting network paths, packets, web synthetics and flow into your heads.
We’re solidly in a Cloud Era of the enterprise and (two types) migration often refers to moving internal apps to cloud infrastructure, but it can also encompass a new dependance on SaaS apps consumed from the cloud. Both come with a certain level of visibility loss. With capital M ‘Migration’ you’re replacing most of the infrastructure between the user and the server and (vs.) with SaaS adoption you’re replacing all of it.
//
Caveat is that there are business cases for not moving certain apps to the cloud. But they usually don’t apply wholesale to every app in an organization. At this point there are very few companies that can make the case for completely siloed, private networks.
High-frequency trading where microseconds matter can’t roundtrip through a CASB service before making a trade.
Legacy apps that require direct access to huge databases would likely fail spectacularly if you introduced additional latency in requests.
But moving apps or workflows into the cloud is not always simple — especially when it comes to managing expectations, and actually delivering improvements once migration is complete.
source: https://www.pexels.com/photo/atmosphere-blue-cloud-clouds-601798/
Let’s get a few data points…
How many of you are in the planning stages?
> Either transitioning to a SaaS app or migrating an internal app to some form of cloud hosting?
How many of you are currently in the middle of some form of migration project?
How many of you think you’re done with cloud migration, finished, completely moved to the cloud?
#Rolling migration - once you start cloud migration you gain expertise and you can find other opportunities in the cloud, but each one is it’s own journey.
I wanted to start by talking about some clear winners of the Cloud Era.
Amazon is the poster child of the cloud in their transition from Amazon.com to market-leading AWS. But even they migrated in pieces, not all at once. They built solutions for specific problems and pivoted those into products. For true migration, utilizing cloud services like S3, SQS or others Amazon allows you to roll out different pieces starting with 1 component of an app.
This is true across cloud providers, but Microsoft has actually pushed to make it as simple as possible to move your C++ or C# apps into Azure, capturing a segment of the market not looking to rewrite entire legacy apps.
Netflix in the early days is similar in the way that they saw specific problems and fixed them by scaling cloud infrastructure. But they had a different problem. Their customers want faster and faster access to movies and shows. Netflix actually almost created a device for overnight downloading of movies before they took a hard look at YouTube around 2005. But it wasn’t until 2011 until they figured out distance. Movies in the cloud was a great idea, but we’ve moved it so far from the user that they need to create their own content delivery network to overcome latency concerns on the internet.
https://media.netflix.com/en/company-blog/how-netflix-works-with-isps-around-the-globe-to-deliver-a-great-viewing-experience
So there are some Key Themes here
Migration is never finished. You’ll likely be in some part of the process for a while on one app or another, one project or another. Even with Amazon and Netflix a migration wasn’t the flip of a switch. These are multi-year projects where when you’re done with one, you start another or run parallel tracks with smaller teams.
There’s also an issue of distance. Moving to the cloud is introducing physical and logical distance between user and app regardless of app type (internal/SaaS) - Changes in apps have caused dramatic changes in our networks.
AppNeta’s approach has been trust but verify because with migration to things like hybrid multi-cloud you’re essentially just a rack in their data center. You can’t plant a flag down in Google’s infrastructure so you need to proactively look at what’s happening. When a packet leaves your network you’re blind. How do you know that your 30ms SLA with Express Route is what you’re actually getting? How do you verify if your ISP isn’t throttling connections speeds. This is where AppNeta can help.
//
- so we have things like forklift problem where the way apps are built are not designed for the latency of the cloud - so that’s what blows up - 1,000s of queries happening which didn’t matter in the DC, but it blows up when you’re in the cloud
and what it boils down to is a matter of expectation - users/execs expect the experience to be better (or at least stay the same). I’ve heard the CIO of GE talk about IT being really about delivering an outcome and cloud migration is often about delivering those outcomes faster.
35% wasted cloud spending (RightScale) - https://www.forbes.com/sites/joemckendrick/2018/02/15/too-much-corporate-money-is-evaporating-into-the-cloud-survey-suggests/#3bdc08971c18
seth
travellers - we’re just a rack in their dc, we don’t have a flag to plant down on that, once a packet leaves our network we can’t see anything
direct connect or express route- need to verify (if your SLA is 30ms from anywhere in the world)
// Apps are moving to the cloud, but orgs are still using networks/architectures that are designed for when the apps sat in the data center. So you either end up with the high cost of backhauling traffic and poor end-user experience OR you can change the way you access them. You can toss SD-WAN into the mix, but if you have a large number of remote locations we’ll have to look cost-scaling and likely bring in some way to secure the branch so maybe a ZScaler or other CASB service. Both SD-WAN and CASB will centralize services and allow for quicker changes, but you’re giving up a bit of the control/visibility.
At the end of the day though, IT will likely be charged with delivering and measuring the outcomes of cloud migration, even if it’s occurring outside of your budget or outside your visibility.
So that’s where AppNeta comes in. We provide the tools you need to identify the current state of application and network performance [click], establish a baseline before you change anything [click] so that after migration [click] you can compare and prove that the system is running better than before. And finally because much of the infrastructure is now out of your control, [click] you can establish continuous monitoring practices that can help you proactively identify issues even before users are impacted.
So this is really a continuous loop though, or at least multiple tracks running in parallel because we never have the luxury of one-project-at-a-time.
Of course, AppNeta can help with this. Let’s start by first discovering the applications in use on the network…
in both U and E - did you know this app depended on all these 3rd party services? U shows all these systems that are talking.
Azure story - take the apps you used to have on-prem and just toss them in Azure - so easy transition to cloud, but now a black box (MS core app - now running as a serverless arch. sharing with the rest of the internet
// Early copy
The baselining that teams conducted before migration needs to be redone for comparison once the new network architecture is in place. The key here is to use the same processes (usage, patterns, time, etc.) that was tested over the old network.
With all cloud migrations, there is some level of control that is lost. Whether that is at the bare metal, OS, or access levels, it’s also important that teams are using modern monitoring solutions that can deliver the same level of visibility into the cloud.
Let’s look at how AppNeta discovers applications.
These boxes [pick up devices], virtual or physical sit at your locations. They actively and passively monitor the network. We generate NetFlow records from the raw packet stream and layer on DPI intelligence to identify applications and while you can use this to identify apps on the network, isolating issues to specific apps, locations or even users, but for cloud migration we can also use this info to look at conversations that are occurring between apps.
So we can use this to identify dependencies between applications. We can understand all of the applications and endpoints that an app talks to. Then, when we’re considering moving one of these to a cloud environment we can fully understand what the full impact might be. If this internal app actually depends on a few other services then you’re introducing additional latency for every one of those calls. If that app needs to make thousands of queries that didn’t matter in the data center, but it’s going to blow up in the cloud.
We need to zero in on the “current state” of the network and application performance to compare before and after.
Now let’s look at some active testing. Since the network will be changing during the process we need something that will give an accurate representation of the user experience. For this we turn to synthetic transaction monitoring combined with active network monitoring.
We use Selenium-based scripting to periodically check not only the availability of your business critical apps, but also provide deeper interaction metrics to mimic how a real user looks at experience, so steps beyond login into the real functions of an app. Not only how fast are apps currently being delivered to users with network, server and browser breakdowns, but aggregate metrics into Apdex scores, pull in data from DNS to see which server responded the fastest and look at external calls to 3rd party APIs or servers.
For applications, this is one example of one script execution against Salesforce, but compared to legacy applications we have a vast difference in resource timings and domain listing. I want to call out domains specifically because with something like salesforce there are a whole host of 3rd party API calls that can be exposed with this type of testing. The truth about salesforce is that they do a pretty good job of keeping their app up and running, but it’s all of the plugins that make pages load slowly that get blamed on them. So much like the network, users blame the underlying platform or infrastructure, but not the real source of the problem.
Lastly I mentioned that cloud migration is never complete. Once you’ve moved an app to the cloud you’re relying on your ISP or MPLS vendor, the cloud infrastructure and in general connections that you can’t monitor with traditional tooling. AppNeta provides the visibility into the networks that you depend on post-migration. If traffic goes through SD-WAN, CASB services, MPLS or other VPN links, or even direct-to-internet over an ISP we can actively monitor those networks as they change from your local networks into cloud or SaaS vendor infrastructure.
This is actually an interesting one from a couple of months ago where Skype had a global outage. Many of us have moved from hosted UC solutions to something like Skype for Business, Zoom, or others, but when the Skype Anycast address went down all inbound traffic stopped at the ISP. Without some kind of route visualization outside your firewall how do you know 1) who to call and 2) what’s actually wrong with the system. With our Route Visualization it’s pretty clear that this is a Microsoft issue. Every hop right of the outage is owned by them.
If you want to find out more then come get a demo after the presentation at either of these stations. AppNeta can help get you visibility back in the cloud era and allow you to identify performance before, during and after each discrete cloud migration.
You can’t manage what you can’t measure
The problem with legacy network performance monitoring is that it’s ill-equipped to deliver insights into network environments in the cloud.