Today on Day Two Cloud we examine global network performance of some of the biggest public cloud providers. Sponsor ThousandEyes, a Cisco company, has a worldwide network of sensors that measures performance to, from, and across AWS, Azure, and Google Cloud. ThousandEyes shares results gathered, as well as analysis, in 2022 edition of its Cloud Performance Report.
We’re joined by Angelique Medina, Head of Internet Intelligence and Director of Product Marketing at ThousandEyes, to examine surprising data points and key findings of the report.
We discuss:
- Highlights of the 2022 report
- Why small outages can be as impactful as big ones
- Cloud performance is not a “steady state”
- Why cloud-to-cloud performance looks pretty good
- The role of networking in cloud design and application performance
- More
Show Links:
Cloud Performance Report 2022 Edition – ThousandEyes
@thousandeyes – ThousandEyes on Twitter
Transcript:
[00:00:10.570] – Ethan
Welcome to day two. Cloud. And on today’s episode, we’re talking about network performance between public clouds. Our sponsor today is Thousand Eyes and we’re going to be discussing their cloud performance report that they published for 2022. This is the third, 3rd year that they’ve done this and they have got a lot, a lot of data in this report. Then we’re going to talk through some of the highlights that are going to explain maybe some thoughts about where to place workloads, how to design your application so that you’re getting the sort of performance that you’re looking for. Ned, who would normally be with us today, had a scheduled conflict. And so Drew Conry Murray, who you know from other shows on the Packet Pushers Podcast network, is substituting his co host. Drew, what stuck out to you in today’s episode? [00:00:54.910] – Drew
Yeah, there was a lot of stuff. So things about just a reminder that the cloud is not steady state network performance is going to change over time. So it’s good to have sort of a finger on the pulse of the most recent information so you can make the best architectural decisions. One thing that really jumped out at me is some conversation around multicloud connectivity, which among the big three cloud providers in the US is actually really good. They’re using direct interconnections, which is a lot more friendly than I would have anticipated in a hotly contested and competitive environment. [00:01:21.530] – Ethan
Yes, I agree with that point. That stuck out to me as well. But we’re going to let the Thousand Eyes team share their information with us. Our guest today is Angelique Medina. She is the head of Internet intelligence and Director of Product Marketing at Cisco Thousand Eyes. Enjoy this conversation. Angelique. Welcome back to the Packet Pushers Podcast network. Today on the day two cloud podcast. And we’re talking about the Thousand Eyes third annual Cloud Performance Report. Now, honest question because I’ve looked through these reports and they are intense, lots and lots of data in there, but are you still discovering data points that surprise you? [00:01:58.390] – Angelique
Yeah, absolutely. I mean, there was a lot here that I didn’t expect. And what was particularly interesting about this report is that we were looking at three years worth of data because the last time we did this report was back in 2019. And of course, a lot has happened in the meantime. So it was really interesting to see not only what performance looks like today in 2022, but also how it evolved over time. So there was a lot to take in and it took us a bit of time to sift through all of it, but hopefully it was worth the wait. [00:02:30.990] – Ethan
Yeah. If you folks haven’t downloaded this report yet, there are lots and lots and lots of matrices of data, graphs and so on to help you understand not just how the public cloud providers are performing, but how they perform in and amongst each other and all sort of different endpoints crossing the different cloud provider networks. So lots and lots of information to chew on. Angelique, why don’t you highlight some of the most interesting data points from this report? [00:02:58.730] – Angelique
Yeah, absolutely. So just to set the stage in terms of what we actually looked at with the report, so we were looking at three of the major providers just in terms of market share. So that was AWS, microsoft Azure and Google Cloud. And we were looking at primarily three different types of latency measurements. So we were looking at interaz. So effectively the latency within a particular region between availability zones. We were also looking at inter region traffic. So this was traffic between regions within a particular cloud provider. So for example, it might be us, west one to us, east one within a particular provider. And then finally we were looking at end user measurements. So these were latencies between different locations around the globe where they were connecting from an Internet or a transit provider into a cloud to a particular region. So those were primarily what we looked at. We looked a little bit of multicloud as well, but just to give you an idea of kind of the scope of what we were looking at. [00:04:11.470] – Ethan
So before we get into the data points, how did you generate that data? You’re saying you’re taking latency measurements. These are between thousand eyes endpoints that are taking the measurements, right? [00:04:22.320] – Angelique
Yeah, that’s right. So we’re effectively doing bi directional test from two agents. So these are agents that we controlled. They were either within the cloud provider or they were within a hosting facility outside of the cloud connecting in. But these were effectively agents that were in place in the same configuration over a lengthy period of time. So, yes, we’re using thousand eyes to collect these measurements. [00:04:51.560] – Ethan
And so not just ping traffic, but other sorts of traffic as well to take the measurements. [00:04:56.050] – Angelique
That’s right. So not just looking at end to end performance, but we could also look at network path. So using sort of a form of trace route, we could actually map the path between these agents that we were testing. And that revealed a lot of really interesting data just in terms of if we saw, for example, excessive latency, then what we would expect. We could actually go down, drill into it and see where and why that latency was occurring. So that was particularly interesting. [00:05:30.250] – Drew
And when you’re doing these tests, is it just a couple of packets or can you actually send some fake traffic or real traffic you can replay? [00:05:38.410] – Angelique
So we were mostly just looking at active traffic. This was really just network measurements. So we weren’t looking for example, we weren’t testing to like a web server or anything like that. This was just VM to VM. [00:05:55.650] – Ethan
So, Angelique, let’s highlight some of the key findings now that we understand how you’re doing the measurements. Yeah, what percolated to the surface in this report. [00:06:04.930] – Angelique
Yes. So there’s a few things. One of them that I thought was particularly interesting was just looking at a particular change from the previous report. So in the previous report, one of the things that we surfaced was that the latency between points within Europe and Southeast Asia for Google, and that was the same whether it was interregion, so traffic just going along their backbone or coming from users who were in Europe or in Southeast Asia, that the latency was extremely high. So it was three times what it was with AWS Azure or what we would expect within an interrupt service provider. And so we were really interested to see what had changed, if that had in fact been fixed, because it was really excessive and not something that you would expect. And we did see that in fact, performance is now closer to it’s, more in line with the other providers and what we would expect to see. But what was particularly interesting was how this fix unfolded, because they, they put in infrastructure or, you know, had basically direct connectivity put in between Europe and Southeast Asia. They announced that in 2019. And then when we were in in 2020, we started to see them rolling out this new route and they rolled out their interregion traffic first. [00:07:26.400] – Angelique
So end users that were connecting from those particular points or those locations, they didn’t start to see an improvement in performance until about six months later. So that was really interesting just in terms of how Google was kind of tearing the rollout of this new route and so kind of prioritizing their own backbone traffic and then going to the end user traffic. And even that was tiered, because we saw that if you were connecting from certain cities, you might have been kind of first in line for that route change or that optimization. And then there were others that took a year before they started to see that implemented. So that was a particularly interesting thing just in terms of a lot of people don’t realize that of course, the cloud providers are like any network operator. They have to make choices about how they’re managing their network. And sometimes that may or may not align with what you expect. [00:08:29.910] – Drew
So I’m assuming when you’re talking about a new route between Europe and Southeast Asia that we’re talking about in undersea. [00:08:34.730] – Angelique
Cable, well, I mean, that’s interesting because it could be. I mean, Google, they really do favor kind of using their backbones. So if you’re connecting from, let’s say you’re connecting from London and you are connecting to a region in Singapore, your traffic is going to get into Google’s network probably within just a few hops. So you’re going to get into Google’s network in London and then from there, there’s really kind of a few different ways that you could get to Singapore. I mean, you could go through the Atlantic Ocean, across the US. And then across the Pacific Ocean, you can go that way or you could go there’s a number of different subsea cable lines connecting Europe and Asia, so that’s also an option. But again, this is all shared infrastructure. So it seemed that they had put in some better optimizations in terms of whether they were provisioning capacity on cables that offered better performance. It’s not entirely clear what specific route they were rolling out that improved it, but it was pretty dramatic just in terms of the performance difference. [00:09:56.830] – Ethan
Well, you’ve got right that much less latency, depending on which direction it goes. If it heads, as you said, across the Atlantic, North America, Pacific, you’ve got what would that be? 250 ish milliseconds, 300 milliseconds, something like that, versus going over the Eurasian continent. It’s just got to be lower, right? [00:10:16.790] – Angelique
Yeah, I mean, it depends on where you’re trying to connect to within Asia. If you’re in Tokyo, it might be faster if you’re connecting from London to go through the United States if you’re like. For example, in India, it’s going to be faster if you’re connecting via the subsea cables that go through the Indian Ocean. So it really just depends. And what’s kind of interesting about that is that the providers, it depends on the providers. But one of the things that we were seeing is that they use both routes in a lot of cases. So sometimes, for example, connecting the UK to Japan, they might take the slightly longer path that’s going through cables running through the Indian Ocean. And sometimes if they were connecting to, for example, Southeast Asia, they might go through the US. So there was a lot of variation just depending on which path was being taken. And sometimes we were seeing that change. It seemed almost like in some cases it was dynamic because we would see it was going one route one day and then it might be going another route the other day. So that’s kind of an interesting thing just in terms of how they’re making these changes. [00:11:35.340] – Angelique
In many cases, what looks like dynamically probably depending on what else is going on within their network. [00:11:44.670] – Ethan
Angela, you may have answered my next question here, which was, do you think that the way that routing is going, is it BGP driven or is it some kind of traffic engineering? [00:11:54.310] – Angelique
It seems to be the latter, just based on all of the different changes that we see. And in some cases it looks like it changes relatively frequently, which is not necessarily something you see if it was just BGP based. [00:12:10.410] – Ethan
Right, okay. Well, another point of clarification here. You’d mentioned that when that new route went in, sometimes it would just be backbone traffic that would traverse it, and then sometimes customer traffic would also be backhauled across it. So if there was plumbing in place between two pops, let’s say, on that cloud, would you see customer traffic and backbone traffic originating between the same two points meant to travel between the same two points, customer traffic would go around the globe the other way and backbone traffic would go across the new route. [00:12:45.970] – Angelique
Yeah, I mean, what’s kind of interesting is that the excessive latency that we were seeing back in 2019 isn’t just explainable given the particular route that you’re taking. So whether you’re going via the US or if you are going taking a more direct path. So it looks like something else was happening within their network to contribute to that excessive latency. But for sure we definitely saw the more direct path used for backbone or kind of region to region traffic much sooner than we did for end user traffic. There’s different handling taking place for sure. One kind of data point on that I think while we’re recording on December 6, but yesterday, December 5, AWS had a pretty sizable network outage and this happened over the course of a little more than an hour and it really only impacted traffic that was coming off of the internet. So it was kind of end user traffic, it didn’t affect their backbone kind of region to region traffic and it only impacted certain traffic that was coming from certain service providers. So there are effectively different ways in which they’re kind of routing and engineering the traffic from one location to another, whether it’s from their own region or from customers. [00:14:21.250] – Drew
Yes, this is a finding that you call out in the report and that cloud providers are showing preferences in managing their network specifically for how they’ll either fix issues or optimize performance. And I think the impact or the import is for customers that if you can sort of glean what their preferences are, maybe you can sort of align your own priorities with theirs because you may not know what their priority is that could affect your own performance. [00:14:46.740] – Angelique
Yeah, for sure. And I think also it’s helpful to know what’s going on because then it can facilitate a conversation with your provider because in some cases some of these things might be unintentional. They run these massive global networks and in making some changes it might lead to something that they didn’t expect and so you would want to make them aware of that. But also depending on where you’re located, there are certain regions that we were seeing were kind of at the back of the line in terms of some of these optimizations that were made. So if you kind of know what you should expect in terms of performance and you’re not getting that, I mean that is something that you obviously want to raise with the provider and try to facilitate some fix. But based on evidence and based on what you should expect from the provider. [00:15:40.870] – Ethan
Well, do you raise the issue with the provider? Hey, I’m not getting as good performance in this site as I would like? Or do you just say, I’m going to pick up my workloads and move them to where the data says the performance is the best? [00:15:54.290] – Angelique
Yeah, I think that when you’re considering your architecture in which regions to choose, you want to be looking at data at that point for sure, to understand what you’re going to get and what to expect. But then things change. One of the things that we talk about a lot in the report is that there’s really no steady state in the cloud. So what’s true today may not be true tomorrow. And you may have made your or put your deployments in place based on measurements and kind of performance data that you collected during your planning phase, and you may not be getting it. And sure, yes, you probably could change regions and kind of uproot and go elsewhere, but it’s not trivial and a lot of organizations that’s not necessarily going to be their go to. And so thinking about how you engage with your provider and actually manage the level of service that you receive is really an important part of any cloud management kind of strategy and operations. [00:17:05.430] – Drew
Yeah, I think a good example of that is the Google example you brought up earlier, where some new route or new capacity came online that’s changing the way they’re sending traffic from Europe to Southeast Asia. And if you built an application that’s running in Southeast Asia based on older numbers, you may want to rethink what you’re doing. You may have made decisions about latency and so on that are no longer relevant. [00:17:27.110] – Angelique
Absolutely. For sure. That was an interesting kind of piece in terms of I think it also speaks to the fact that the providers really do care about their performance. And in a lot of instances in which we’ve pointed out maybe less than optimal performance, they’ve been very responsive in fixing issues. So I think at the end of the day, if you’re able to be specific and kind of point out areas where you see an opportunity to improve that, you’re likely going to get a positive response. But ultimately it’s going to come down to data because they have a number of customers and they’re not necessarily going to be just hyper focused on ensuring performance for you specifically, just sort of one organization. They’re not an extension of your It department or your cloud operations team. So you kind of have to do that for yourself, where there’s things that you can’t optimize yourself, know that you can be more collaborative with your provider. I think it’s kind of interesting. [00:18:44.550] – Ethan
Yeah, well, I think they do actually care, maybe some more than others. There’s different tiers of customer service than the public cloud providers. But here’s an anecdote from a thread that I spent some time reading on Hacker News. It wasn’t about network performance specifically, but it was about Azure and their capacity to spin up new workloads. Oh, sorry. In this particular region, we don’t have enough capacity for you to spin up whatever it was that they were trying to spin up. And this person was expressing frustration. And as the thread went on, someone I think they worked for, Azure maybe, but they popped up and said, hey, one of the things we struggle with is capacity planning. So the way you can help us with that is by letting us know we’re betting big on this region or we’re going to be spinning up a bunch of workloads in this particular region. And so they would know then, hey, our customers are going to want to have more presence in these areas. We need to have more physical capacity in those areas. Now they were talking about bare metal servers and stuff like that. But I think that extends to this networking discussion as well. [00:19:45.050] – Ethan
If you know you’re going to be putting a lot of workloads into a particular area and you want your performance to be good, you should let your cloud provider know we’re building in this region over the next year. Please be ready for us. We’re coming. [00:19:58.670] – Angelique
Yeah, absolutely. And I think what’s kind of interesting about that is that if you’re in the cloud, it’s very different than the traditional model that a lot of folks may have gotten used to with, for example, service providers or transit providers where you have an SLA for whatever reason. With the cloud providers, that model was never really put in place. And so you don’t have the same kind of management structures or the same opportunity for accountability just based on service level agreements, for example. Or if there are SaaS in place, they’re practically unenforceable. So the way to kind of think about this is almost like a service level relationship rather than service level agreement. You know, how do you put structures in place in order to facilitate you having these more constructive conversations with the providers? So to your point yeah, just communication, I think is. [00:20:58.370] – Drew
Take your provider out for a steak dinner. [00:21:00.870] – Angelique
Right? I lifted that from a colleague. We were having this conversation and he was like, yeah, the SLAs, they’re kind of dead in a lot of ways. You have to think about it. It’s a service level relationship. I was like, I like that. [00:21:16.950] – Drew
Send your client writer a holiday gift. [00:21:19.310] – Angelique
Exactly. [00:21:21.370] – Ethan
They’re people and there’s teams there that do actually care about you. And there are reps and humans you can talk to. And again, some seem to have a better reputation than others. AWS has a better reputation for customer service. Calling up and getting things fixed, for example, than GCP seems to be lower than the total poll in that regard. Where they kind of don’t want to talk to you is the vibe I get. Anyway. Angelique, you had mentioned steady state in the cloud. There is no steady state in the cloud. We’ve been kind of talking about that, but you dive into that a little more. The point you’re making is that things are changing in the cloud networks all the time. And so you can’t assume because you have good performance one day, you’ll have good performance forever. Or conversely, if it’s terrible right now, it might not be better in the future. [00:22:09.370] – Angelique
Right? Yeah, we kind of saw this manifesting in a few different ways. So to your point, the cloud provider networks are constantly changing. They may be putting new regions in place, they may be expanding. There’s also a lot of infrastructure that’s just like shared infrastructure that’s come online just even in the last few years. So, for example, there’s like cable, new subsea cable between Perth and Singapore. And we saw when that was put in place that that improved performance for a couple of the providers. So there are things that are just kind of changing in terms of the infrastructure. But also there was some things that weren’t necessarily explainable that might just be anomalies. And again, where you may want to point things out to your providers. So, for example, there was a point in time and this wasn’t just like something that was brief. This was like over a six month period, we saw that performance between Azure’s Korea region and really every other region that they have was like three or four times what it was at their baseline. And so, you know, that was, you know, pretty pretty extreme increase in performance. [00:23:30.750] – Angelique
And then after six months, it just kind of went back to its baseline. So, you know, there there absolutely are things that are happening that are like brief anomalies, and of course those have to be managed, but there may also be things that are more systemic where you want to think about how you can engage and manage around those as well. But, yeah, I think it was really interesting how things were constantly changing and those could happen over the course of a month. There was a lot of instances in which we were seeing, particularly in Asia, I would say there are a lot of outliers there’s, like a much broader spread of performance measurements that we would capture, for example. So there’s just greater variability in certain areas of the world, and that was even within the cloud provider’s backbone. So I think it was pretty surprising to me that even so there was over time, yes, there were changes, but also, just even within a 30 day period, looking at, like, the range of measurements between point A and point B. It was in a lot of cases and dependent on the provider. It was really kind of extreme just in terms of the kind of measurements that we were taking. [00:25:00.190] – Ethan
Angelique so we were talking about how the nature of a cloud provider’s network changes and it changes with some frequency. You can’t just assume the performance envelope is going to be the same all the time. You also mentioned earlier in the show that AWS had an outage that impacted lots of different providers and so on. That was a thing which isn’t even a headline anymore. Should we just be counting on there being performance issues and outages and so on and the cloud providers? [00:25:28.570] – Angelique
Yeah, it’s interesting that you bring that up because I know that there have been really huge outages that get a lot of attention. And those are maybe not as common as the incident that you just mentioned, but I think a lot of people give the providers a pass and just sort of assume that everything’s going to work, they pay for this service and everything’s going to be great. And the reality is that they’re actually much more common than a lot of folks realize. And whether it was an hour outage that we saw the other day or other kind of maybe smaller scale, more systemic things or just things that are kind of changing all the time, you really have to assume that. There’s going to be challenges, there’s going to be problems, and then figure out a way to implement some management practices that are going to deal with that effectively. [00:26:33.870] – Ethan
It’s funny that performance issues can be major scale where lots and lots and lots of people notice and are affected because their apps are down or performing poorly. And then there can be just little things that are an issue. Not that long ago we had a problem on one of the VPs services we use to host a website with a noisy neighbor. Everything was fine, everything was operating okay, but the performance of the website was rather slow and that was the troubleshooting process. Oh yeah, the metal that your site is provisioned on is just overloaded, I don’t know, crypto, mining, I don’t know what was going on, but some neighbor was doing something noisy. So a very small scale, sort of a problem, which just goes back to the guidance we’ve been getting from the cloud providers anyway, which is you need to be thinking about application resiliency, you need to be spreading your workloads out, you need to be able to survive some kind of a problem. You can’t assume that just because we’re AWS, Azure, Google cloud that everything’s going to be 100% fine all the time, because it isn’t. You should assume that just like in your own data centers, there might be problems, they’ll have problems as well. [00:27:40.920] – Ethan
And so you can’t just throw application architecture out the window because the cloud will take care of it for me. [00:27:46.470] – Angelique
Yeah, for sure. And that was a good example that you brought up because it’s funny, I was talking to someone the other day about these really large outages that get a ton of attention. They get a lot of people talking about them, a lot of applications impacted. When that happens, there’s a little bit of hurt immunity. Like if everybody is sort of equally impacted, then it’s like, okay, we can point to the cloud provider. It’s not my fault, but there’s those smaller scale things where it’s like, okay, maybe it’s just one particular route or kind of a more localized issue and it’s impacting you. And your website is slow, your application is slow. Well, there’s no big headline talking about a cloud outage. This is all on you. So in a lot of ways those can be even more damaging in terms of kind of the perception of responsibility because they’re not these sort of like big massive, the cloud is down type events. [00:28:58.650] – Drew
Yeah, that herd immunity is lost in some of these smaller outages. And that’s, I guess, again, why the visibility that sort of having an up to date picture of performance and not assuming it’s going to be the same should tie into your application design, your resiliency design. Okay. Another thing that I noticed in the report, you were talking about multi cloud connectivity. So between the big cloud providers, which seems good, and it seems like they’re using more direct interconnections with each other instead of going across the Internet, do you see this as sort of a sign of agreed upon cooperation among the big three on how to interconnect with each other? [00:29:33.110] – Angelique
Yeah, that’s a good question. To your point, it was pretty interesting to see just how interconnected the providers are. I mean, they’re in a lot of the same exchange points and they peer extensively with a lot of providers as well. But for traffic that was going from a region in one provider destined to a region within a different cloud provider entirely, we were seeing the traffic just getting handed off directly from one provider to the other. So as you mentioned, it wasn’t going over the public Internet, which I think is good news for organizations that might have not just multicloud from the standpoint of how they’re architecting their own application, but a lot of applications today are using best of breed API services. And those services, those apps might be in a different cloud provider. And so knowing that that traffic is more likely going to stay within the, quote unquote cloud is probably good news from some folks. Not to say that the internet is sort of inherently bad, it’s just that it minimizes kind of the handling of the traffic across multiple providers. And certainly we’ve seen issues with internet routing where there might be BGP issues or whatnot. [00:31:01.650] – Angelique
Yeah. [00:31:02.050] – Drew
So the reason I found it surprising is that there is, I guess, an element of competition here where I want to keep my users within my own cloud as much as possible. But the fact that you’re mentioning this push toward multicloud and folks having API connections to services in different clouds, maybe there’s sort of this shared fate where, well, they’re using a piece of my cloud, so I want that to work well. So I will, I guess, have this friendly interconnect relationship with my competitors, essentially because we have. This shared fate, right? [00:31:31.820] – Angelique
Yeah, I think that’s a good point. And this is pretty common where you’re going to be a lot of your customers are going to be connecting to things that are in one of your competitors clouds. And so especially given the proximity where they peer, it probably makes sense for them, right? [00:31:58.160] – Drew
If I’m providing a service that relies on a service in provider B, but my customer thinks I’m at fault because of a slow response from provider B to provider A, I look bad. So I guess maybe there’s that willingness to cooperate on things like that. [00:32:15.420] – Ethan
Angelique that’s actually a good follow up question. Maybe a way to close this podcast out are some takeaways for what do we do with all of this information as cloud operators, folks that are building and standing up clouds? Because on the one hand, I could look at the clouds and go, okay, I’m going to stand this up in US east and off I go, that’s going to be good enough. Or I’m going to put a workload in Chicago because I know Chicago is well connected. I’m not going to think about it anymore. But what the data suggests is that the decision about where to place workloads is a lot more complex and I’m almost I’m not sure what to do with all of the information. Angeli can you, can you give me some guidance? [00:32:58.300] – Angelique
Yeah, absolutely. So of course performance is going to mean different things to different organizations depending on their use cases, their applications, who their customers are. So the specific performance measurements that we have in the report are really kind of guidelines. I mean, it’s good information and it’s helpful to understand how the cloud providers operate and what you can generally expect. But in terms of what you can do with this information, I think it’s really important to consider latency and performance throughout the full kind of life cycle of your cloud deployment. So whether that’s from a planning phase as you’re rolling out and then as you’re managing, or during your operational phase, ensuring that you’re continuously getting the performance that you need. So the report itself is sort of meant to be a bit of a framework for that and giving examples of what you can expect and how you can then get this data for yourself and use that to better manage your performance with your cloud provider. [00:34:10.560] – Ethan
You didn’t give me the easy button. The takeaway is pretty straightforward then, but it is a complex one. Also. It’s straightforward in the sense of, okay, you have to understand your application architecture. Where are you going to place your workloads? What that means to the customer facing side of that app, but then also the back end of that app and how all of the different services that make up your application. Are interacting and then make intelligent decisions about whether it’s latency performance, the latency between the different services as they’re interacting between regions, and then how to group all of those things intelligently so that you’re getting the performance that you’re looking for. And it’s not necessarily as straightforward as group it all together. You may have to put a lot more thought into it and then to know what we mean by a lot more thought. It’s all driven by the data of which there is I don’t think it’s hundreds of pages, but it’s at least dozens of pages of data that can show you what your connectivity looks like between different regions where you might be putting components of your application together. [00:35:18.520] – Angelique
Yeah, absolutely. And as you said, this can get pretty complicated because there’s the performance that you can expect from a network standpoint with your cloud provider, but there’s also other variables in terms of other services that you’re connecting to and even where you’re connecting from, whether that’s your customers that are out on the internet connecting to you through different service providers or just in terms of getting to your Cloud Management console and connecting from some point out on the internet. Or it could also involve do you use Direct connect, do you connect to your VPC over VPN? These are all these things that have to be weighed and it can get pretty complicated. So you want to make sure that you’re using data to make these decisions. [00:36:19.180] – Drew
I’m curious if you’re hearing from customers about the networking element of cloud and that I assume when most organizations are having a cloud, designing an application for the cloud, they’re thinking about cost, they’re thinking about developer preference, they’re thinking about what tools to integrate with and maybe the network is not top of mind. Is there a way to make sure networking has a seat at the table to say, hey, here’s some issues we need to think about, about location, latency performance, all of that? [00:36:44.100] – Angelique
Yeah, I think that’s an interesting question. Talking to a few different folks on this. It seems like the network performance piece may in fact get factored in when there’s effectively the architecture planning. But then when you get to the operations phase, it’s sort of like, okay, well, I think I know what I’m going to get, and I’m just going to assume that that’s the case. I think it’s really about ensuring that the network piece, which is effectively what’s gluing all of these things together, is factored in because it’s probably the networking. [00:37:23.930] – Drew
People who are going to get the first phone call when there’s a problem. [00:37:26.610] – Angelique
They always are. [00:37:30.560] – Ethan
Angelique this has been a fun conversation. We have learned a lot of things that I wasn’t expecting. There was a lot of data in that report that just looking at things as the armchair network designer would have assumed, things were different than what the data has uncovered. For people that want to download that report, where do they go? [00:37:49.400] – Angelique
Right, so you can go to Thousandis.com, so go to our website. We have a resources section and you can download the report there. [00:37:58.230] – Ethan
This is the Cloud performance report for 2022. You can also find Thousand Eyes on Twitter. They are at thousand Eyes, and of course you can find them on LinkedIn. And if you want to read their blog, some really good technical content there thousandis Comb. Our thanks to Angelique Medina for joining us today. And our thanks to Thousand Eyes, a Cisco company, for sponsoring today’s episode. And virtual high fives to you for staying all the way to the end. If you have suggestions for future shows, you can ask us anything. You can hit either Ned or I up on Twitter at day two Cloud Show, or fill out the request form on day twocloud IO. And if you like engineering oriented shows like this one, and I know you do, visit packet, pushers net subscribe. All of our podcasts, newsletters and websites are there. It’s all nerdy content designed for your professional career development. And until then, just remember, cloud is what happens while it is making other plans.
Podcast: Play in new window | Download
