(bright music) >> Hi, everybody, this is Dave Vellante, welcome back to Supercloud 2. Last August, at the first Supercloud event, we invited the broader community to help further define Supercloud, we assessed its viability, and identified the critical elements and deployment models of the concept. The objectives here at Supercloud too are, first of all, to continue to tighten and test the concept, the second is, we want to get real world input from practitioners on the problems that they're facing and the viability of Supercloud in terms of applying it to their business. So on the program, we got companies like Walmart, Sachs, Western Union, Ionis Pharmaceuticals, NASDAQ, and others. And the third thing that we want to do is we want to drill into the intersection of cloud and data to project what the future looks like in the context of Supercloud. So in this segment, we want to explore the concept of data architectures and what's going to be required for Supercloud. And I'm pleased to welcome one of our Supercloud sponsors, ChaosSearch, Ed Walsh is the CEO of the company, with Thomas Hazel, who's the Founder, CTO, and Chief Scientist. Guys, good to see you again, thanks for coming into our Marlborough studio. >> Always great. >> Great to be here. >> Okay, so there's a little debate, I'm going to put you right in the spot. (Ed chuckling) A little debate going on in the community started by Bob Muglia, a former CEO of Snowflake, and he was at Microsoft for a long time, and he looked at the Supercloud definition, said, "I think you need to tighten it up a little bit." So, here's what he came up with. He said, "A Supercloud is a platform that provides a programmatically consistent set of services hosted on heterogeneous cloud providers." So he's calling it a platform, not an architecture, which was kind of interesting. And so presumably the platform owner is going to be responsible for the architecture, but Dr. Nelu Mihai, who's a computer scientist behind the Cloud of Clouds Project, he chimed in and responded with the following. He said, "Cloud is a programming paradigm supporting the entire lifecycle of applications with data and logic natively distributed. Supercloud is an open architecture that integrates heterogeneous clouds in an agnostic manner." So, Ed, words matter. Is this an architecture or is it a platform? >> Put us on the spot. So, I'm sure you have concepts, I would say it's an architectural or design principle. Listen, I look at Supercloud as a mega trend, just like cloud, just like data analytics. And some companies are using the principle, design principles, to literally get dramatically ahead of everyone else. I mean, things you couldn't possibly do if you didn't use cloud principles, right? So I think it's a Supercloud effect, you're able to do things you're not able to. So I think it's more a design principle, but if you do it right, you get dramatic effect as far as customer value. >> So the conversation that we were having with Muglia, and Tristan Handy of dbt Labs, was, I'll set it up as the following, and, Thomas, would love to get your thoughts, if you have a CRM, think about applications today, it's all about forms and codifying business processes, you type a bunch of stuff into Salesforce, and all the salespeople do it, and this machine generates a forecast. What if you have this new type of data app that pulls data from the transaction system, the e-commerce, the supply chain, the partner ecosystem, et cetera, and then, without humans, actually comes up with a plan. That's their vision. And Muglia was saying, in order to do that, you need to rethink data architectures and database architectures specifically, you need to get down to the level of how the data is stored on the disc. What are your thoughts on that? Well, first of all, I'm going to cop out, I think it's actually both. I do think it's a design principle, I think it's not open technology, but open APIs, open access, and you can build a platform on that design principle architecture. Now, I'm a database person, I love solving the database problems. >> I'm waited for you to launch into this. >> Yeah, so I mean, you know, Snowflake is a database, right? It's a distributed database. And we wanted to crack those codes, because, multi-region, multi-cloud, customers wanted access to their data, and their data is in a variety of forms, all these services that you're talked about. And so what I saw as a core principle was cloud object storage, everyone streams their data to cloud object storage. From there we said, well, how about we rethink database architecture, rethink file format, so that we can take each one of these services and bring them together, whether distributively or centrally, such that customers can access and get answers, whether it's operational data, whether it's business data, AKA search, or SQL, complex distributed joins. But we had to rethink the architecture. I like to say we're not a first generation, or a second, we're a third generation distributed database on pure, pure cloud storage, no caching, no SSDs. Why? Because all that availability, the cost of time, is a struggle, and cloud object storage, we think, is the answer. >> So when you're saying no caching, so when I think about how companies are solving some, you know, pretty hairy problems, take MySQL Heatwave, everybody thought Oracle was going to just forget about MySQL, well, they come out with Heatwave. And the way they solve problems, and you see their benchmarks against Amazon, "Oh, we crush everybody," is they put it all in memory. So you said no caching? You're not getting performance through caching? How is that true, and how are you getting performance? >> Well, so five, six years ago, right? When you realize that cloud object storage is going to be everywhere, and it's going to be a core foundational, if you will, fabric, what would you do? Well, a lot of times the second generation say, "We'll take it out of cloud storage, put in SSDs or something, and put into cache." And that adds a lot of time, adds a lot of costs. But I said, what if, what if we could actually make the first read hot, the first read distributed joins and searching? And so what we went out to do was said, we can't cache, because that's adds time, that adds cost. We have to make cloud object storage high performance, like it feels like a caching SSD. That's where our patents are, that's where our technology is, and we've spent many years working towards this. So, to me, if you can crack that code, a lot of these issues we're talking about, multi-region, multicloud, different services, everybody wants to send their data to the data lake, but then they move it out, we said, "Keep it right there." >> You nailed it, the data gravity. So, Bob's right, the data's coming in, and you need to get the data from everywhere, but you need an environment that you can deal with all that different schema, all the different type of technology, but also at scale. Bob's right, you cannot use memory or SSDs to cache that, that doesn't scale, it doesn't scale cost effectively. But if you could, and what you did, is you made object storage, S3 first, but object storage, the only persistence by doing that. And then we get performance, we should talk about it, it's literally, you know, hundreds of terabytes of queries, and it's done in seconds, it's done without memory caching. We have concepts of caching, but the only caching, the only persistence, is actually when we're doing caching, we're just keeping another side-eye track of things on the S3 itself. So we're using, actually, the object storage to be a database, which is kind of where Bob was saying, we agree, but that's what you started at, people thought you were crazy. >> And maybe make it live. Don't think of it as archival or temporary space, make it live, real time streaming, operational data. What we do is make it smart, we see the data coming in, we uniquely index it such that you can get your use cases, that are search, observability, security, or backend operational. But we don't have to have this, I dunno, static, fixed, siloed type of architecture technologies that were traditionally built prior to Supercloud thinking. >> And you don't have to move everything, essentially, you can do it wherever the data lands, whatever cloud across the globe, you're able to bring it together, you get the cost effectiveness, because the only persistence is the cheapest storage persistent layer you can buy. But the key thing is you cracked the code. >> We had to crack the code, right? That was the key thing. >> That's where the plans are. >> And then once you do that, then everything else gets easier to scale, your architecture, across regions, across cloud. >> Now, it's a general purpose database, as Bob was saying, but we use that database to solve a particular issue, which is around operational data, right? So, we agree with Bob's. >> Interesting. So this brings me to this concept of data, Jimata Gan is one of our speakers, you know, we talk about data fabric, which is a NetApp, originally NetApp concept, Gartner's kind of co-opted it. But so, the basic concept is, data lives everywhere, whether it's an S3 bucket, or a SQL database, or a data lake, it's just a node on the data mesh. So in your view, how does this fit in with Supercloud? Ed, you've said that you've built, essentially, an enabler for that, for the data mesh, I think you're an enabler for the Supercloud-like principles. This is a big, chewy opportunity, and it requires, you know, a team approach. There's got to be an ecosystem, there's not going to be one Supercloud to rule them all, so where does the ecosystem fit into the discussion, and where do you fit into the ecosystem? >> Right, so we agree completely, there's not one Supercloud in effect, but we use Supercloud principles to build our platform, and then, you know, the ecosystem's going to be built on leveraging what everyone else's secret powers are, right? So our power, our superpower, based upon what we built is, we deal with, if you're having any scale, or cost effective scale issues, with data, machine generated data, like business observability or security data, we are your force multiplier, we will take that in singularly, just let it, simply put it in your object storage wherever it sits, and we give you uniformity access to that using OpenAPI access, SQL, or you know, Elasticsearch API. So, that's what we do, that's our superpower. So I'll play it into data mesh, that's a perfect, we are a node on a data mesh, but I'll play it in the soup about how, the ecosystem, we see it kind of playing, and we talked about it in just in the last couple days, how we see this kind of possibly. Short term, our superpowers, we deal with this data that's coming at these environments, people, customers, building out observability or security environments, or vendors that are selling their own Supercloud, I do observability, the Datadogs of the world, dot dot dot, the Splunks of the world, dot dot dot, and security. So what we do is we fit in naturally. What we do is a cost effective scale, just land it anywhere in the world, we deal with ingest, and it's a cost effective, an order of magnitude, or two or three order magnitudes more cost effective. Allows them, their customers are asking them to do the impossible, "Give me fast monitoring alerting. I want it snappy, but I want it to keep two years of data, (laughs) and I want it cost effective." It doesn't work. They're good at the fast monitoring alerting, we're good at the long-term retention. And yet there's some gray area between those two, but one to one is actually cheaper, so we would partner. So the first ecosystem plays, who wants to have the ability to, really, all the data's in those same environments, the security observability players, they can literally, just through API, drag our data into their point to grab. We can make it seamless for customers. Right now, we make it helpful to customers. Your Datadog, we make a button, easy go from Datadog to us for logs, save you money. Same thing with Grafana. But you can also look at ecosystem, those same vendors, it used to be a year ago it was, you know, its all about how can you grow, like it's growth at all costs, now it's about cogs. So literally we can go an environment, you supply what your customer wants, but we can help with cogs. And one-on one in a partnership is better than you trying to build on your own. >> Thomas, you were saying you make the first read fast, so you think about Snowflake. Everybody wants to talk about Snowflake and Databricks. So, Snowflake, great, but you got to get the data in there. All right, so that's, can you help with that problem? >> I mean we want simple in, right? And if you have to have structure in, you're not simple. So the idea that you have a simple in, data lake, schema read type philosophy, but schema right type performance. And so what I wanted to do, what we have done, is have that simple lake, and stream that data real time, and those access points of Search or SQL, to go after whatever business case you need, security observability, warehouse integration. But the key thing is, how do I make that click, click, click answer, and do it quickly? And so what we want to do is, that first read has to be fast. Why? 'Cause then you're going to do all this siloing, layers, complexity. If your first read's not fast, you're at a disadvantage, particularly in cost. And nobody says I want less data, but everyone has to, whether they say we're going to shorten the window, we're going to use AI to choose, but in a security moment, when you don't have that answer, you're in trouble. And that's why we are this service, this Supercloud service, if you will, providing access, well-known search, well-known SQL type access, that if you just have one access point, you're at a disadvantage. >> We actually talked about Snowflake and BigQuery, and a different platform, Data Bricks. That's kind of where we see the phase two of ecosystem. One is easy, the low-hanging fruit is observability and security firms. But the next one is, what we do, our super power is dealing with this messy data that schema is changing like night and day. Pipelines are tough, and it's changing all the time, but you want these things fast, and it's big data around the world. That's the next point, just use us alongside, or inside, one of their platforms, and now we get the best of both worlds. Our superpower is keeping this messy data as a streaming, okay, not a batch thing, allow you to do that. So, that's the second one. And then to be honest, the third one, which plays you to Supercloud, it also plays perfectly in the data mesh, is if you really go to the ultimate thing, what we have done is made object storage, S3, GCS, and blob storage, we made it a database. Put, get, complex query with big joins. You know, so back to your original thing, and Muglia teed it up perfectly, we've done that. Now imagine if that's an ecosystem, who would want that? If it's, again, it's uniform available across all the regions, across all the clouds, and it's right next to where you are building a service, or a client's trying, that's where the ecosystem, I think people are going to use Superclouds for their superpowers. We're really good at this, allows that short term. I think the Snowflakes and the Data Bricks are the medium term, you know? And then I think eventually gets to, hey, listen if you can make object storage fast, you can just go after it with simple SQL queries, or elastic. Who would want that? I think that's where people are going to leverage it. It's not going to be one Supercloud, and we leverage the super clouds. >> Our viewpoint is smart object storage can be programmable, and so we agree with Bob, but we're not saying do it here, do it here. This core, fundamental layer across regions, across clouds, that everyone has? Simple in. Right now, it's hard to get data in for access for analysis. So we said, simply, we'll automate the entire process, give you API access across regions, across clouds. And again, how do you do a distributed join that's fast? How do you do a distributed join that doesn't cost you an arm or a leg? And how do you do it at scale? And that's where we've been focused. >> So prior, the cloud object store was a niche. >> Yeah. >> S3 obviously changed that. How standard is, essentially, object store across the different cloud platforms? Is that a problem for you? Is that an easy thing to solve? >> Well, let's talk about it. I mean we've fundamentally, yeah we've extracted it, but fundamentally, cloud object storage, put, get, and list. That's why it's so scalable, 'cause it doesn't have all these other components. That complexity is where we have moved up, and provide direct analytical API access. So because of its simplicity, and costs, and security, and reliability, it can scale naturally. I mean, really, distributed object storage is easy, it's put-get anywhere, now what we've done is we put a layer of intelligence, you know, call it smart object storage, where access is simple. So whether it's multi-region, do a query across, or multicloud, do a query across, or hunting, searching. >> We've had clients doing Amazon and Google, we have some Azure, but we see Amazon and Google more, and it's a consistent service across all of them. Just literally put your data in the bucket of choice, or folder of choice, click a couple buttons, literally click that to say "that's hot," and after that, it's hot, you can see it. But we're not moving data, the data gravity issue, that's the other. That it's already natively flowing to these pools of object storage across different regions and clouds. We don't move it, we index it right there, we're spinning up stateless compute, back to the Supercloud concept. But now that allows us to do all these other things, right? >> And it's no longer just cheap and deep object storage. Right? >> Yeah, we make it the same, like you have an analytic platform regardless of where you're at, you don't have to worry about that. Yeah, we deal with that, we deal with a stateless compute coming up -- >> And make it programmable. Be able to say, "I want this bucket to provide these answers." Right, that's really the hope, the vision. And the complexity to build the entire stack, and then connect them together, we said, the fabric is cloud storage, we just provide the intelligence on top. >> Let's bring it back to the customers, and one of the things we're exploring in Supercloud too is, you know, is Supercloud a solution looking for a problem? Is a multicloud really a problem? I mean, you hear, you know, a lot of the vendor marketing says, "Oh, it's a disaster, because it's all different across the clouds." And I talked to a lot of customers even as part of Supercloud too, they're like, "Well, I solved that problem by just going mono cloud." Well, but then you're not able to take advantage of a lot of the capabilities and the primitives that, you know, like Google's data, or you like Microsoft's simplicity, their RPA, whatever it is. So what are customers telling you, what are their near term problems that they're trying to solve today, and how are they thinking about the future? >> Listen, it's a real problem. I think it started, I think this is a a mega trend, just like cloud. Just, cloud data, and I always add, analytics, are the mega trends. If you're looking at those, if you're not considering using the Supercloud principles, in other words, leveraging what I have, abstracting it out, and getting the most out of that, and then build value on top, I think you're not going to be able to keep up, In fact, no way you're going to keep up with this data volume. It's a geometric challenge, and you're trying to do linear things. So clients aren't necessarily asking, hey, for Supercloud, but they're really saying, I need to have a better mechanism to simplify this and get value across it, and how do you abstract that out to do that? And that's where they're obviously, our conversations are more amazed what we're able to do, and what they're able to do with our platform, because if you think of what we've done, the S3, or GCS, or object storage, is they can't imagine the ingest, they can't imagine how easy, time to glass, one minute, no matter where it lands in the world, querying this in seconds for hundreds of terabytes squared. People are amazed, but that's kind of, so they're not asking for that, but they are amazed. And then when you start talking on it, if you're an enterprise person, you're building a big cloud data platform, or doing data or analytics, if you're not trying to leverage the public clouds, and somehow leverage all of them, and then build on top, then I think you're missing it. So they might not be asking for it, but they're doing it. >> And they're looking for a lens, you mentioned all these different services, how do I bring those together quickly? You know, our viewpoint, our service, is I have all these streams of data, create a lens where they want to go after it via search, go after via SQL, bring them together instantly, no e-tailing out, no define this table, put into this database. We said, let's have a service that creates a lens across all these streams, and then make those connections. I want to take my CRM with my Google AdWords, and maybe my Salesforce, how do I do analysis? Maybe I want to hunt first, maybe I want to join, maybe I want to add another stream to it. And so our viewpoint is, it's so natural to get into these lake platforms and then provide lenses to get that access. >> And they don't want it separate, they don't want something different here, and different there. They want it basically -- >> So this is our industry, right? If something new comes out, remember virtualization came out, "Oh my God, this is so great, it's going to solve all these problems." And all of a sudden it just got to be this big, more complex thing. Same thing with cloud, you know? It started out with S3, and then EC2, and now hundreds and hundreds of different services. So, it's a complex matter for a lot of people, and this creates problems for customers, especially when you got divisions that are using different clouds, and you're saying that the solution, or a solution for the part of the problem, is to really allow the data to stay in place on S3, use that standard, super simple, but then give it what, Ed, you've called superpower a couple of times, to make it fast, make it inexpensive, and allow you to do that across clouds. >> Yeah, yeah. >> I'll give you guys the last word on that. >> No, listen, I think, we think Supercloud allows you to do a lot more. And for us, data, everyone says more data, more problems, more budget issue, everyone knows more data is better, and we show you how to do it cost effectively at scale. And we couldn't have done it without the design principles of we're leveraging the Supercloud to get capabilities, and because we use super, just the object storage, we're able to get these capabilities of ingest, scale, cost effectiveness, and then we built on top of this. In the end, a database is a data platform that allows you to go after everything distributed, and to get one platform for analytics, no matter where it lands, that's where we think the Supercloud concepts are perfect, that's where our clients are seeing it, and we're kind of excited about it. >> Yeah a third generation database, Supercloud database, however we want to phrase it, and make it simple, but provide the value, and make it instant. >> Guys, thanks so much for coming into the studio today, I really thank you for your support of theCUBE, and theCUBE community, it allows us to provide events like this and free content. I really appreciate it. >> Oh, thank you. >> Thank you. >> All right, this is Dave Vellante for John Furrier in theCUBE community, thanks for being with us today. You're watching Supercloud 2, keep it right there for more thought provoking discussions around the future of cloud and data. (bright music)

