(upbeat music) >> Okay, we're now going to try and stretch our minds a little bit and stretch Supercloud to the edge. Supercloud, as we've been discussing today and reporting through various breaking analyses, is a term we use to describe a continuous experience across clouds, or even on-prem, that adds new value on top of hyperscale infrastructure. Priya Rajagopal is the director of product management at Couchbase. She's a developer, a software architect, co-creator on a number of patents as well as being an expert on edge, IoT, and mobile computing technologies. And we're going to talk about edge requirements. Priya, you've been around software engineering and mobile and edge technologies your entire career, and now you're responsible for bringing enterprise class database technology to the edge and IoT environments, synchronizing. So, when you think about the edge, the near edge, the far edge, what are the fundamental assumptions that you have to make with regards to things like connectivity, bandwidth, security, and any other technical considerations when you think about software architecture for these environments? >> Sure, sure. First off, Dave, thanks for having me here. It's really exciting to be here again, my second time. And thank you for that kind introduction. So, quickly to get back to your question. When it comes to architecting for the edge our principle is prepare for the worst and hope for the best. Because, really, when it comes to edge computing, it's sort of the edge cases that come to bite you. You mentioned connectivity, bandwidth, security. I have a few more. Starting with connectivity, as you import on low network connectivity, think offshore oil rigs, cruise ships, or even retail settings, when you want to have business continuity, most of the time you've got an internet connection, but then when there is disruption, then you lose business continuity. Then when it comes to bandwidth, the notion or the approach we take is that bandwidth is always limited or it's at a premium. Data plans can go up through the roof, depending on the volume of data. Think medical clinics in rural areas. When it comes to security, edge poses unique challenges because you're moving away from this world garden, central cloud-based environment, and now everything is accessible over the internet. And the internet really is inherently untrustworthy. Every bit of data that is written or read by an application needs to be authenticated, needs to be authorized. The entire path needs to be secured end-to-end. It needs to be encrypted. That's confidentiality. Also the persistence of data itself. It needs to be encrypted on disk. Now, one of the advantages of edge computing or distributing data is that the impacted edge environment can be isolated away without impacting the other edge location. Looking at the classic retail architecture, if you've got retail use case, if you've got a a retail store where there's a security breach, you need to have a provision of isolating that store so that you don't bring down services for the other stores. When it comes to edge computing, you have to think about those aspects of security. Any of these locations could be breached. And if one of them is breached, how do you control that? So, that's to answer those three key topics that you brought up. But there are other considerations. One is data governance. That's a huge challenge. Because we are a database company at Couchbase, we think of database, data governance, compliance, privacy. All that is very paramount to our customers. It's not just about enforcing policies right now. We are talking about not enforcing policies in a central location, but you have to do it in a distributed fashion because one of the benefits of edge computing is, as you probably very well know, is the benefits it brings when it comes to data privacy, governance policies. You can enforce that at a granular scale because data doesn't have to ever leave the edge. But again, I talked about this in the context of security, there needs to be a way to control this data at the edge. You have to govern the data when it is at the edge remotely. Some of the other challenges when thinking about the edge is, of course, volume, scale, think IoT, mobile devices, classic far edge type scenarios. And I think the other criteria that we have to keep in mind when we are architecting a platform for this kind of computing paradigm is the heterogeneity of the edge itself. It's no longer a uniform set of compute and storage resources that are available at your disposal. You've got a variety of IoT devices. You've got mobile devices, different processing capabilities, different storage capabilities. When it comes to edge data centers, it's not uniform in terms of what services are available. Do they have a load balancer? Do they have a firewall? Can I deploy a firewall? These are all some key architectural considerations when it comes to actually architecting a solution for the edge. >> Great. Thank you for that awesome setup. Talking about stretching to the edge this idea of Supercloud that connote that single logical layer that spans across multiple clouds. It can include on on-prem, but a critical criterion is that the developer, and, of course, the user experience, is identical or substantially similar. Let's say identical. Let's say identical, irrespective of physical location. Priya, is that vision technically achievable today in the world of database. And if so, can you describe the architectural elements that make it possible to perform well and have low latency and the security and other criteria that you just mentioned? What's the technical enablers? Is it just good software. Is it architecture? Help us understand that. >> Sure. You brought up two aspects. You mentioned user experience, and then you mentioned from a developer standpoint, what does it take? And I'd like to address the two separately. They are very tightly related, but I'd like to address them separately. Just focusing on the easier of the two when it comes to user experience, what are the factors that impact user experience? You're talking about reliability of service. Always on, always available applications. It doesn't matter where the data is coming from. Whether the data is coming from my device, it's sourced from an on-prem data center, or if it is from the edge of the cloud, it's from a central cloud data center, from an end-user perspective, all they care about is that their application is available. The next is, of course, responsiveness. Users are getting increasingly impatient. Do you want to reduce wait times to service? You want something which is extremely fast. They're looking for immersive applications or immersive experiences, AR, VR, mixed reality use cases. Then something which is very critical, and what you just touched upon, is this sort of seamless experience. Like this omnichannel, as we talk about in the context of retail kind of experience, Or what I like to refer to as park and pick up reference. You park, you start your application, running your application, you start a transaction on one device, you park it, pick it up on another device. Or in case of retail, you walk into a store, you pick it up from there. So, there's a park and pick up. Seamless mobility of data is extremely critical. In the context of a database, when we talk about responsiveness, two key, the KPIs are latency, bandwidth. And latency is really the round trip time from the time it takes to make a request for data, and the response comes back. The factors that impact latency are, of course, the type of the network itself, but also the proximity of the data source to the point of consumption. And so the more number of hubs that the data packets have to take to reach from the source to its destination, then you're going to incur a lot of latency. And when it comes to bandwidth, we are talking about the capacity of the network. How much data can be shot through the pipe? And, of course, when edge computing, large number of clients. I talked about scale, the volume of devices. And when you're talking about all of them concurrently connected, then you're going to have network congestion which impacts bandwidth which, in turn, impacts performance. And so when it comes to how do you architect a solution for that, if you completely remove the reliance on network to the extent possible, then you get the highest guarantees when it comes to responsiveness, availability, reliability. Because your application is always going to be on. In order to do that, if you have the database and the data processing components co-located with the application that needs it, that would give you the best experience. But, of course, you want to bring it as close. A lot of times, it's not possible to end with that data within your application itself. And that's where you have options of your an on-prem data center, the edge of the cloud, max end and so on. So the closer you bring the data, you're going to get the better experience. Now, that's all great. But then when it comes to something to achieve a vision of Supercloud, when we talked about, "Hey, one way from a developer standpoint, I have one API to set up this connection to a server, but then behind the scenes, my data could be resident anywhere." How do you achieve something like that? And so, a critical aspect of the solution is data synchronization. I talked about data storage as a database, data storage database, that's a critical aspect of what database is really where the data is persisted, data processing, the APIs to access and query the data. But another really critical aspect of distributing a database is the data synchronization technology. And so once all the islands of data, whether it is on the device, whether it's an on-prem data center, whether it's the edge of the cloud, or whether it is a regional data center, once all those databases are kept in sync, then it's a question of when connectivity to one of those data centers goes down, then there needs to be a seamless switch to another data center. And today, at least when it comes to Couchbase, a lot of our customers do employ global load balancers which can automatically detect. So, from a perspective of an application, it's just one URL end point. But then when one of those services goes down or data centers goes down, we have active failover and standby. And so the load balance automatically redirects all the traffic to the backup data center. And of course, for that to happen, those two data centers need to be in sync. And that's critical. Did that answer your question? >> Yeah, let me jump in here. Thank you again for that. I want to unpack some of those, and I want use the example of Couchbase Light, which, as the name implies, a mobile version of Couchbase. I'm interested in a number of things that you said. You talked about, in some cases, you want to get data from the most proximate location. Is there a some kind of metadata intelligence that you have access to? I'm interested in how you do the synchronization. How do you deal with conflict resolution and recovery if something goes wrong? You're talking about distributed database challenges. How do you approach all that? >> Wow, great question. And probably one that I could occupy the entire session for, but I'll try and keep it brief and try and answer most of the points that you touched upon. So, we talked about distributed database and data sync. But here's the other challenge. A lot of these distributed locations can actually be disconnected. So, we've just exacerbated this whole notion of data sync. And that's what we call offline first, not just we call, what is typically referred to as offline first sync. But the ability for an application to run in a completely disconnected mode, but then when there is network connectivity, the data is synced back to the backend data servers. In order for this to happen, you need a sync protocol (indistinct). Since you asked in the context of Couchbase, our sync protocol, it's a web sockets, extremely lightweight data synchronization protocol that's resilient to network disruption. So, what this means is I could have hundreds of thousands of clients that are connected to a data center, and they could be at various stages of disconnect. And you have a field application, and then you are veering in and out of pockets of network connectivity, so network is disrupted, and then network connectivity is restored. Our sync protocol has got a built-in checkpoint mechanism that allows the two replicating points to have a handshake of what is the previous sync point, and only data from that previous sync point is sent to that specific client. And in order to achieve that you mentioned Couchbase Light, which is, of course, our embedded database for mobile, desktop and any embedded platform. But the one that handles the data synchronization is our Sync Gateway. So, we got a component, Sync Gateway, that sits with our Couchbase server, and that's responsible for securely syncing the data and implementing this protocol with Couchbase Light. You talked about conflict resolution. And it's great that you mentioned that. Because when it comes to data sync, a lot of times folks think, "Oh well, how hard can that be?" I mean, you request for some data, and you pull down the a data, and that's great. And that's the happy path. When all of the clients are connected, when there is reliable network connectivity, that's great. But we are, of course, talking about unreliable network connectivity and resiliency to network disruptions. And also the fact that you have lots of concurrently connected clients, all of them potentially updating the same piece of data. That's when you have a conflict, When two or more clients are updating the same, clients or writers. You could have the writes coming in from the clients. You could have the writes coming in from the backend systems. Either way, multiple writers do the same piece of data. That's when you have conflicts. Now, when it comes to, so, a little bit to explain how conflict resolution is handled within our data sync protocol in Couchbase, it would help to understand a little bit about what kind of database we are, how is data itself stored within our database. So, Couchbase Light is a NoSql JSON document store, which means everything is stored as JSON documents. And so every time there is a write, an update to a document, let's say you start with an initial version of the document, the document is created. Every time there is a mutation to a document, you have a new revision to that document. So, as you build in more rights or more mutations to that document, you build out what's called a revision tree. And so when does a conflict happen? Conflict happens when there is a branch in the tree. So, you've got two writers, writing to the same revision, then you get a branch, and that's what is a conflict. We have a way of detecting those conflicts automatically. That's conflict detection. So, now we know there's a conflict, but we have to resolve it. And within Couchbase, you have two options. You don't have to do anything about it. The system has built-in automatic conflict resolution heuristics built in. So, it's going to check, pick a winning revision. And so we use a bunch of criteria, and we pick a winning revision. So, if two writers are updating the same revision of the document, version of the document, we pick a winner. But then that seemed to work from our experience, 80% of the use cases. But then for the remaining 20%, applications would like to have more control over how the winner of the conflict is picked. And for that, applications can implement a custom conflict resolver. So, we'll automatically detect the conflicting revisions and send these conflicting revisions over to the application via a callback, and the application has access to the entire document body of the two revisions and can use whatever criteria needs to merge >> So, that's policy based in that example? >> Yes. >> Yeah, yeah, okay. >> So you can have user policy based, or you can have the automatic heuristics. >> Okay, I got to wrap because we're out of time, but I want to run this scenario by you. One of the risks to the Supercloud Nirvana that we always talk about is this notion of a new architecture emerging at the edge, far edge really, 'cause they're highly-distributed environments. They're low power, tons of data. And this idea of AI inferencing at the edge, a lot of the AI today is done in modeling in the cloud. You think about ARM processors in these new low-cost devices and massive processing power eventually overwhelming the economics. And then that's seeping back into the enterprise and disrupting it. Now, you still get the problem of federated governance and security, and that's probably going to be more centralized slash federated. But, in one minute, do you see that AI inferencing real-time taking off at the edge? Where is that on the S-curve? >> Oh, absolutely right. When it comes to IoT applications, it's all about massive volumes of data generated at the edge. You talked about the economics doesn't add up. Now you need to actually, the data needs to be actioned at some point. And if you have to transfer all of that over the internet for analysis, the responsiveness, you're going to lose that. You're not going to get that real-time responsiveness and availability. The edge is the perfect location. And a lot of this data is temporal in nature. So, you don't want that to be sent back to the cloud for long-term persistence, but instead you want that to be actioned close as possible to the source itself. And when you talk about, there are, of course, the really small microcontrollers and so on. Even there, you can actually have some local processing done, like tiny ML models, but then mobile devices, when you talk about those, as you're very well aware, these are extremely capable. They're capable of running neural, they have neural network processors. And so they can do a lot of processing locally itself. But then when you want to have an aggregated view within the edge, you want to process that data in an IoT gateway and only send the aggregated data back to the cloud for long-term analytics and persistence. >> Yeah, this is something we're watching, and I think could be highly disruptive, and it's hard to predict. Priya, I got to go. Thanks so much for coming on the "theCube." Really appreciate your time. >> Yeah, thank you. >> All right, you're watching "Supercloud 22." We'll be right back right after this short break. (upbeat music)