Building smarter technology at the edge with Verizon 5G Edge & AWS Wavelength | Verizon
Hello, my name is Elise Neel and I'm the SVP of New Business Incubation at Verizon. I'm here today with my colleague, Robbie Belson, who leads our developer relations efforts specifically for our mobile edge compute portfolio with AWS. Thanks, Elise. We're here today to showcase how Verizon is building smarter applications at the edge with Verizon 5G Edge and AWS Wavelength.
And through the combination of Verizon 5G Ultra Wideband, AWS Wavelength and intelligent software, we want to show you firsthand how Verizon will be connecting and deploying aerial and ground robots for Industry 4.0 customers. Additionally, for those of you who wish to build these types of capabilities from scratch, we'll walk you through exactly how to do that, starting with the fundamentals. And you're not just going to hear it from us. You're going to hear it from some of our partners
about how network intelligence can play a role in amplifying existing software capabilities when it's deployed to Verizon’s 5G Edge with AWS Wavelength. So let's get started. We're gonna start by talking about the customer. The fourth industrial revolution or Industry 4.0 is a brand new chapter in human development, where interconnectivity and interoperability are beginning to deliver large scale automation for manufacturers and other industrial sectors. Industry 4.0 sets out to solve some of customers’ biggest problems today.
Enterprises face many challenges in accelerating their digitization efforts, and at Verizon, we are always focused on our customers. And we're working to propel our customers from merely just connecting their devices, to automating end-to-end value chains. And then from automation into full autonomy of end-to-end operations. Here's what's great. 5G is the foundational technology enabling Industry 4.0, because without it, you can't create an interoperable system that can manage that amount of data, that amount of speed and the reliability and security requirements that are necessary. 5G is beginning to unlock new opportunities for bold innovators in one sector after another.
By using the power of the network and pairing that with intelligent software, we're helping customers usher in the next generation of industry. One area in which we're seeing that come to life today is in robotics. By moving robot control in intelligence into a centralized orchestration engine on Mobile Edge Compute, we are introducing the future of robotic automation. Leveraging the speed, throughput, reliability and responsiveness of the Verizon network, paired with the sophistication of next generation software, all being deployed on AWS wavelength, we are poised to transform a variety of industries. You see, we are experts in building drone and autonomous mobile robot software to facilitate the orchestration of aerial and ground robots.
And I'm delighted today to be able to show you two groundbreaking technologies - one in the air and one on the ground. Autonomous mobile robots can help keep workers safe in factories, dangerous environments, and hazardous industries, and help reduce the labor crunch. Industries today are leveraging ground robots to help assess perimeter security and to inspect infrastructure. The data is being captured on the robot, but it's a very manual process, and the robot can't respond to the information on the fly. So I'm going to take you through two demonstrations to showcase a few of the possibilities of how better connectivity enables expanded sensor capability.
It enables expanded extended range and mobility of autonomous mobile robots in the air and on the ground. Let's begin with on the ground. In this example, a Quadruped robot, or a four-legged robot is deployed to run in automated security patrol of a parking lot.
Its core mission is to identify vehicles that have been inappropriately and suspiciously parked in the parking lot for more than 24 hours. Today, what would happen is that robot would return back to its dock to report that an alarm had been triggered, letting the human operator know. However, now we are using the network to autonomously redirect the robot based on what it finds and streams that information back in near real time to redirect its behavior and perform a detailed inspection of the vehicle. Through the use of digital twins, we take a static map of a space and we merge it with data from a wide variety of sensors to create a reproduction of that space.
And listen, it's not necessary for us, but it's so the robot can understand the world around it. This digital twin is a precise machine readable representation of everything in a space, which updates dynamically in near real time to reflect changes that are taking place in that space. Now let's see how the twin surfaces up the inspection mission for the robot. You can see when the robot reaches the vehicle, it takes a scan with its camera and that information is sent back in near real time to identify the type of vehicle. The system then loads an appropriate model into the digital twin as a starting point for the investigation.
Next, the software calculates a path and plots the key points of interest for investigation. The robot then completes its inspection of the vehicle. Now through the entire inspection, the robot is streaming what it sees from its camera back through the software over the network. The video is being captured and live streamed and also kept in the application for future reference. This allows the human operator to monitor what's happening in near real time from the comfort and safety of their office.
The robot here is fulfilling a role that might be difficult to find a human operator to do efficiently and effectively and has taken something that would be very manual and potentially dangerous, and turned it into a quick and easy inspection. The value of Verizon 5G Edge with AWS Wavelength is immense. But the value of these technologies plus intelligent software is far greater. In this case, the vehicle is cleared and a notification is sent to the security operations center.
Now, let's move to the air. In this example, a technician engineer is sent to do a routine inspection of a remote cell phone tower. Rather than a manual inspection of the tower the engineer will have the ability to operate the first 4G LTE connected drone in the US market, the Parrot ANAFI Ai that's also paired with Verizon’s owned and operated Skyward Aviation Management Platform. With a cellular connection and an appropriate waiver from the FAA, this drone is now able to go much farther, process imagery while still in flight and shrink the time of insight from several hours to just a few minutes. Pairing that with intelligent software at the edge with AWS Wavelength means the tower inspection and subsequent data can be shared with the engineer on site in near real-time.
But let me walk you through this step by step. First, the engineer loads up the application to create a new inspection report and indicates the points of interest for the inspection. The application confirms the location, analyzes the visibility and the weather conditions, and uses Verizon's very own Aviation Management Company Skyward to provide airspace conditions.
From there, the application loads the digital twin, plots the inspection points and creates the flight path for the drone. The drone then launches and initiates its pre-inspection calibration. First, it flies to the top of the tower to center itself in relation to the tower, checking its GPS coordinates in near real-time and what it sees in the world to what it knows it should see from the digital twin. This is exciting.
This will allow it and the twin to be completely in sync. From there, the drone begins its inspection of the predefined points of interest. The drone investigates each part of the tower by capturing images and once again, thanks to the low latency of AWS wavelength, paired with the Verizon network and intelligence software, it's able to stream the footage back in near real-time through the application to the engineer on the ground. Once the drone completes the inspection of the tower, it heads back down to the ground and lands. The digital twin updates the engineer with the final report notifying them of any irregularities found and in this case, no irregularities are found. So the drone returns back to the operator.
So let's just zoom out for a second. All of these examples were not developed overnight. Our edge enablement journey from silicon to the cloud was a product of Software Engineering and Applied Sciences, a tactful understanding of the mobile network and so much more. But for those of you who wish to build these types of capabilities from scratch, we wanted to show you what that might look like starting from the fundamentals. And to unpack these fundamentals. I'm going to turn it back over to Robbie. 111 00:08:56,02 --> 00:09:02,02 Thanks, Elise. Let's start by unpacking the fundamentals of Verizon 5G Edge with AWS Wavelength, starting with the simplest of questions. What is it? Where is it? And how do you use it? So Verizon 5G Edge is all about bringing the best of AWS compute and storage capabilities within the edge of our 4G and 5G mobile networks to truly deliver unprecedented immersive application experiences at scale.
But for those of you less familiar with mobile networks, I think it's great to always start with a quick primer on 5G networks. So let's say I'm browsing a mobile app today, that mobile traffic is routed through a cell tower or genode b along with the traffic from other surrounding genode B's back to our 5G core. And think of this as the place in which all of the mobile traffic finally becomes an IP address and connects to the broader internet at large.
Precisely at this point is where the compute resides and thus is the topologically closest point at which applications can be delivered to end users and iOT devices alike. But for traffic that isn't so lucky and has to leave the mobile network, packets are subject to a best effort service that's the internet. And what that actually means is that at every single hop from source to destination, a given router along that journey could become overwhelmed with network traffic. And what happens is that packet ends up being dropped, and the client is forced to retransmit.
And what that means for you- higher latency, and in most cases, a less desirable user experience. So let's take this one step further and look at a real world scenario, an application that I actually built and recorded right here. So what I've done is I've divided my phone in half, I took an Android app, and on the top half of the screen, I used the camera app and had it face a millisecond clock. So it said something like 624 and 52 seconds. But then on the bottom half of the screen, I decided to subscribe to the RTMP stream of that exact camera facing a millisecond clock.
And by doing this split screen exercise, we can isolate the end-to-end delay of our application from source to destination, across the wavelength zone, as you see on one side of the screen. And the next best alternative, which is the region itself. And what you're seeing here is incredible. 33% increase in latency without altering a single line of code. And I'll add, this is all over the 5G Ultra Wideband network. So I'm isolating the benefits of the mobile edge computing experience itself.
And worth noting that what you're seeing here isn't unique to Boston. In fact, Verizon 5G Edge is available in 13 cities today. And in this way, developers can continue to focus on building their applications, while we at Verizon focus on abstracting the complexities of the network itself. So let's talk about application intelligence. Because it can mean a number of different things in different contexts. And let's start with horizontal scaling as one such example. Because today, you might have one virtual machine running in the cloud.
And at some certain threshold, you'd want to scale to two virtual machines. And in the cloud computing literature, often virtual machines, CPU utilization is that go-to example, for auto scaling policies or that trigger. And so if you were to think about the underlying decision making engine that actually triggers that scaling behavior, it's application metrics. But what if I told you that the network could also play a role in that decision making process? In a 5G world, network intelligence has a larger opportunity than ever to shape how we orchestrate applications to meet ever increasing customer demands for low latency, immersive mobile experiences.
But what might that actually look like specifically? If you now have four parent regions and 13 wavelength zones, that's 17 potential geographies that a mobile client could connect to. So who's deciding all of this routing? Additionally, how should ops teams decide where to deploy their applications on day one, without incurring costs for idle VMs and containers? And perhaps even beyond that, how do you think about dynamically adjusting workloads over time to care for an ever changing set of demands from clients and an ephemeral set of clients to begin with. And safe to say that these challenges are admittedly, incredibly difficult to solve. So to unpack this further, let's talk about why. And to best explain the why, let's unpack the network itself. The beauty of AWS wavelength is that the vast majority of AWS infrastructure concepts are the exact same as what you'd expect in your cloud architecture today. And here's how. Let's start with your Virtual Private Cloud, the VPC.
Today, you might add to your VPC, a series of subnets, corresponding to an availability zone. And to use wavelength zones, you create a subnet in the exact same way, leveraging those same concepts of an availability zone, but now you have so many more choices for where that subnet might reside. After you create a subnet in a wavelength zone, or multiple wavelength zones of your choice, you attach a carrier gateway, which is a new resource in AWS that allows your wavelength zone to connect to our 4G and 5G networks and in turn your device fleet. And so by attaching this carrier gateway to the subnet, and then specifically applying the route to the carrier gateway, for your outbound traffic, you're essentially enabling that subnet and any resources instantiated therein to be connected to our 4G and 5G networks. The next question we often get from developers is, how do I create an EC2 instance in a wavelength zone? I’ve set up my networking environment, that's great, but what about now? It's really as simple as creating an EC2 instance in the parent region, you go to the AWS console or CLI, SDK, CDK. And when you create that EC2 instance,
you specify the VPC, and you specify the subnet, which in this case, is the wavelength zone. Now, there's only one thing left to do. And that's the carrier IP address. And typically, when you would create a public IP, all you do is you can assign it at launch or thereafter as a static or elastic IP. But in AWS wavelength, we have something called a carrier IP. Because when you attach it to an instance, you're not giving it access to the entirety of the internet itself, but rather just the Verizon carrier network.
And so you have two ways to do this: one within the console, you can say, absolutely, I'd like to automatically attach a carrier IP address to this EC2 instance. That's option one. Option two, you can go into the elastic IP subsection of the console, and say, I want to statically define or allocate an address within a wavelength zone and apply it to the instance. And everything else from selecting an instance type, attaching EBS storage, key pairs, exactly the same. And that's the beauty of AWS Wavelength. So what does this mean for you more broadly? Simply put, mobile edge computing introduces an incremental level of complexity that at face value might appear insurmountable.
But through network intelligence, and the seamlessness of the AWS console itself, we can easily solve these challenges without undifferentiated heavy lifting. And what better way to capture how we at Verizon are addressing these challenges 204 00:15:57,18 --> 00:15:06,06 than with the edge discovery service. So let's start with a simple problem statement. I have a mobile device and it's trying to connect to an application running in AWS Wavelength. How am I to do so? Remember that I could be deployed to 13 different wavelength zones and on top of that, the carrier IP addresses that expose say my load balancer and PTT broker, ML inference server, as just a few examples are not reachable by the broader Internet itself. And you might be asking, Who cares? Why does it matter? First and foremost, existing geolocation based routing systems are nowhere near precise enough for a world of 5G Edge.
And in fact, if you don't believe me, go take a carrier IP and pass it to one of these geo lookup tools available on the internet. And what you'll find is that these tools might expect, say, the Boston carrier IP address to be in Chicago as one such example. But let's go beyond the geo proximity problem and borrow from one of my favorite phrases from the airline industry. As they say, the closest exit, may be behind you.
In a 5G Edge world, here's what might happen. You might find yourself in Boston, but anchor to a packet core back in Washington DC. What that actually means for you is that the closest wavelength zone would be in Washington DC, even though you're currently in Boston.
And this is just one such example of all the fascinating intricacies of how mobile networks operate. But let's go back to the whole point of Verizon 5G Edge. Remember, we optimized the network so you don't have to deal with the complexities of the network itself, and in turn, can seamlessly build your immersive applications.
So continuing along that line of thought, imagine having a Waze or Mapquest-like tool for your edge computing journey, particularly to deal with these routing complexities we just mentioned. That's exactly what I want to tell you more about. The edge discovery service is an API that we developed here at Verizon, that takes care of all of that. So when you create your first application, you essentially use this API to create a service registry of all of your carrier facing endpoints, be it an IPV4 address, or a fully qualified domain name, like MyAwesomeApplication.com. From there, any device wishing to connect to the most optimal wavelength zone just has to use that same API to retrieve the endpoints of interest. And from a workflow perspective, it's really not all that different from DNS.
The difference rather, is how network intelligence can provide developers and devices alike with more information and more flexibility than ever before. And to elucidate this further, I want to take the time to walk you through a few examples of network intelligence. Now that we've unpacked the fundamentals of the edge discovery service, let's see this network intelligence in action with real partners building at the network edge. Let's start with Confluent.
For those of you building real time data analytics applications, you've probably struggled to identify the right data streaming architecture that's highly available, secure, geo redundant, and most importantly, all of those capabilities but not having to have done the heavy lifting required to build it yourself. And so to address these customer challenges, we teamed up with Confluent, one of the leaders in data in motion products to solve this exact problem. And upon first glance, you're seeing exactly that, using Confluent for Kubernetes, we realize that Confluent on EKS could truly be run anywhere, including with an AWS Wavelength, with a geo redundant implementation. But if we put on our AWS well-architected hats for a second here, perhaps we could be even more prescriptive with our deployments. Said differently, we probably don't want a bunch of idle node groups hanging out in each of the wavelength zones. So we worked with Confluent to address this exact implementation.
Imagine a world where you only have the application or Confluent cluster deployed in a single wavelength zone. But in turn, you're keeping track of all of the different wavelength zones at any given point in time. So now, instead of just asking EDS for the closest endpoint to me, which will always return just that single cluster, here's what you can now do. Let's say, you've now moved on to a second wavelength zone, you started in Boston, you're now in Miami, there's now going to be a mismatch between the wavelength zone closest to you in Miami, and the workload that EDS knows about which is in Boston.
So what do you do? And how do you recognize this discrepancy? Well, again, if you're keeping track of both of those, then the Edge Discovery Service can recognize that discrepancy, if you have two service registries that you're managing. And so now you have two options for how you want to act on this discrepancy of Aha! The closest wavelength zone to you is not one where this Confluent cluster actually resides. One option, you could have the client pass the header, perhaps a simple Boolean yes or no, to say: yes, deploy on my behalf if such a discrepancy exists, go ahead and deploy that Confluent cluster for me.
Alternatively, you could have some sort of cron job running in Kubernetes, that pulls inbound requests from mobile devices at some frequent interval, and then calls EDS on behalf of the clients to instantiate any additional node groups that are necessary. Worth noting that it could be node groups, horizontal pod auto scalars, doesn't really matter. The point here is that this is the true meaning of application orchestration to me. It's about taking information from the network, which was never possible before, and feeding that information back to the application to make smarter decisions across the application development lifecycle. And to learn more, we've worked with Confluent to build everything you see here into an easy to use infrastructure template available on our GitHub repository at github.com/Verizon/5GEdgeTutorials.
And now, let's hear directly from the Confluent team about their experiences on the network edge. Hi, I'm Amit Gupta, Director of Product Management at Confluent. And I want to talk to you today about Confluent, real-time data and edge computing use cases with wavelength. First off, Confluent was founded by the creators of Apache Kafka. And our mission is to set the world's data in motion, we see a paradigm shift in the industry, where user experiences and business operations need to happen in real-time, powered by data about what's actually happening in the world in real-time. For example, you might have a large fleet of delivery trucks dropping off packages around the country, and you want your customers as well as your back end systems to know immediately when a package has been successfully delivered.
Or if there's a delay or some other problem, you also want to know about that immediately and update your customers. Or you might have 1000s of retail locations around the country. And you want to update your back-end inventory systems, and your in-store discounts and promotions to respond to real-time customer activities within each store.
With Confluent for Kubernetes, Confluent cluster linking and wavelength, there are some exciting possibilities about how you could solve for such use cases. First wavelength, which provides the fully managed infrastructure experience of AWS, including elastic Kubernetes service or EKS to wavelength zones located closer to your edge endpoints, than the standard AWS regions and availability zones. Then Confluent for Kubernetes makes it easy to deploy a performant complete production grade data in motion platform based on Apache Kafka to each of your wavelength zones. Confluent for Kubernetes is the best way to orchestrate Kafka and Confluent in a declarative, API driven Kubernetes-native manner. Using the same technology that powers Confluent’s fully managed offering Confluent Cloud.
Confluent and wavelength together create the potential for something really exciting. This creates a very powerful compute mesh everywhere. Now with Conflutent for Kubernetes and Confluent Cloud on top of this compute mesh, and with cluster linking seamlessly bridging data between your clusters, you also have a mesh of real-time data everywhere as well. This has the potential to power the next generation of truly real-time customer experiences and business operations.
Let me give you another example of the Edge Discovery Service applied today in the context of real world architectures. As you think about the core services available today in AWS Wavelength, you have your core compute, an EC2, you have your containers and ECS, and EKS. But what about data? What about databases? And how do you think about distributed databases at the edge? And again, not have to manage the underlying complexities of what's the primary, what's the secondary, how do I deal with conflict resolution? Here's a great solution. We worked with MongoDB to create a distributed architecture precisely to service this use case, because we quickly realize that 5G Edge with AWS Wavelength solves the problem of how do you deliver immersive experiences? But how do you deliver immersive experiences and personalized experiences? And to me, that's exactly where the database comes in. So imagine you have a computer vision application that detects a given athlete.
Let's say in the spirit of the Summer Olympics, you take a picture of Caeleb Dressel, it tells you it's Caeleb Dressel. The high level AWS Wavelength implementation would be: Run that computer vision inference server at the edge. But now, let's say that computer vision wasn't enough. You also wanted to know, upon detection of a given athlete,
how many medals did they win back at the Olympics? Well, now you need a database that has all of the different player information, how many medals they've accrued, what type of medal... That's exactly where MongoDB can come in. And there's two ways you can do it. And we'll focus today on one such way called MongoDB Realm. So how exactly is MongoDB Realm used in this architecture? It's actually fairly simple. And let's start with the parent region.
Because in that parent region, you'll probably have a larger MongoDB Atlas Cluster consisting of a variety of data sources. But you can use that MongoDB Atlas Cluster to connect these edge databases, otherwise known as realm instances. And you can have this in one or many wavelength zones. The beauty of realm rather, is simple. It takes care of all of the syncing from edge back to the parent region, particularly if there's another edge also writing at that same point in time. That's what we call conflict resolution. So you don't have to deal with any of that.
You can focus on building your application, which in this case, might be that computer vision application for the Olympics. You take a picture of Caeleb Dressel. And it tells you not just that it's in fact, Caeleb Dressel, but overlays the number of medals accrued during the Olympics itself. So now you've essentially co-located the computer vision algorithm and the database itself. So how might we use the edge discovery service in this context? All you do is you take those carrier IP addresses associated in this case, with that computer vision, you populate it into the service registry, and then from there, any mobile client that wants to consume this application simply has to invoke the edge discovery service and say, hey, I want a copy of the computer vision app.
And there you go. It'll return the carrier IP. It's that simple. And to illustrate this further, let’s hear from Mark Porter, MongoDB’s CTO on his vision for MongoDB and 5G Edge together. I am so happy to be here today telling you about the partnership between MongoDB, Verizon and AWS. Edge computing is vital to the success of the technology industry. We have so many handheld devices that require low latency and high bandwidth. And frankly, the centralized infrastructure we built over the last couple of decades, just won't stand up to it.
So what do you need? You need a low latency network provided by Verizon, you need great phones that run great apps, you need computing infrastructure provided by AWS. And above all, you need the ability to write great applications. MongoDB provides Realm which runs on either your phone or in the edge data center. And we provide MongoDB, which has all the tools you need to write your app to get your data all the way from the central data center, out to the edge out to the phone.
Together, we are modernizing the infrastructure of this country. And we're gonna keep doing it and we're doing it so that you can write applications faster and more predictably and delight your customers. So we've talked a lot about platform capabilities at the network edge, or rather taking the core compute and building new capabilities on top of it. But as you think about day 2 operations, after you've deployed your application, what are the types of considerations you might have to care for, and at the very top to me, is performance monitoring and instrumentation. And to that end, we worked with New Relic to explore two really compelling architectures, first and foremost, solving the north-south traffic problem. Or rather, how do you monitor the latency between a mobile device or iOT device and a range of different AWS Wavelength zone endpoints? The other architecture we explored, was east-west traffic monitoring.
Or rather, how do I monitor traffic exchanges between a wavelength zone and a second wavelength zone, or a wavelength zone and an availability zone in the parent region, or some combination of the two? Let's talk about the north-south traffic problem. Imagine a scenario, perhaps a crowd analytics scenario, you have all of these different LIDAR cameras sending a bunch of data back to AWS Wavelength, so that you can do all sorts of interesting fan analytics use cases, such as: Where is there congestion in this stadium? Or how long does it take to get to that popcorn line? Safe to say that the connection between that camera and a wavelength zone could vary by wave latency. And today, New Relic has a feature by way of alerting that if a certain threshold is exceeded, it could send a notification, perhaps to a Slack channel that, hey, there's something wrong, you should look into it. But here's what you can do now. That alert could now be sent to the edge discovery service,
to ask a much more nuanced question around the lines of are you actually connected to the right wavelength zone? Perhaps the network environment is such that you're not connected to the most optimal wavelength zone. Perhaps you are in Boston, but again, using that analogy of the closest exit could be behind you, the closest wavelength zone right now, or most optimal wavelength zone rather, is the New York City wavelength zone. So now, you can connect this alerting feature by way of webhooks to send a message directly to the edge discovery service.
And if it turns out again, there's a discrepancy between what the edge discovery service just responded, such as actually, the most optimum wavelength zone is New York City, not Boston, you can reconfigure the connection from that LIDAR camera, back to AWS Wavelength. And this is just one example of network intelligence. If we transition back to east-west traffic flows, the story here is really all about intercluster traffic. So it's less about network intelligence, it's more about, you have all these different wavelength zones, how do you manage the complexity? And to that end, we use Pixie or New Relic’s open source performance monitoring framework, and deployed it directly within an EKS cluster, fully automated it and exposed it on our 5G Edge tutorials GitHub repo. So now, for all of you looking to get a start on day two operations and performance monitoring, we have a great solution for you. Just clone the repo, and look at all of that traffic
monitoring that you see out of the box. You don't have to deal with, how do I make sure that there's an agent running? And is it in all the right wavelength zones? It's just a Kubernetes cluster. And it's all taken care of right there for you. And now, let’s hear from the New Relic team directly as they share their experiences deploying Pixie to the network edge. Hi everyone, I'm Zain Asgar. I'm the General Manager of Pixie and Open Source at New Relic. So today I wanted to talk about Pixie, which is a CNCF sandbox project, how it connects up to New Relic and why we're so excited to be working with Verizon on the 5G Edge. So the first thing, let's talk a little bit about Pixie and how it works.
So Pixie is an observability platform for developers, and as I mentioned earlier is a CNCF sandbox project. We have three guiding principles, which I'll talk about in more detail in a second. But they are auto-telemetry using eBPF, being 100% scriptable, and being Kubernetes native. Pixie is very easy to install. It takes just a few minutes to get started and running.
A simple CLI command can deploy Pixie on your entire cluster. And once Pixie is installed, because we don't require you to change anything in your application, you can immediately get insights about what services are running, you can do different types of clustering, and get deep protocol level visibility. So the way Pixie architecture is structured, we are particularly well-suited to working in Edge environments, environments where you're very latency sensitive, you have to deal with lots of traffic and don't want to egress all the information out of your clusters. Using Pixie you can still do all the deep analytics, extract important information, without having to move you know everything off of your cluster and send it over to a cloud provider. We can flag interesting information that can be useful for long term storage and can be useful to get alerts on and all the pre-filtering can be done on the cluster.
Anyways, that was my quick overview of Pixie, our New Relic integration and why we're so excited about working with AWS and we look forward to shipping lots of stuff together. Thank you. Now that we've talked about network intelligence in three different ways: performance monitoring, data in motion, near real-time data architectures, let's look ahead to the future a little bit. What else can we do? One of my favorite examples, is all about proactive auto scaling. We talked about this a little bit before,
this idea that today, you scale based on things like CPU utilization, but maybe you could proactively scale. Let's not wait until that individual virtual machine is overwhelmed by way of capacity. Let's scale before that event happens. But you also don't wanna scale too early. Because then that's not cost effective. How might you do that? Here's a great idea. Specifically, in the case of an iOT use case, where you control that device fleet using Verizon Thinkspace, our iOT platform, there's actually API's for geolocation. So at any given point, you can know the lat long of your iOT devices. Here's why this matters.
If I know that I was in Boston, five minutes ago, and then I'm trekking further south five minutes after that, and further south five minutes after that, I can start to create a matrix of where all of my devices are heading, and use analytics to start to predict where are these devices going. In that way, you can proactively scale on those clients behalf, even before they might invoke the Edge Discovery Service to say, wait a minute, I might actually be closer to the Washington DC wavelength zone, should I scale? You don't have to wait anymore, it will already start that scaling behavior so that when you invoke the edge discovery service, there's already a workload that sits there. That's one super exciting use case to me. The second use case that's equally exciting to me, it's all about Kubernetes. We live and breathe a world of Kubernetes. That's exactly how applications are being deployed today on AWS Wavelength. But right now, you're not connecting the fact that your infrastructure is ephemeral and ever changing.
That has to be connected dynamically and automatically to the Edge Discovery Service. Said differently, wouldn't it be nice that anytime a new workload is exposed through the carrier network, the Edge Discovery Service will just know about it, you don't need an ops team to manually populate all of these carrier IPs, it just happens. And with Kubernetes, you can actually do that with admission controllers, this idea that you can constantly be monitoring for changes to a particular resource, which in this case, could be node ports, load balancers, you name it. And then use that intelligence to connect it back to the Edge Discovery Service.
So now, any time your environment changes, you don't have to worry about it. It's just taken care of for you. It’s not just about your infrastructure, it’s not just about your network architecture. It’s even not just about your network intelligence, rather, it’s how all of these forces come together to create a truly differentiated experience at our mobile edge on Verizon 5G Edge with AWS Wavelength.
And so whether you're talking Kubernetes, whether you're talking proactive auto scaling, whatever your architecture might entail, I hope we've convinced you that network intelligence is the future for how you deploy, manage and orchestrate mobile edge computing applications, not just today, but for the years to come. Thanks, Robbie. It's really remarkable to see all of our partners and the way they're addressing these unique business and technical challenges for the 5G Edge ecosystem.
That's exactly right and here at Verizon, we want to be your trusted partner in your edge enablement journey beyond re:Invent, and many ways you can get involved include checking out our Verizon 5G Edge blog on Medium, checking out our developer newsletter which comes out every single month and beyond that we host immersion days for hands on experience with Verizon 5G Edge, AWS Wavelength, and network intelligence. You see Verizon is leading the way alongside innovative customers but we can't shape the ecosystem alone. We're working every day to deliver on this end-to-end value chain that Industry 4.0 longs for, and we want to invite you to take this journey with us. So if you're a startup, a partner, a hardware supplier, a software shop, we would enjoy sharing more about our vision, our technology, and how we can work together to meet the growing demands of our customers. So on behalf of the entire Verizon 5G Edge team, stay safe, stay healthy, and enjoy the rest of re:Invent.
Boom. There we go. That's a wrap.
2021-12-04 13:23