>> Live from Mountain View, California, it's theCUBE! Covering DevNet Create 2019, brought to you by Cisco. >> Hi, welcome to theCUBE's coverage of Cisco DevNet Create 2019, Lisa Martin with John Furrier, we've been here all day, talking about lots of very inspiring, educational, collaborative folks, and we're pleased to welcome to theCUBE Anne Gentle, developer experience manager for Cisco DevNet, Anne, thank you so much for joining us on theCUBE today. >> Thank you so much for having me. >> So this event, everything's like, rockstar start this morning with Susie, Mandy, and the team with the keynotes, standing room only, I know when I was walking out. >> I loved it, yes. >> Yes, there's a lot of bodies in here, it's pretty toasty. >> Yeah. >> The momentum that you guys have created, pun intended. >> Oh, yes. >> No, I can't take credit for that, is really, you can feel it, there's a tremendous amount of collaboration, this is your second create? >> Second create, yeah, so I've been with DevNet itself for about year and a half, and started at Cisco about three years ago this month, but I feel like developer experience is one of my first loves, when I really started to understand how to advocate for the developer experience. So DevNet just does a great job of not only advocating within Cisco, but outside of Cisco as well, so we make sure that their voice is heard, if there's some oddity with an API, which, you know, I'm really into API design, API style, we can kind of look at that first, and kind of look at it sideways and then talk to the teams, okay is there a better way to think about this from a developer standpoint. >> It's great, I love the API love there, it's going around a lot here. DevNet create a cloud native vibe that's kind of integrating and cross-pollinating into DevNet, Cisco proper. You're no stranger to cloud computing early days, and ecosystems that have formed naturally and grown, some morph, some go different directions, so you're involved in OpenStack, we know that, we've talked before about OpenStack, just some great successes as restarts, restarts with OpenStack ultimately settled in what it did, the CNCF, the Cloud Native Computing Foundation, is kind of the cloud native OpenStack model. >> Yeah, yeah. >> You've seen the communities grow, and the market's maturing. >> Definitely, definitely. >> So what's your take on this, because it creates kind of a, the creator builder side of it, we hear builder from Amazon. >> Yeah, I feel like we're able to bring together the standards, one of the interesting things about OpenStack was okay, can we do open standards, that's an interesting idea, right? And so, I think that's partially what we're able to do here, which is share, open up about our experiences, you know, I just went to a talk recently where the SendGrid former advocate is now working more on the SDK side, and he's like, yeah the travel is brutal, and so I just kind of graduated into maintaining seven SDKs. So, that's kind of wandering from where you were originally talking, but it's like, we can share with each other not only our hardships, but also our wins as well, so. >> API marketplaces is not a new concept, Apache was acquired-- >> Yes. >> By a big company, we know that name, Google. But now it's not just application programming interface marketplaces, with containers and server space, and microservices. >> Right. >> The role of APIs growing up on a whole other level is happening. >> Exactly. >> This is where you hear Cisco, and frankly I'm blown away by this, at the Cisco Live, that all the portfolio (mumbles) has APIs. >> True, yes, exactly. >> This is just a whole changeover, so, APIs, I just feel a whole other 2.0 or 3.0 level is coming. >> Absolutely. >> What's your take on this, because-- >> So, yeah, in OpenStack we documented like, two APIs to start, and then suddenly we had 15 APIs to document, right, so, learn quick, get in there and do the work, and I think that that's what's magical about APIs, is, we're learning from our designs in the beginning, we're bringing our users along with us, and then, okay, what's next? So, James Higginbotham, I saw one of his talks today, he's really big in the API education community, and really looking towards what's next, so he's talking about different architectures, and event-driven things that are going to happen, and so even talking about, well what's after APIs, and I think that's where we're going to start to be enabled, even as end users, so, sure, I can consume APIs, I'm pretty good at that now, but what are companies building on top of it, right? So like GitHub is going even further where you can have GitHub actions, and this is what James is talking about, where it's like, well the API enabled it, but then there's these event-driven things that go past that. So I think that's what we're starting to get into, is like, APIs blew up, right? And we're beyond just the create read. >> So, user experience, developer experience, back to what you do, and what Mandy was talking about. You can always make it easier, right? And so, as tools change, there's more tools, there's more workloads, there's more tools, there's more this, more APIs, so there's more of everything coming. >> Yeah. >> It's a tsunami to the developer, what are some of the trends that you see to either abstract away complexities, and, or, standardize or reduce the toolchains? >> Love where you're going with this, so, the thing is, I really feel like in the last, even, since 2010 or so, people are starting to understand that REST APIs are really just HTTP protocol, we can all understand it, there's very simple verbs to memorize. So I'm actually starting to see that the documentation is a huge part of this, like a huge part of the developer experience, because if, for one, there are APIs that are designed enough that you can memorize the entire API, that blows me away when people have memorized an API, but at the same time, if you look at it from like, they come to your documentation every day, they're reading the exact information they can give, they're looking at your examples, of course they're going to start to just have it at their fingertips with muscle memory, so I think that's, you know, we're starting to see more with OpenAPI, which is originally called Swagger, so now the tools are Swagger, and OpenAPI is the specification, and there's just, we can get more done with our documentation if we're able to use tools like that, that start to become industry-wide, with really good tools around them, and so one of the things that I'm really excited about, what we do at DevNet, is that we can, so, we have a documentation tool system, that lets us not only publish the reference information from the OpenAPI, like very boring, JSON, blah blah blah, machines can read it, but then you can publish it in these beautiful ways that are easy to read, easy to follow, and we can also give people tutorials, code examples, like everything's integrated into the docs and the site, and we do it all from GitHub, so I don't know if you guys know that's how we do our site from the back side, it's about 1000 or 2000 GitHub repos, is how we build that documentation. >> Everything's going to GitHub, the network configurations are going to GitHub, it's programmable, it's got to be in GitHub. >> Yes, it's true, and everything's Git-based right? >> So, back to the API question, because I think I'm connecting some dots from some of the conversations we had, we heard from some of the community members, there's a lot of integration touchpoints. Oh, a call center app on their collaboration talks to another database, which talks to another database, so these disparate systems can be connected through APIs, which has been around for a while, whether it's an old school SOAP interface, to, you know, HTTP and REST APIs, to full form, cooler stuff now. But it's also more of a business model opportunity, because the point is, if your API is your connection point-- >> Yes. >> There's potential business deals that could go on, but if you don't have good documentation, it's like not having a good business model. >> Right, and the best documentation really understands a user's task, and so that's why API design is so important, because if you need to make sure that your API looks like someone's daily work, get the wording right, get the actual task right, make sure that whatever workflow you've built into your API can be shown through in any tutorial I can write, right? So yeah, it's really important. >> What's the best practice, where should I go? I want to learn about APIs, so then I'm going to have a couple beers, hockey's over, it's coming back, Sharks are going to the next round, Bruins are going to the next round, I want to dig into APIs tonight. Where do I go, what are some best practices, what should I do? >> Yeah, alright, so we have DevNet learning labs, and I'm telling you because I see the web stats, like, the most popular ones are GitHub, REST API and Python, so you're in good company. Lots of people sitting on their couches, and a lot of them are like 20 minutes at a time, and if you want to do like an entire set that we've kind of curated for you all together, you should go to developer.cisco.com/startnow, and that's basically everything from your one-on-ones, all the way up to, like, really deep dive into products, what they're meant to do, the best use cases. >> Okay, I got to ask you, and I'll put you on the spot, pick your favorite child. Gold standard, what's the best APIs that you like, do you think are the cleanest, tightest? >> Oh, best APIs I like, >> Best documented? >> So in the technical writing world, the gold standard that everyone talks about is the Stripe documentation, so that's in financial tech, and it's very clean, we actually can do something like it with a three column layout-- >> Stripe (mumbles) payment gateway-- >> Stripe is, yeah, the API, and so apparently, from a documentation standpoint, they're just, people just go gaga for their docs, and really try to emulate them, so yeah. And as far as an API I use, so I have a son with type one diabetes, I don't know if I've shared this before, but he has a continuous glucose monitor that's on his arm, and the neat thing is, we can use a REST API to get the data every five minutes on how his blood sugar is doing. So when you're monitoring this, to me that's my favorite right now, because I have it on my watch, I have it on my phone, I know he's safe at school, I know he's safe if he goes anywhere. So it's like, there's so many use cases of APIs, you know? >> He's got the policy-based program, yeah. >> He does, yes, yes. >> Based upon where's he's at, okay, drink some orange juice now, or, you know-- >> Yes, get some juice. >> Get some juice, so, really convenient real-time. >> Yes, definitely, and he, you know, he can see it at school too, and just kind of, not let his friends know too much, but kind of keep an eye on it, you know? >> Automation. >> Yeah, exactly, exactly. >> Sounds like great cloud native, cool. You have a Meraki hub in your house? >> I don't have one at home. >> Okay. >> Yeah, I need to set one up, so yeah, we're terrible net nannies and we monitor everything, so I think I need Meraki at home. (laughing) >> It's a status symbol now-- >> It is now! >> We're hearing in the community. Here in the community of DevNet, you got to have a Meraki hub in your, switch in your house. >> It's true, it's true. >> So if you look back at last year's Create versus, I know we're just through almost day one, what are some of the things that really excite you about where this community of now, what did they say this morning, 585,000 strong? Where this is going, the potential that's just waiting to be unlocked? >> So I'm super excited for our Creator awards, we actually just started that last year, and so it's really neat to see, someone who won a Creator award last year, then give a talk about the kind of things he did in the coming year. And so I think that's what's most exciting about looking a year ahead for the next Create, is like, not only what do the people on stage do, but what do the people sitting next to me in the talks do? Where are they being inspired? What kind of things are they going to invent based on seeing Susie's talk about Wi-Fi 6? I was like, someone invent the thing so that when I go to a hotel, and my kids' devices take all the Wi-Fi first, and then I don't have any, someone do that, you know what I mean, yeah? >> Parental rights. >> So like, because you're on vacation and like, everybody has two devices, well, with a family of four-- [John] - They're streaming Netflix, Amazon Prime-- >> Yeah, yeah! >> Hey, where's my video? >> Like, somebody fix this, right? >> Maybe we'll hear that next year. >> That's what I'm saying, someone invent it, please. >> And thank you so much for joining John and me on theCUBE this afternoon, and bringing your wisdom and your energy and enthusiasm, we appreciate your time. >> Thank you. >> Thank you. >> For John Furrier, I am Lisa Martin, you're watching theCUBE live from Cisco DevNet Create 2019. Thanks for watching. (upbeat music)