(bouncy music) >> Welcome to this Cube Conversation, I'm Lisa Martin. I'm joined by Erez Berkner, the CEO and co-founder of lumigo. Erez, welcome to the program. >> Hey Lisa, thank you for having me. Glad to be here. >> Excellent, we're going to have a great conversation. We're going to be talking about the growing trend of using cloud native and serverless. But before we do, Erez, give our audience an overview of lumigo. >> Excellent, so lumigo is an observability platform. Basically allowing developer, architects, the technology person in the organization to understand what's going on with his modern cloud, with his serverless, with his cloud native application. So at the end of the day, lumigo as assess platform, allow you to know what's happening, get visibility, and be able to get to the root cause of issues, many times before they actually hit your production. >> I saw on your website, in terms of speed, getting up and running quickly, in four minutes with four clicks. Tell me how developers do this that quickly. >> Yeah, that's actually great point. Because in general, when we talk about the modern cloud, people are really fed up with deploying agents, long processes of servers, and more and more we see the trend towards APIs, toward code libraries. At the end of the day, at the heart of lumigo, we built a very strong automation engine based on APIs, based on lomdalier integration. And this allows a developer to basically connect lumigo via the APIs in couple of clicks. Doesn't require code changes, deployment of agents, deployment of services. And this is why it's so fast, because it's lightweight. And that's a trend of managed services, of serverless, and lumigo is another stone in that wall. >> Excellent, lightweight, key there. Define serverless, what is considered serverless? >> Mmm, ooh, don't get me involved in dispute of those definitions. But I can share my view, but this is a.. Anyone, I would say, have his own definition. But the main concept with serverless is at the end of the day, really, like it says, serverless. You don't deploy a server. You don't rent a server, you don't manage a server, you don't deploy an operating system, you don't patch a server. You don't take care of scalability, of high visibility. Basically, all the chores of managing, of maintaining a server, basically go away. Now, they don't really go away. Somebody else is dealing with them. So there is a server, but it's not your server to manage. And that someone is a cloud provider, is Amazon, is Microsoft, is Google, it's IBM. And this is how I view serverless. Basically, a managed service that doesn't require to deploy or manage a server, and you use it via APIs. And if you think about that, in the past when serverless started, 2015, serverless was function as a service, Lambda, AWS started that. But today, in 2021, serverless, yeah, it's function as a service, it's Lambda, but it's also storage as a service, like S3, and data as a service, like Snowflake, like DynamoDB. And queue as a service like SNS, like EventBridge, like Kenesis. And even Stripe, payment a as service, and Twilio, and SendGrid. So all these API based services, that you just consume, and they're like Lego pieces that you connect together and you just connect and you go, and you start working and they up and running, this is how I define serverless today. And that's basically allowing you to run any application today with zero servers. >> That's a great definition, that nice and clean, and I think the Lego bricks really kind of clicked in my mind when you talked about that. Let's talk now about for business critical production applications, what are you seeing in terms of adoption of serverless for those cases? >> That's a great question, because I think that we are in a critical point of time, in cloud native, in modern cloud, in serverless market. And I think it's an evolution. You know, when we started, again, back in 2015, serverless was just one or two services. But we got to a critical mass of services, including DynamoDB and S3 and Lambda and EventBridge and all the other services, that step function, that basically allow you to build your application based on serverless. And this critical point of the architecture of serverless being mature enough, being wide enough, to allow you to do what you want, to have the confidence running serverless in production, to know that you have the tooling that you used to have in the past to monitor, to debug, to secure, to understand cost, all of this are really coming together this year. We actually see this year, and a bit of end of last year, but this is what's driving a trend in the industry. I think it's still not known enough to many of the organizations, or not wide enough, or not public enough. But our customers are focused on cloud native and serverless. And we've seen a dramatic change in the last six months. And the main change is organizations that used to play around with serverless, that used to do non-business critical usage of serverless, because it's easy, because it makes sense, because it's fast, all of a sudden they got the confidence to do that with their business critical application in production. And this is a shift that we're seeing. And that goes many times with the technology maturity. You start, you play around with something, it makes sense, it makes sense, you get confidence, and boom! This become more and more mainstream technology. And we're at the verge of that. >> In terms of a catalyst for that confidence, do you think that the events, the world events of the last 12 months and this acceleration of digital transformation, has that played any part in the maturation of the technology that's giving customers the confidence to adopt serverless? >> Yeah, I think it's fascinating, what we're seeing. Because I think the last event really push a organization to innovate. Because of different reason, because they don't have the head count, so they need to reduce the maintenance that they do, they need to reduce the developer head count, the DevOps head count, they need to reduce costs. Serverless is running only when it need to run, so you pay only for what you use. So this is another method that our customer, for example, reduce their cost. So I think beyond the maturity of the architecture, the push forward for optimization, for lower usage or lower usage of engineering force, really pushed serverless forward. And this paradigm, once it worked for one team, it's viral. It's viral with in organization and the cross-organization. So this team managed to reduce 50% of the cost, and 70% of the developers that need to maintain the production. Let's duplicate that. And let's do that four times, and five times, and 10 times. And this is the point in time that we are. So that's a trend and I think it's very much impacted by the world economics. >> Interesting, that trend of virality. Let's dig into, you mentioned a couple of benefits. I heard reduction in total cost of ownership, or costs. Talk to me about the lumigo solution, the technology, and what some of those key benefits are that it is consistently delivering to your customers. >> So I think the basic is that serverless makes a lot of sense, economical, maintenance. That's why the cloud providers are putting so much effort and power in delivering more and more serverless maturity. One of the challenges that we see for almost any organization adopting the new technology, it goes back to we understand the values, but at the end of the day I need to make sure that if something goes wrong in production, I will know about it and I will know how to react and fix it in a matter of minutes. 'Cause that's my service, that's my business. And I know how to do it in a server world, where there's one server or three servers, and everything running in the same server. I have the tools for that. And I want to go serverless, I want to go cloud native, but all of a sudden there are dozens of services that I consume via APIs and they're a part of a bigger picture of my application. So I'm lacking many times the confidence, the tools, the awareness of, something goes wrong, I'll know about it, and I'll be able to fix it. And this is where lumigo comes in. So we built lumigo from the ground up to be very much focused on the modern cloud, on serverless. And that means two main things that we provide for our customers. One is, I would say one thing. We provide confidence. You can use serverless in production, and you can rest assured that if something goes wrong, you will be the one alerting and we'll give you all the information to debug it. And we do it by two main things. One is the visibility that we create. Because we're connected to the environment, we alert on things that are relevant to serverless. It's not about CPU, it's not about a iO. It's about concurrency limits, it's about cold start, it's about time outs, it's about reaching duration limits. These are the things that we know to alert you about. It's very specific to the serverless services. And it's not a generic metric, it's serverless metric. So that's number one, visibility, getting alert whenever something is about to go wrong. But what do you do then? Let's say I have one million invocations a day, and one of them is actually, I have a trigger, something went wrong. And this is where lumigo allow the developers to debug. Basically, you click on a specific issue, and lumigo tell you the entire story of what happened, from the very beginning, an API gateway triggering a Lambda, right into DynamoDB, triggering an Lambda, it tell you the entire story end to end of what happened with that specific request, with inputs, with outputs, with environment variables. All the things the developer need in order to debug, to find the root cause, and then fix it in matter of minutes. And that's the game-changer that allow those organizations to run serverless with confidence. >> You talk about confidence, it's a word that I hear often when I'm talking with customers of vendors. It's not something to be underestimated. It's incredibly important that technology provide that confidence, especially given the events of the last year and a half that we've seen where suddenly folks couldn't get into data centers, for example. Talk to me a little bit about some of the customers. I saw from your website some great brand names, but talk to me about a customer that you think really not only has that confidence that lumigo is delivering, but is really changing their business and their approach to modern monitoring with lumigo. >> Yeah, so there are several interesting. I'll choose maybe one of the more interesting cases, a company called Medtronic. It's one of the largest medical device companies in the U.S. And it's very interesting because they have an IoT backend. Basically they have medical devices around the world that send IoT information back to their cloud. And they get metrics, they run machine learning on that. And they took a strategic decision to run the system with serverless. Because it can scale automatically, because it can deploy one more million devices and they don't need to change anything, and many, many other benefits of serverless. And we met them back in 20, end of 2019. They were looking for exactly a solution that allows them to get issues and drill down to analyze those issues. And they were just in the beginning. The early days they had 20 million invocations, requests per month. They knew they were going to scale, they knew that when they scale, they cannot correlate logs, and try to understand what happened manually. They need a professional tool. And this is where they started using lumigo. And today, a year and a half after, they reached one billion invocations a month. Again, the same concept, IoT devices, medical devices, sending metrics and information for the backend for processing. And today, lumigo is monitoring everything in that environment. And alert them from, you're about to have a problem, or you have an application error, or you have high latency, you have spike of cost, all of that are covered by lumigo. And the developers, once they get this to slot, to play the duty, you're just able to click on it, and drill down and see, one by one, requests that created the trigger that alert. And they can understand, again, the inputs, the output, the logs, the return values, everything. I call it debugging heaven. Because it's always there, it's always post-mortem, you don't need to do anything. At the same time you get the visibility and you can fix it, because this is their production, this is their business critical application. >> Debugging heaven, I love that. That's for developers, that is probably a Nirvana state. I want to wrap up Erez, just giving our folks in the audience an overview of the relationship that lumigo has with AWS. >> AWS is one of our strongest partner. I think there's a great synergy working with AWS. We've been partners for the last three years. And I think the reason for the... You know, we're still... AWS has thousands, tens of thousands of partners. I think that this partnership is specifically strong because there is a win-win relationship over here. On the one hand side lumigo is very much invested on Amazon. Our customers are mostly Amazon customers, and we are solving, providing confidence for those customers to run serverless in production, and answering a need of a customer. And this is also the win for Amazon. Amazon is basically have a great, great technology of serverless. But the lack of visibility, the lack of confidence, is hindering the adoption. And Amazon decided to work with lumigo, saying, we'll develop the core, we'll develop the services, we'll develop the serverless architecture, and you can use lumigo for monitoring, for debugging, for everything that you need in order to run that in production. And that's been very, very strong relationship that just grows as we develop together. And it's been on working together with customers, introducing customers, but also on the technology level. For the audience who sees Amazon announcement on serverless, many times lumigo is a design partner. It's part of the announcement, of lumigo was a design partner and the launch partner, and support the new feature out of the box. This is because we want to get the support as soon as possible, as soon as new features are released. So that's where we are today. >> Sounds like a very collaborative and symbiotic relationship. Erez, thank you for joining me on the program today, talking to us about some of the trends in serverless, some of the things that are catalyzing adoption, that visibility, that confidence, that lumigo delivers to its customers. We thank you for your time. >> Excellent, thank you very much Lisa. Have a good day. >> You too! For Erez Berkner, I'm Lisa Martin. Thanks for watching this Cube Conversation. (bouncy music)

>> Announcer: From theCUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. >> Hi, I'm Stu Miniman and welcome to a special CUBE conversation. I'm coming from the Boston area studio. We were supposed to have a KubeCon Europe in Amsterdam. First in the spring, they pushed it off to the summer, and, of course, the decision due to the global pandemic is it's making it virtual. But happy to welcome to the program two guests that I was planning to have on in person, but couldn't wait for our virtual coverage of the event, though. Happy to welcome the co-founders of TriggerMesh. Sitting in the middle is Mark Hinkle, who is the CEO of the company, and to the other side is Sebastien Goasguen, who is also the co-founder and the Chief Product Officer. Gentlemen, thanks so much for joining us. >> Thanks for having us, Stu. >> Thanks, Stu. >> All right, so, it's interesting, we've been covering the cloud native space for a number of years, and especially at KubeCon, there's always some of those discussions of does cloud kill on-premises, does this new thing kill that old thing. And in some of the early days of KubeCon, it was like, well, containers are really interesting, and there was all the buzz for years about Docker but, hey, the next thing is going to be serverless. And serverless, we don't need to think about any of that stuff, it's the nirvana of what developers wanted. So therefore, let's not worry about containers, but you sit in that space really helping to connect between some of the various pieces. So, I guess, Sebastien, maybe if I could start with you, 'cause you've built some of these various projects, when you go through and look at your background, you've been involved in the co-business space, uBLAS, and now for TriggerMesh but, you know, give us some of that background as to how, from a technological under pinnings, the community's been thinking about how these worlds fit together. >> Yeah sure, it's very interesting because first, the container rejuvenation started with Docker obviously and then Kubernetes appeared, and the entire community started building this. And this was really an evolution from the virtual machine orchestration, right. People needing a better way to package applications, deploy them, and they said, "You know what, "virtual machines are not that great for this. "Can't we have a better vehicle to do this" and that's where, really, containers took over. And it made total sense and so we saw this switch from, craziness about open stack and even cloud stack that Mark and I worked on, and putting all the focus on containers. And then comes AWS always innovating, always in the lead, and AWS saying, "Hey, you know what? "Actually, we need to go serverless. "We need to forget about the infrastructure. "What people want is really deploy applications "without worrying about the infrastructure. "They want things that are going to auto scale. "They want to pay very little, even pay per function call "and not pay when your VM is up." So AWS really pushed this mindset of serverless, but then what was the meaning in that realm of containers, and that's when I started Kubeless and I said, "You know what, if you would need to build function "as a service, you should build it on Kubernetes, "and use Kubernetes as a platform." And from there we started started seeing this fight, a little bit, between people, saying "Hey, forget containers, go serverless." So in TriggerMesh, we're not really taking that stance. We really see on-premises has, it's always going to be here, we have worked clouds on-premises, we have our own data centers but definitely there is more and more cloud usage, and when you start using the cloud you don't want to care about the infrastructure in the cloud, right. So, you want as much serverless as possible in the cloud, but you know you have to deal with your on-premises, data bases and some work loads and so on. So you have to be a pragmatic and you have to pick the best of both worlds and keep moving to modernize your stack and your IT in general. >> Excellent, alright so Mark, at the CNCF I'd seen the Knative project come out and it was talking about how we can connect containers and serverless, and one of the questions I'd been asking is "Well look, there are a lot "of open source projects for serverless." But when I talk to the community, when I talk to users, you say serverless, I think AWS. Sebastien was just talking about, so, I was sitting at the KubeCon shows and talking to the vendors and a lot of really big vendors were working on Knative, Oracle, IBM, RedHat and others and I said if this doesn't connect with AWS first and Azure second, I don't understand what we're doing. Yes, there's probably a place for on-premises but that was when, I think you and I had a conversation, we'd been looking at this space, so how did the ideas that Sebastien talked about turn into an initiative and a company of TriggerMesh. >> Well, early on we latched onto the Knative announcement that Google made. Google had given Sebastien some insight into where they were going with serverless, and the Knative project before it launched. And then they actually quoted him in the release which started interest in our company which was the only company in name at that point. But we really didn't know where Knative and Kubernetes together were going and the serverless movement, but we thought at first that there would need to be management capabilities to do lifecycle management around serverless functions, but what we realized, or Sebastien realized, early on was that it's not so much the management of serverless, because the whole idea of serverless is to abstract away all of the severs and architecture so that all you're really dealing with is the run time. So the problem that we saw early on was not managing but actually integrating applications across serverless framework, so the name TriggerMesh, that came from the idea that you trigger serverless functions and that you would mesh architectures whether they be legacy applications or they be file services or other serverless clouds across the fabric of the internet. So that's Triggermesh and that's really where we're going and we see that there's a couple of proof points in our industry for that already and people having the desire to do that. >> All right excellent, so that integration that you're talking about. Help Sebastien explain, there's some news I believe its the EveryBridge Cloud Native Integration Platform that's just announced. Help us understand what that is and what should we be kind of comparing it to other solutions in the industry today. >> Yeah so, you know we are very happy about the EveryBridge announcement and it's really, we're getting beta, we are doing a beta release of EveryBridge available in our SaaS cloud, the Triggermesh.io and really to first piggy back on what Mark was saying, is that a lot of people still believe serverless is just functions, right. And for us serverless is much more than this. Serverless is about building event driven applications. We see it with AWS, with things like they are doing with EventBridge, for example, but we really believe in this mindset. What we are trying to do is to help people build applications, build cloud native applications, that fundamentally are event driven and they are linking cloud services in the public cloud providers and also on-premises work load, right. So EveryBridge allows people to do this, to build those cloud native apps as basic event flows that connect event sources wherever they are, could be events that are on-prem from an eCommerce application, ERP application, could be events that are circulating through a Kafka infrastructure on-prem, and people can connect those event sources with what we call targets. So those targets could be on-premises, they would be OpenShift work loads for example or they could be in the cloud at AWS lambda functions, Google cloud run, or even dedicated SaaS like Twilio, SendGrid, and so on, so that's when we saw really over the last 18 to almost two years now, is that serverless is more of an integration problem, more like traditional IPaaS that we've seen, right. So basically we are building a new IPaaS solution at the frontier of serverless offerings from the public clouds, traditional messaging systems like Kafka, Remittent, Q and so on, plus the, I would say, the old IPaaS solution and we're doing all of this backed by Kubernetes and Knative. >> Excellent, so Mark I heard Sebastien talking about, he mentioned OpenShift, talked about Google, speak a little bit to really the ecosystems, the market places that TriggerMesh fits into. What are the use cases that you are seeing customers using. >> Yeah, I think a couple of the, to the dive into the on-prem triggers we have capabilities to trigger oracle database changes that could actually pick off cloud based ETL transactions. We're seeing that users are going through digital transformation and really to be more specific given the global climate right now, it's remote work, and the idea of lifting and shifting all of your infrastructure into the cloud is pretty daunting and long ask, but if you can front end those systems with new cloud native architecture and you have a way to create those event flows to tie in your existing systems to new portals for your employees to get their work done, automate workflows to provision new systems, like Zoom for example, and other conferencing systems, you can use the serverless front ends and work flows that actually integrate with all of your existing infrastructure and give you a way to extend your life of your applications and modernize them. >> Yeah, the long pole on attending modernization is that application. Sebastien maybe I'd come to you on this is, I think about iPaaS, when you look at that space they talk about all the integration that they need to work on, usually there are certifications involved, you mentioned Oracle databases, these are things that we need to go in there with a engineering effort and make sure that it is tested and certified by the ISV out there. Does containerization, Kubernetes, and serverless, does this change it at all, does this make it easier to move along these environments? I guess the question is for the enterprise, normally this change is rather slow. Mark was just alluding to the fact that we need to do some of these things faster, to try to react from what's happening in the world. >> Yeah, I think that's the entire premise of containers. It's speeding up the software life cycle and the speed at which we can deliver new features, for all our applications and so on. So, a big part of the job, when Docker started and then Kubernetes has been, if you adopt that type of infrastructure and that type of artifact, containers, you're going to speed up your software management and software delivery. So now what happens is that you have slow moving pieces, maybe pieces that you've had in your data center for 10, 20 years, for quite a while, and then you have these extremely fast moving environment, which is containerized and running Kubernetes plus the cloud. That's even, we could say even faster moving, and you can, that's definitely the challenge, that's where we see the value and that's where we see the struggle, is that you have all those big companies that have those slow moving pieces Oracle DB, IBM MQ, and so on and they need to make those pieces relevant in a fast moving containerized world and in a cloud native world, right. So how do you bridge that gap? Well that's what we do, we provide bridges. We provide integration bridges with every bridge, there you go. So we connect the event sources from Oracle DB and MQ and we bring that to a more fast moving cloud native environment, whether it's managed Kubernetes on Google GKE or whether its still on-prem in OpenShift. >> Mark, want to get your view point, just being a start up in today's global environment, obviously, you look at the cloud data space, many of the companies are distributed. We're talking to Sebastien from over in Europe, you're down in North Carolina, but give us your view point as a startup. How is the current economic environment impacting you, impacting your partners, impacting your customers. >> So, our partners and customers are probably moving more slowly than we do as a startup because they had physical brick and mortar offices and now they are coming into our world. We're 100% virtual, we're in 3 continents across over 12 time zones. That kind of work versus where they're at, I think everybody is consciously moving ahead, the one thing that I will say is that their interest in being more like the startups that are virtual, don't have brick and mortar, are really good at online collaboration. They look at us for sort of inspiration on how they are going to do business going forward or at least for the foreseeable future. So, overall I think that, not only are we teaching them about cloud native technologies but we're just teaching them about distributed work forces in a quarantined world. >> Absolutely, and I think those are some of the key learnings that you look at that are diversity consistent in the cloud native space. Want to give you both a final word and-- >> And Stu if I just add something. Mark and I have been working from home for quite a while, eight to 10 years, and definitely right now this is not the normal working from home, right, we all have, most of us have kids at home 24/7. The cognitive load in the news is huge, this is not the normal environment. So we are extremely careful, we help each other definitely internally in the team, you know, India, Vietnam, Germany, Spain, U.S. We have to be extremely careful that everybody is not falling down and putting too much on the nerves and their spirits right, so not a normal environment and even though we know how to do it we have to be careful. >> Yeah Sebastien, I'm so glad you brought that up 'cause this is not just a, how do we move to a distributed system. There is the rest of the impact on that. All right so lets give you both final words. Hopefully, we absolutely will be gathering together even if we are remote for the KubeCon event for Europe, other event later on this year, but Sebastien let's start with you, final take aways. >> Yeah, so we are very excited to build a startup. It's fast moving, its an exciting industry and really seeing the beta release of EveryBridge for us. We are trying to bring the future of event driven application to everybody, event sources to targets for everyone, not just on AWS and taking all of the strength of Kubernetes with us. It's going to be a familiar system for all Kubernetes lovers. >> Great, and Mark. >> Well as we talked about today, we are very excited about the EveryBridge announcement, and if you are interested in a cloud native, serverless, digital transformation we think we have great tools for you. But on a more personal and global note, I think Sebastien hit something that's really important, it's that even though we are not all together it's really important to check in. Even these virtual sessions have been, it's nice to interact with your colleagues and friends in the industry but be kind to each other and don't just take it for granted. that everything is good at the other end of the wire so reach out to each other and we'll all get through this together. >> Well Mark and Sebastien, thank you so much for joining us. Absolutely the personal pieces as well as TriggerMesh. You're helping to pull some of those technology communities together so congratulations on the progress and definitely look forward to tracking where you go from here. >> Thanks Stu. >> Thanks a lot. >> We appreciate it. >> All right be sure to check out theCUBE.net, we will be covering KubeCon and CloudNativeCon Europe as it goes virtual as well as lots of others in the cloud developer space. I'm Stu Miniman and thank you for watching theCUBE. (upbeat 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)