>> live from Mountain View, California It's the queue covering definite create twenty nineteen Brought to you by Cisco >> Hey, welcome back to the cave, Lisa Martin with John Barrier. We're coming to you Live from the Computer System Museum at the third annual Cisco Definite Create twenty nineteen Excited to be joined by Joycelyn Developer Advocate from Postman Joyce Welcome to the Q Thank you. So you are a developer advocate. But postman is a tool that helps the community learn about Cisco ap eyes Postman is a Cisco was a customer of yours but a little bit about your experience at definite cry Because you have an interesting story from last year, which was your first year of this event >> Exactly last year. We just happen to stop by. And as I was walking through this very room you hear all these workshops going on behind us My ears perked up cause I heard somebody say python in postman or two of most powerful tools And I was like, Hey, I >> work a postman >> So I like, stopped in to see and I slapped my team back immediately at the office there, really using postman to teach Cisco Technology here. >> That was surprising to you. And here you are now here a year later. Tell us some of the things that you're expecting to learn and hear and feel and see from twenty nineteen. Create. >> So this year I hear about all these people learning postman learning about tech through postman. So I'm actually giving to talks this afternoon The first talks talking about building the community because a lot of people use postman in the second talk is about using mock servers. Had a fake an AP I until you actually coded and deploy it. >> Take a minute to explain. Postman. Why is it so popular? Why Francisco jazzed about it? What are they using it for? How they bring that in take a minute to talk about what you guys do >> Well, several years ago, when postman started as a side project was primarily for developers and help developers do their day to day jobs. But we found a lot more People are interacting with technology or working at tech companies where they might not have the setup to initiate a request. AP I request, and so postman allows them tio on their desktop be able. Teo interact with the tech in a way that normally they wouldn't have the whole set up to do it. >> So So in terms of developers, what's is a freemium model? They do have a free hand leads >> premium. And I think within the last year we've scooch almost anything that used to be a paid feature down to free so you can try it out. And in fact, if you have a small business or a side project, it's it's free. >> And what's the talk track? You're gonna have to get to talks. One on community, one on serve servers. Monster. >> Yeah, So Mock service is something that I thought might be interesting to this crowd. But a lot of these people have are in charge of managing the infrastructure or supporting existing AP eyes or services that are out in the cloud. And so mock servers are a way that you can essentially mock an FBI for parallel development or to build a prototype put into >> you. And so this helps develop, get faster app up and running. And then what happens when they have to get rid of mock server and put a real server on there? They had built out the re p I. Is that what happens? >> Typically, they're spinning Oppa marks over first, and then they're building out their own servers. So, yeah, they would swap out the mock with their own. >> And what's the other talk on community? Just how did do a community open sores? What's the aspects of the community talk? >> It's kind of on >> odd topic for this kind of crowd, but a lot of people work for companies that are or work for teams where they're just trying to build, like, a sense of community or foster some sort of mission. And so just telling the Postman story and Postman was free for absolutely free for a super long time in growth has just been astronomical. >> You're six million developers on the planet working on that, but I can't say on the company's one hundred thirty million plus AP eyes. And that's all. Just since the company was established in twenty fourteen after this sort of side project that you talked about so pretty, >> pretty quick >> growth trajectory that you guys are on >> and a lot of it was word of mouth. I mean, until I came here last year and heard all the system people talking about how they're using postman. We did not know that. >> So how have how has Postman actually evolved your technology in the last year? Just since you stumbled upon? Wow, this we're actually really hot here. We are really facilitator of developers. This community that's now what five hundred eighty five thousand members strong Learn about Cisco AP eyes. I'd love to know how that has sort of catalyzed growth for postman. Well, back in the >> day, Postman started as developer first. So here's an individual developer. How can they work more effectively? But teams like Cisco you'll be lucky if you find a team of ten people these air hundreds and thousands of developers coming together to work together. So postman as a tool has shifted from focusing on on ly the developer to how do you support developers working in larger teams? >> So what? The community angle? Because one of the things that Lise and I were just talking about you she does a lot of women in tech interviews with Cube and we're building out these communities ourselves and in Silicon Valley, the old expression fake it till you make it. It's kind of a startup buzzword, but people try to fake community or by community. You really can't get away with that. In communities, communities are very fickle. A successful open source projects you've gotta contribute. You've gotta have presence. You've got to show your work to get you to the bad actors. It's >> pretty >> efficient. But things air new now in communities this modern era coming into slag, you got tools. How is community evolving? That's your perspective on this. >> That's an interesting question. I think the community you never wanted fake community absolutely agree, and something that Postman is kind of lagged on is the community's been huge, but we haven't really been involved. So around the world we have people giving workshops that we don't even know about, like around the world. And how can we support them and allow them to tell, teach things consistently and teach best practices? So I wouldn't say unfortunately, well or fortunately, we're not in the position where we have to encourage the growth, but rather just support the people that are already doing this. This >> is the pure ingredient Teo Community development, because you're enabling other people to be relevant with their communities. So you're not so much like just trying to be a community player. You're just your product enables community growth. >> Absolutely. Yeah. >> You just gotta come feed >> postman as a tool. And then postman, the seeds >> of community. >> Yeah, we're healthy. >> So talk about some of the where you guys locate. How many people in your company? What's this? What numbers >> were headquartered in San Francisco. We have a huge engineering department in Bangalore where our founders air from. And I think just a few months ago, we started having distributed people. So now we're everywhere. I think we're about a hundred head count. Uh, fifty five percent of that is engineering. So where? I don't know where a >> start off. I mean, they were started hunting with number two hundred thousand companies using the technologies. We said over six million developers. How do you get a handle on to your point earlier supporting all of these groups that are out there enabling us Johnson enabling and fueling communities like Deb. Nanny? How do you start that with a one hundred person organization? >> Yeah. I'm so glad you're like, Wow, that doesn't seem like a huge organization because other people are like I thought you are way bigger than that. One thing is that we do listen to our community. And so if they're having a pain point way, try to aggregate all those voices and then come out with a cohesive road map because what might be the loudest voice for even a lot of voices might not be what's right for the tool. The other thing is, we're not open source company, but we have a ton of open source projects. So the community has again developed converters, integrations all these open source tools that for their specific workflow works for them. And actually, they're sharing with the community. >> How did you get into all this? How did you join the company? What attracted you and what's what story? >> Well, I'm in San Francisco, so I work for a tech company. I have a hodgepodge background, but I won't go into because it just sounds confusing. Some people call me the Wolverine at work. >> That's a nickname. >> Um, hopefully it's not because I'm so Harry, but because I've had many lives, so I I kind of bring a little bit of that, too. My developer advocate role, a little bit of product, A little bit of marketing, little bit of the business side. >> It's good versatility, lot of versatility. Yeah, let me ask a question. One of the things we've been covering is actually we love cloud nated. We've been covering cloud in the early days. Oh, wait. Oh, seven All the way through Love Cloud native We get that check enterprises Ha! You see Cisco using your stuff. Enterprise developers are hot right now. People are fast filling applications has got a cloud native flare to a definite create. It's also gotta integrate into the classic enterprise. What's the difference in your view and your experience, your observations between enterprise developers and then your classic You know, hard core cloud native developer >> I would say that's something that postman, as an organization is dealing with right now because we started developer first. Now we're finding Oh, it's a different person making these decisions. What tools should we use? Sometimes it's top down, but at the end of the day, it's always the developer that is going to support a top down decision. A developer that's going to find the utility out of certain tool. So we're shifting our focus. But not necessarily by that much. Because long as you focus developer first, it's still >> so enterprise. Kind of taking more of a classic cloud developer or native cloud native developer. You think that kind of profile you in your mind? >> Well, again, you have an enterprise developer. But what? Where's that enterprise developer going to be in two years? So we're not hanging our hat too much on Enterprise? Only now >> what do you want? The Ciscos measures of programming. The network. I mean, infrastructure is code. That's kind of a nice value proposition. Take the complexity away. What's your take on reaction toe that vision? >> I don't know what you're talking >> about. I don't know what part. >> What part of tell you are. >> Well, they're saying developers shouldn't have to configure hardware. You know, abstract the network capabilities out and make it code. So the developers just it just happens. >> Got it? Yeah, And if you think about how you Khun scale, can you scale linearly or exponentially? Enabling every developer or team to deploy their own code at their own pace with their own tools is something that allows you to scale exponentially. So things like mock servers that were talking about earlier. If I'm relying on somebody, that's my bottleneck. To spin this up with the normal workflow for the organization, that's a bottleneck. Spin up your own mock server. >> Find mock servers were great. Resource because remember the old days and mobile the emulators kind of had to have an emulator to kind of get going. Okay, that was, like five years, but similar model like, Hey, I don't need I can't build that out now. But I need to know what it's gonna look like so I can get this done. >> And that allows you to iterated at the fastest >> level at the local >> developer level. >> We've been covering the old days here in the Cube world. >> Throwback. Joyce, thanks so much for your time joining us on the cue program this morning. It a definite creed. Best of luck in your two sessions later on today. We look forward to seeing you next time. Great. Thank you. Nice to meet you for John Ferrier. I'm Lisa Martin. You're watching to keep live from Cisco Definite create twenty nineteen. Thanks for watching

(inspirational music) (music ends) >> Okay, so now that we've heard Scott talk about smart data fabrics, it's time to see this in action. Right now we're joined by Jess Jowdy, who's the manager of Healthcare Field Engineering at InterSystems. She's going to give a demo of how smart data fabrics actually work, and she's going to show how embedding a wide range of analytics capabilities, including data exploration business intelligence, natural language processing and machine learning directly within the fabric makes it faster and easier for organizations to gain new insights and power intelligence predictive and prescriptive services and applications. Now, according to InterSystems, smart data fabrics are applicable across many industries from financial services to supply chain to healthcare and more. Jess today is going to be speaking through the lens of a healthcare focused demo. Don't worry, Joe Lichtenberg will get into some of the other use cases that you're probably interested in hearing about. That will be in our third segment, but for now let's turn it over to Jess. Jess, good to see you. >> Hi, yeah, thank you so much for having me. And so for this demo, we're really going to be bucketing these features of a smart data fabric into four different segments. We're going to be dealing with connections, collections, refinements, and analysis. And so we'll see that throughout the demo as we go. So without further ado, let's just go ahead and jump into this demo, and you'll see my screen pop up here. I actually like to start at the end of the demo. So I like to begin by illustrating what an end user's going to see, and don't mind the screen 'cause I gave you a little sneak peek of what's about to happen. But essentially what I'm going to be doing is using Postman to simulate a call from an external application. So we talked about being in the healthcare industry. This could be, for instance, a mobile application that a patient is using to view an aggregated summary of information across that patient's continuity of care or some other kind of application. So we might be pulling information in this case from an electronic medical record. We might be grabbing clinical history from that. We might be grabbing clinical notes from a medical transcription software, or adverse reaction warnings from a clinical risk grouping application, and so much more. So I'm really going to be simulating a patient logging in on their phone and retrieving this information through this Postman call. So what I'm going to do is I'm just going to hit send, I've already preloaded everything here, and I'm going to be looking for information where the last name of this patient is Simmons, and their medical record number or their patient identifier in the system is 32345. And so as you can see, I have this single JSON payload that showed up here of, just, relevant clinical information for my patient whose last name is Simmons, all within a single response. So fantastic, right? Typically though, when we see responses that look like this there is an assumption that this service is interacting with a single backend system, and that single backend system is in charge of packaging that information up and returning it back to this caller. But in a smart data fabric architecture, we're able to expand the scope to handle information across different, in this case, clinical applications. So how did this actually happen? Let's peel back another layer and really take a look at what happened in the background. What you're looking at here is our mission control center for our smart data fabric. On the left we have our APIs that allow users to interact with particular services. On the right we have our connections to our different data silos. And in the middle here, we have our data fabric coordinator which is going to be in charge of this refinement and analysis, those key pieces of our smart data fabric. So let's look back and think about the example we just showed. I received an inbound request for information for a patient whose last name is Simmons. My end user is requesting to connect to that service, and that's happening here at my patient data retrieval API location. Users can define any number of different services and APIs depending on their use cases. And to that end, we do also support full life cycle API management within this platform. When you're dealing with APIs, I always like to make a little shout out on this, that you really want to make sure you have enough, like a granular enough security model to handle and limit which APIs and which services a consumer can interact with. In this IRIS platform, which we're talking about today we have a very granular role-based security model that allows you to handle that, but it's really important in a smart data fabric to consider who's accessing your data and in what context. >> Can I just interrupt you for a second, Jess? >> Yeah, please. >> So you were showing on the left hand side of the demo a couple of APIs. I presume that can be a very long list. I mean, what do you see as typical? >> I mean you could have hundreds of these APIs depending on what services an organization is serving up for their consumers. So yeah, we've seen hundreds of these services listed here. >> So my question is, obviously security is critical in the healthcare industry, and API securities are like, really hot topic these days. How do you deal with that? >> Yeah, and I think API security is interesting 'cause it can happen at so many layers. So, there's interactions with the API itself. So can I even see this API and leverage it? And then within an API call, you then have to deal with all right, which end points or what kind of interactions within that API am I allowed to do? What data am I getting back? And with healthcare data, the whole idea of consent to see certain pieces of data is critical. So, the way that we handle that is, like I said, same thing at different layers. There is access to a particular API, which can happen within the IRIS product, and also we see it happening with an API management layer, which has become a really hot topic with a lot of organizations. And then when it comes to data security, that really happens under the hood within your smart data fabric. So, that role-based access control becomes very important in assigning, you know, roles and permissions to certain pieces of information. Getting that granular becomes the cornerstone of the security. >> And that's been designed in, it's not a bolt on as they like to say. >> Absolutely. >> Okay, can we get into collect now? >> Of course, we're going to move on to the collection piece at this point in time, which involves pulling information from each of my different data silos to create an overall aggregated record. So commonly, each data source requires a different method for establishing connections and collecting this information. So for instance, interactions with an EMR may require leveraging a standard healthcare messaging format like Fire. Interactions with a homegrown enterprise data warehouse for instance, may use SQL. For a cloud-based solutions managed by a vendor, they may only allow you to use web service calls to pull data. So it's really important that your data fabric platform that you're using has the flexibility to connect to all of these different systems and applications. And I'm about to log out, so I'm going to (chuckles) keep my session going here. So therefore it's incredibly important that your data fabric has the flexibility to connect to all these different kinds of applications and data sources, and all these different kinds of formats and over all of these different kinds of protocols. So let's think back on our example here. I had four different applications that I was requesting information for to create that payload that we saw initially. Those are listed here under this operations section. So these are going out and connecting to downstream systems to pull information into my smart data fabric. What's great about the IRIS platform is, it has an embedded interoperability platform. So there's all of these native adapters that can support these common connections that we see for different kinds of applications. So using REST, or SOAP, or SQL, or FTP, regardless of that protocol, there's an adapter to help you work with that. And we also think of the types of formats that we typically see data coming in as in healthcare we have HL7, we have Fire, we have CCDs, across the industry, JSON is, you know, really hitting a market strong now, and XML payloads, flat files. We need to be able to handle all of these different kinds of formats over these different kinds of protocols. So to illustrate that, if I click through these when I select a particular connection on the right side panel, I'm going to see the different settings that are associated with that particular connection that allows me to collect information back into my smart data fabric. In this scenario, my connection to my chart script application in this example, communicates over a SOAP connection. When I'm grabbing information from my clinical risk grouping application I'm using a SQL based connection. When I'm connecting to my EMR, I'm leveraging a standard healthcare messaging format known as Fire, which is a REST based protocol. And then when I'm working with my health record management system, I'm leveraging a standard HTTP adapter. So you can see how we can be flexible when dealing with these different kinds of applications and systems. And then it becomes important to be able to validate that you've established those connections correctly, and be able to do it in a reliable and quick way. Because if you think about it, you could have hundreds of these different kinds of applications built out and you want to make sure that you're maintaining and understanding those connections. So I can actually go ahead and test one of these applications and put in, for instance my patient's last name and their MRN, and make sure that I'm actually getting data back from that system. So it's a nice little sanity check as we're building out that data fabric to ensure that we're able to establish these connections appropriately. So turnkey adapters are fantastic, as you can see we're leveraging them all here, but sometimes these connections are going to require going one step further and building something really specific for an application. So why don't we go one step further here and talk about doing something custom or doing something innovative. And so it's important for users to have the ability to develop and go beyond what's an out-of-the box or black box approach to be able to develop things that are specific to their data fabric, or specific to their particular connection. In this scenario, the IRIS data platform gives users access to the entire underlying code base. So you not only get an opportunity to view how we're establishing these connections or how we're building out these processes, but you have the opportunity to inject your own kind of processing, your own kinds of pipelines into this. So as an example, you can leverage any number of different programming languages right within this pipeline. And so I went ahead and I injected Python. So Python is a very up and coming language, right? We see more and more developers turning towards Python to do their development. So it's important that your data fabric supports those kinds of developers and users that have standardized on these kinds of programming languages. This particular script here, as you can see actually calls out to our turnkey adapters. So we see a combination of out-of-the-box code that is provided in this data fabric platform from IRIS, combined with organization specific or user specific customizations that are included in this Python method. So it's a nice little combination of how do we bring the developer experience in and mix it with out-of-the-box capabilities that we can provide in a smart data fabric. >> Wow. >> Yeah, I'll pause. (laughs) >> It's a lot here. You know, actually- >> I can pause. >> If I could, if we just want to sort of play that back. So we went to the connect and the collect phase. >> Yes, we're going into refine. So it's a good place to stop. >> So before we get there, so we heard a lot about fine grain security, which is crucial. We heard a lot about different data types, multiple formats. You've got, you know, the ability to bring in different dev tools. We heard about Fire, which of course big in healthcare. And that's the standard, and then SQL for traditional kind of structured data, and then web services like HTTP you mentioned. And so you have a rich collection of capabilities within this single platform. >> Absolutely. And I think that's really important when you're dealing with a smart data fabric because what you're effectively doing is you're consolidating all of your processing, all of your collection, into a single platform. So that platform needs to be able to handle any number of different kinds of scenarios and technical challenges. So you've got to pack that platform with as many of these features as you can to consolidate that processing. >> All right, so now we're going into refinement. >> We're going into refinement. Exciting. (chuckles) So how do we actually do refinement? Where does refinement happen? And how does this whole thing end up being performant? Well the key to all of that is this SDF coordinator, or stands for Smart Data Fabric coordinator. And what this particular process is doing is essentially orchestrating all of these calls to all of these different downstream systems. It's aggregating, it's collecting that information, it's aggregating it, and it's refining it into that single payload that we saw get returned to the user. So really this coordinator is the main event when it comes to our data fabric. And in the IRIS platform we actually allow users to build these coordinators using web-based tool sets to make it intuitive. So we can take a sneak peek at what that looks like. And as you can see, it follows a flow chart like structure. So there's a start, there is an end, and then there are these different arrows that point to different activities throughout the business process. And so there's all these different actions that are being taken within our coordinator. You can see an action for each of the calls to each of our different data sources to go retrieve information. And then we also have the sync call at the end that is in charge of essentially making sure that all of those responses come back before we package them together and send them out. So this becomes really crucial when we're creating that data fabric. And you know, this is a very simple data fabric example where we're just grabbing data and we're consolidating it together. But you can have really complex orchestrators and coordinators that do any number of different things. So for instance, I could inject SQL logic into this or SQL code, I can have conditional logic, I can do looping, I can do error trapping and handling. So we're talking about a whole number of different features that can be included in this coordinator. So like I said, we have a really very simple process here that's just calling out, grabbing all those different data elements from all those different data sources and consolidating it. We'll look back at this coordinator in a second when we introduce, or we make this data fabric a bit smarter, and we start introducing that analytics piece to it. So this is in charge of the refinement. And so at this point in time we've looked at connections, collections, and refinements. And just to summarize what we've seen 'cause I always like to go back and take a look at everything that we've seen. We have our initial API connection, we have our connections to our individual data sources and we have our coordinators there in the middle that are in charge of collecting the data and refining it into a single payload. As you can imagine, there's a lot going on behind the scenes of a smart data fabric, right? There's all these different processes that are interacting. So it's really important that your smart data fabric platform has really good traceability, really good logging, 'cause you need to be able to know, you know, if there was an issue, where did that issue happen in which connected process, and how did it affect the other processes that are related to it? In IRIS, we have this concept called a visual trace. And what our clients use this for is basically to be able to step through the entire history of a request from when it initially came into the smart data fabric, to when data was sent back out from that smart data fabric. So I didn't record the time, but I bet if you recorded the time it was this time that we sent that request in and you can see my patient's name and their medical record number here, and you can see that that instigated four different calls to four different systems, and they're represented by these arrows going out. So we sent something to chart script, to our health record management system, to our clinical risk grouping application, into my EMR through their Fire server. So every request, every outbound application gets a request and we pull back all of those individual pieces of information from all of those different systems, and we bundle them together. And from my Fire lovers, here's our Fire bundle that we got back from our Fire server. So this is a really good way of being able to validate that I am appropriately grabbing the data from all these different applications and then ultimately consolidating it into one payload. Now we change this into a JSON format before we deliver it, but this is those data elements brought together. And this screen would also be used for being able to see things like error trapping, or errors that were thrown, alerts, warnings, developers might put log statements in just to validate that certain pieces of code are executing. So this really becomes the one stop shop for understanding what's happening behind the scenes with your data fabric. >> Sure, who did what when where, what did the machine do what went wrong, and where did that go wrong? Right at your fingertips. >> Right. And I'm a visual person so a bunch of log files to me is not the most helpful. While being able to see this happened at this time in this location, gives me that understanding I need to actually troubleshoot a problem. >> This business orchestration piece, can you say a little bit more about that? How people are using it? What's the business impact of the business orchestration? >> The business orchestration, especially in the smart data fabric, is really that crucial part of being able to create a smart data fabric. So think of your business orchestrator as doing the heavy lifting of any kind of processing that involves data, right? It's bringing data in, it's analyzing that information it's transforming that data, in a format that your consumer's not going to understand. It's doing any additional injection of custom logic. So really your coordinator or that orchestrator that sits in the middle is the brains behind your smart data fabric. >> And this is available today? It all works? >> It's all available today. Yeah, it all works. And we have a number of clients that are using this technology to support these kinds of use cases. >> Awesome demo. Anything else you want to show us? >> Well, we can keep going. I have a lot to say, but really this is our data fabric. The core competency of IRIS is making it smart, right? So I won't spend too much time on this, but essentially if we go back to our coordinator here, we can see here's that original, that pipeline that we saw where we're pulling data from all these different systems and we're collecting it and we're sending it out. But then we see two more at the end here, which involves getting a readmission prediction and then returning a prediction. So we can not only deliver data back as part of a smart data fabric, but we can also deliver insights back to users and consumers based on data that we've aggregated as part of a smart data fabric. So in this scenario, we're actually taking all that data that we just looked at, and we're running it through a machine learning model that exists within the smart data fabric pipeline, and producing a readmission score to determine if this particular patient is at risk for readmission within the next 30 days. Which is a typical problem that we see in the healthcare space. So what's really exciting about what we're doing in the IRIS world, is we're bringing analytics close to the data with integrated ML. So in this scenario we're actually creating the model, training the model, and then executing the model directly within the IRIS platform. So there's no shuffling of data, there's no external connections to make this happen. And it doesn't really require having a PhD in data science to understand how to do that. It leverages all really basic SQL-like syntax to be able to construct and execute these predictions. So, it's going one step further than the traditional data fabric example to introduce this ability to define actionable insights to our users based on the data that we've brought together. >> Well that readmission probability is huge, right? Because it directly affects the cost for the provider and the patient, you know. So if you can anticipate the probability of readmission and either do things at that moment, or, you know, as an outpatient perhaps, to minimize the probability then that's huge. That drops right to the bottom line. >> Absolutely. And that really brings us from that data fabric to that smart data fabric at the end of the day, which is what makes this so exciting. >> Awesome demo. >> Thank you! >> Jess, are you cool if people want to get in touch with you? Can they do that? >> Oh yes, absolutely. So you can find me on LinkedIn, Jessica Jowdy, and we'd love to hear from you. I always love talking about this topic so we'd be happy to engage on that. >> Great stuff. Thank you Jessica, appreciate it. >> Thank you so much. >> Okay, don't go away because in the next segment, we're going to dig into the use cases where data fabric is driving business value. Stay right there. (inspirational music) (music fades)

>> Okay, so now that we've heard Scott talk about smart data fabrics, it's time to see this in action. Right now we're joined by Jess Jowdy, who's the manager of Healthcare Field Engineering at InterSystems. She's going to give a demo of how smart data fabrics actually work, and she's going to show how embedding a wide range of analytics capabilities including data exploration, business intelligence natural language processing, and machine learning directly within the fabric, makes it faster and easier for organizations to gain new insights and power intelligence, predictive and prescriptive services and applications. Now, according to InterSystems, smart data fabrics are applicable across many industries from financial services to supply chain to healthcare and more. Jess today is going to be speaking through the lens of a healthcare focused demo. Don't worry, Joe Lichtenberg will get into some of the other use cases that you're probably interested in hearing about. That will be in our third segment, but for now let's turn it over to Jess. Jess, good to see you. >> Hi. Yeah, thank you so much for having me. And so for this demo we're really going to be bucketing these features of a smart data fabric into four different segments. We're going to be dealing with connections, collections, refinements and analysis. And so we'll see that throughout the demo as we go. So without further ado, let's just go ahead and jump into this demo and you'll see my screen pop up here. I actually like to start at the end of the demo. So I like to begin by illustrating what an end user's going to see and don't mind the screen 'cause I gave you a little sneak peek of what's about to happen. But essentially what I'm going to be doing is using Postman to simulate a call from an external application. So we talked about being in the healthcare industry. This could be for instance, a mobile application that a patient is using to view an aggregated summary of information across that patient's continuity of care or some other kind of application. So we might be pulling information in this case from an electronic medical record. We might be grabbing clinical history from that. We might be grabbing clinical notes from a medical transcription software or adverse reaction warnings from a clinical risk grouping application and so much more. So I'm really going to be assimilating a patient logging on in on their phone and retrieving this information through this Postman call. So what I'm going to do is I'm just going to hit send, I've already preloaded everything here and I'm going to be looking for information where the last name of this patient is Simmons and their medical record number their patient identifier in the system is 32345. And so as you can see I have this single JSON payload that showed up here of just relevant clinical information for my patient whose last name is Simmons all within a single response. So fantastic, right? Typically though when we see responses that look like this there is an assumption that this service is interacting with a single backend system and that single backend system is in charge of packaging that information up and returning it back to this caller. But in a smart data fabric architecture we're able to expand the scope to handle information across different, in this case, clinical applications. So how did this actually happen? Let's peel back another layer and really take a look at what happened in the background. What you're looking at here is our mission control center for our smart data fabric. On the left we have our APIs that allow users to interact with particular services. On the right we have our connections to our different data silos. And in the middle here we have our data fabric coordinator which is going to be in charge of this refinement and analysis those key pieces of our smart data fabric. So let's look back and think about the example we just showed. I received an inbound request for information for a patient whose last name is Simmons. My end user is requesting to connect to that service and that's happening here at my patient data retrieval API location. Users can define any number of different services and APIs depending on their use cases. And to that end we do also support full lifecycle API management within this platform. When you're dealing with APIs I always like to make a little shout out on this that you really want to make sure you have enough like a granular enough security model to handle and limit which APIs and which services a consumer can interact with. In this IRIS platform, which we're talking about today we have a very granular role-based security model that allows you to handle that, but it's really important in a smart data fabric to consider who's accessing your data and in what contact. >> Can I just interrupt you for a second? >> Yeah, please. >> So you were showing on the left hand side of the demo a couple of APIs. I presume that can be a very long list. I mean, what do you see as typical? >> I mean you can have hundreds of these APIs depending on what services an organization is serving up for their consumers. So yeah, we've seen hundreds of these services listed here. >> So my question is, obviously security is critical in the healthcare industry and API securities are really hot topic these days. How do you deal with that? >> Yeah, and I think API security is interesting 'cause it can happen at so many layers. So there's interactions with the API itself. So can I even see this API and leverage it? And then within an API call, you then have to deal with all right, which end points or what kind of interactions within that API am I allowed to do? What data am I getting back? And with healthcare data, the whole idea of consent to see certain pieces of data is critical. So the way that we handle that is, like I said, same thing at different layers. There is access to a particular API, which can happen within the IRIS product and also we see it happening with an API management layer, which has become a really hot topic with a lot of organizations. And then when it comes to data security, that really happens under the hood within your smart data fabric. So that role-based access control becomes very important in assigning, you know, roles and permissions to certain pieces of information. Getting that granular becomes the cornerstone of security. >> And that's been designed in, >> Absolutely, yes. it's not a bolt-on as they like to say. Okay, can we get into collect now? >> Of course, we're going to move on to the collection piece at this point in time, which involves pulling information from each of my different data silos to create an overall aggregated record. So commonly each data source requires a different method for establishing connections and collecting this information. So for instance, interactions with an EMR may require leveraging a standard healthcare messaging format like FIRE, interactions with a homegrown enterprise data warehouse for instance may use SQL for a cloud-based solutions managed by a vendor. They may only allow you to use web service calls to pull data. So it's really important that your data fabric platform that you're using has the flexibility to connect to all of these different systems and and applications. And I'm about to log out so I'm going to keep my session going here. So therefore it's incredibly important that your data fabric has the flexibility to connect to all these different kinds of applications and data sources and all these different kinds of formats and over all of these different kinds of protocols. So let's think back on our example here. I had four different applications that I was requesting information for to create that payload that we saw initially. Those are listed here under this operations section. So these are going out and connecting to downstream systems to pull information into my smart data fabric. What's great about the IRIS platform is it has an embedded interoperability platform. So there's all of these native adapters that can support these common connections that we see for different kinds of applications. So using REST or SOAP or SQL or FTP regardless of that protocol there's an adapter to help you work with that. And we also think of the types of formats that we typically see data coming in as, in healthcare we have H7, we have FIRE we have CCDs across the industry. JSON is, you know, really hitting a market strong now and XML, payloads, flat files. We need to be able to handle all of these different kinds of formats over these different kinds of protocols. So to illustrate that, if I click through these when I select a particular connection on the right side panel I'm going to see the different settings that are associated with that particular connection that allows me to collect information back into my smart data fabric. In this scenario, my connection to my chart script application in this example communicates over a SOAP connection. When I'm grabbing information from my clinical risk grouping application I'm using a SQL based connection. When I'm connecting to my EMR I'm leveraging a standard healthcare messaging format known as FIRE, which is a rest based protocol. And then when I'm working with my health record management system I'm leveraging a standard HTTP adapter. So you can see how we can be flexible when dealing with these different kinds of applications and systems. And then it becomes important to be able to validate that you've established those connections correctly and be able to do it in a reliable and quick way. Because if you think about it, you could have hundreds of these different kinds of applications built out and you want to make sure that you're maintaining and understanding those connections. So I can actually go ahead and test one of these applications and put in, for instance my patient's last name and their MRN and make sure that I'm actually getting data back from that system. So it's a nice little sanity check as we're building out that data fabric to ensure that we're able to establish these connections appropriately. So turnkey adapters are fantastic, as you can see we're leveraging them all here, but sometimes these connections are going to require going one step further and building something really specific for an application. So let's, why don't we go one step further here and talk about doing something custom or doing something innovative. And so it's important for users to have the ability to develop and go beyond what's an out of the box or black box approach to be able to develop things that are specific to their data fabric or specific to their particular connection. In this scenario, the IRIS data platform gives users access to the entire underlying code base. So you cannot, you not only get an opportunity to view how we're establishing these connections or how we're building out these processes but you have the opportunity to inject your own kind of processing your own kinds of pipelines into this. So as an example, you can leverage any number of different programming languages right within this pipeline. And so I went ahead and I injected Python. So Python is a very up and coming language, right? We see more and more developers turning towards Python to do their development. So it's important that your data fabric supports those kinds of developers and users that have standardized on these kinds of programming languages. This particular script here, as you can see actually calls out to our turnkey adapters. So we see a combination of out of the box code that is provided in this data fabric platform from IRIS combined with organization specific or user specific customizations that are included in this Python method. So it's a nice little combination of how do we bring the developer experience in and mix it with out of the box capabilities that we can provide in a smart data fabric. >> Wow. >> Yeah, I'll pause. >> It's a lot here. You know, actually, if I could >> I can pause. >> If I just want to sort of play that back. So we went through the connect and the collect phase. >> And the collect, yes, we're going into refine. So it's a good place to stop. >> Yeah, so before we get there, so we heard a lot about fine grain security, which is crucial. We heard a lot about different data types, multiple formats. You've got, you know the ability to bring in different dev tools. We heard about FIRE, which of course big in healthcare. >> Absolutely. >> And that's the standard and then SQL for traditional kind of structured data and then web services like HTTP you mentioned. And so you have a rich collection of capabilities within this single platform. >> Absolutely, and I think that's really important when you're dealing with a smart data fabric because what you're effectively doing is you're consolidating all of your processing, all of your collection into a single platform. So that platform needs to be able to handle any number of different kinds of scenarios and technical challenges. So you've got to pack that platform with as many of these features as you can to consolidate that processing. >> All right, so now we're going into refine. >> We're going into refinement, exciting. So how do we actually do refinement? Where does refinement happen and how does this whole thing end up being performant? Well the key to all of that is this SDF coordinator or stands for smart data fabric coordinator. And what this particular process is doing is essentially orchestrating all of these calls to all of these different downstream systems. It's aggregating, it's collecting that information it's aggregating it and it's refining it into that single payload that we saw get returned to the user. So really this coordinator is the main event when it comes to our data fabric. And in the IRIS platform we actually allow users to build these coordinators using web-based tool sets to make it intuitive. So we can take a sneak peek at what that looks like and as you can see it follows a flow chart like structure. So there's a start, there is an end and then there are these different arrows that point to different activities throughout the business process. And so there's all these different actions that are being taken within our coordinator. You can see an action for each of the calls to each of our different data sources to go retrieve information. And then we also have the sync call at the end that is in charge of essentially making sure that all of those responses come back before we package them together and send them out. So this becomes really crucial when we're creating that data fabric. And you know, this is a very simple data fabric example where we're just grabbing data and we're consolidating it together. But you can have really complex orchestrators and coordinators that do any number of different things. So for instance, I could inject SQL Logic into this or SQL code, I can have conditional logic, I can do looping, I can do error trapping and handling. So we're talking about a whole number of different features that can be included in this coordinator. So like I said, we have a really very simple process here that's just calling out, grabbing all those different data elements from all those different data sources and consolidating it. We'll look back at this coordinator in a second when we introduce or we make this data fabric a bit smarter and we start introducing that analytics piece to it. So this is in charge of the refinement. And so at this point in time we've looked at connections, collections, and refinements. And just to summarize what we've seen 'cause I always like to go back and take a look at everything that we've seen. We have our initial API connection we have our connections to our individual data sources and we have our coordinators there in the middle that are in charge of collecting the data and refining it into a single payload. As you can imagine, there's a lot going on behind the scenes of a smart data fabric, right? There's all these different processes that are interacting. So it's really important that your smart data fabric platform has really good traceability, really good logging 'cause you need to be able to know, you know, if there was an issue, where did that issue happen, in which connected process and how did it affect the other processes that are related to it. In IRIS, we have this concept called a visual trace. And what our clients use this for is basically to be able to step through the entire history of a request from when it initially came into the smart data fabric to when data was sent back out from that smart data fabric. So I didn't record the time but I bet if you recorded the time it was this time that we sent that request in. And you can see my patient's name and their medical record number here and you can see that that instigated four different calls to four different systems and they're represented by these arrows going out. So we sent something to chart script to our health record management system, to our clinical risk grouping application into my EMR through their FIRE server. So every request, every outbound application gets a request and we pull back all of those individual pieces of information from all of those different systems and we bundle them together. And for my FIRE lovers, here's our FIRE bundle that we got back from our FIRE server. So this is a really good way of being able to validate that I am appropriately grabbing the data from all these different applications and then ultimately consolidating it into one payload. Now we change this into a JSON format before we deliver it, but this is those data elements brought together. And this screen would also be used for being able to see things like error trapping or errors that were thrown alerts, warnings, developers might put log statements in just to validate that certain pieces of code are executing. So this really becomes the one stop shop for understanding what's happening behind the scenes with your data fabric. >> Etcher, who did what, when, where what did the machine do? What went wrong and where did that go wrong? >> Exactly. >> Right in your fingertips. >> Right, and I'm a visual person so a bunch of log files to me is not the most helpful. Well, being able to see this happened at this time in this location gives me that understanding I need to actually troubleshoot a problem. >> This business orchestration piece, can you say a little bit more about that? How people are using it? What's the business impact of the business orchestration? >> The business orchestration, especially in the smart data fabric is really that crucial part of being able to create a smart data fabric. So think of your business orchestrator as doing the heavy lifting of any kind of processing that involves data, right? It's bringing data in, it's analyzing that information, it's transforming that data, in a format that your consumer's not going to understand it's doing any additional injection of custom logic. So really your coordinator or that orchestrator that sits in the middle is the brains behind your smart data fabric. >> And this is available today? This all works? >> It's all available today. Yeah, it all works. And we have a number of clients that are using this technology to support these kinds of use cases. >> Awesome demo. Anything else you want to show us? >> Well we can keep going. 'Cause right now, I mean we can, oh, we're at 18 minutes. God help us. You can cut some of this. (laughs) I have a lot to say, but really this is our data fabric. The core competency of IRIS is making it smart, right? So I won't spend too much time on this but essentially if we go back to our coordinator here we can see here's that original that pipeline that we saw where we're pulling data from all these different systems and we're collecting it and we're sending it out. But then we see two more at the end here which involves getting a readmission prediction and then returning a prediction. So we can not only deliver data back as part of a smart data fabric but we can also deliver insights back to users and consumers based on data that we've aggregated as part of a smart data fabric. So in this scenario, we're actually taking all that data that we just looked at and we're running it through a machine learning model that exists within the smart data fabric pipeline and producing a readmission score to determine if this particular patient is at risk for readmission within the next 30 days. Which is a typical problem that we see in the healthcare space. So what's really exciting about what we're doing in the IRIS world is we're bringing analytics close to the data with integrated ML. So in this scenario we're actually creating the model, training the model, and then executing the model directly within the IRIS platform. So there's no shuffling of data, there's no external connections to make this happen. And it doesn't really require having a PhD in data science to understand how to do that. It leverages all really basic SQL like syntax to be able to construct and execute these predictions. So it's going one step further than the traditional data fabric example to introduce this ability to define actionable insights to our users based on the data that we've brought together. >> Well that readmission probability is huge. >> Yes. >> Right, because it directly affects the cost of for the provider and the patient, you know. So if you can anticipate the probability of readmission and either do things at that moment or you know, as an outpatient perhaps to minimize the probability then that's huge. That drops right to the bottom line. >> Absolutely, absolutely. And that really brings us from that data fabric to that smart data fabric at the end of the day which is what makes this so exciting. >> Awesome demo. >> Thank you. >> Fantastic people, are you cool? If people want to get in touch with you? >> Oh yes, absolutely. So you can find me on LinkedIn, Jessica Jowdy and we'd love to hear from you. I always love talking about this topic, so would be happy to engage on that. >> Great stuff, thank you Jess, appreciate it. >> Thank you so much. >> Okay, don't go away because in the next segment we're going to dig into the use cases where data fabric is driving business value. Stay right there.

(upbeat music) >> Announcer: From our studios, in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. >> Hey, welcome back already, Jeff Frick here with theCUBE. We're in our Palo Alto studio today for a CUBE Conversation that's a little bit of a deeper dive into the Cisco CloudCenter, we've had an ongoing conversation and there's a new component today, we're going to do a deep dive, so we're excited to welcome back to the studio CUBE alumni Ali G, technical leader, software engineering group from Cisco, Ali, great to see you again. >> Thank you so much, happy to be here. >> Absolutely, and joining us from New Jersey via the phone is Michael Chenetz, he's a technical marketing engineer from Cisco, Michael, great to see you. >> Hey, great to see you guys. >> And I hope you'll go get a cheese steak when we're finished and figure out how you can send it to me, I don't know if that's possible. But anyway, welcome. So let's jump into it, so Cisco CloudCenter, we've been talking about it for a while, but today we wanted to dig into a very specific feature, and it goes technically by AO, but that stands for the Action Orchestrator. Ali, what's Action Orchestrator all about? >> Well, action orchestration is a component inside our CloudCenter Suite that brings together cross-domain orchestration. And it's extremely useful because not only is it valuable for DevOps engineers to orchestrate and maintain and automate their infrastructure, but it's also useful for application developers to define workflow and orchestration in their products as well. So, this tool is heavily used throughout the stack, inside the cloud, at the application level, all the way down to the intro level as well, and it's made it extremely easy for DevOps engineers to get their hands on defining workflows, and conditions and logics where they can create, maintain, all the appropriate infrastructure that they need. Works very well hand to hand with the current technology out there like Terraform or Ansible, and it's part of our CloudCenter Suite, so. >> And is it more on the config side or is it more on kind of the operational workflow side? >> Correct, so it could be used for both, right, it's so flexible in a matter of this abstraction of having the orchestration engine outside, enables both developers and DevOps engineers to illustrate and create their workflows. Rather, it's again based on infrastructure or even networking layers, are all the way up the stack to the application where if your product requires an orchestration engine in the back end, to process work, this component definitely plays a big role, right, so. >> Okay. Michael, throw it over to you. >> Yeah, so I think everything that Ali is saying is absolutely correct, the nice part about it is it's a product that can really do whatever you imagine, so I mean we've seen people use it for business process, for automation of network, server, cloud, whatever you can think of, it's extensible but we're going to talk about that in a little bit, but really the nice part about it is you create the workflows and you design the way that you want to go. And what I have here, if you can show the next video, is just a little clip of what it would look like to go through a workflow. So let's cue that up and we'll take a walk through it. >> Jeff: Let's go to the video number one, guys. >> Michael: All right, so... Yeah, so if you look here, what we're seeing is, we're seeing a preview of what Amazon looked like beforehand, looking at VPCs and subnets, and now what we're doing is going through a workflow that is going to show afterwards that those actual VPCs and subnets were created by using a flow. So what we're going to do is just pick one flow here, which is called create infra, and this is just an example, and what you see on the left-hand side is something called actions, so these are all the atomic actions that are available. But these are just out of the box, we're adding stuff all the time, and these actions could be dragged over to the right and create workflows. And the nice thing about it is if it's not there, you can create them in minutes and we're going to show you that in a little bit, too. So, right now what I'm going to show you is the fact that if you click on each one of these actions, there's actually some kind of information that you'll see on the right-hand side, and this information is how you configure that particular action, so this particular one's going to create a VPC, and you can see the VPC name, you can see the VPC subnet, and whatever other parameters are needed for that particular action. So now I'll have to do, you pretty much select the target, and this one already had a target selected, which is Amazon, or AWS, and this second action here, if you look down, actually has a parameter too, or a couple parameters, and one of those parameters, you can see the first one is just the name, the second one, though, is actually used in a variable from the previous step. So really really easy to map stuff from different workflow elements, and it allows you to quickly kind of glue things together to make things work, so this is just an example, again, very simple example, that this is going to create infrastructure on Amazon, and you can think about using this as part of the process, like when you're trying to bring up a cloud environment, maybe you run this first. Maybe you run this to say, "Hey, I need some infrastructure "for that cloud environment," and maybe you even want to execute bringing up certain VMs or containers, you could do that afterwards. But this was just a really really quick showcase of a simple thing you can do with very few steps, that you could then run and it will actually, we're going to run, hit validate here, just validates the workflow, but once we click run here, it's actually going to create all of that stuff within Amazon, so in this step you're going to see the run, you can see that both steps work, because they're green. If they didn't work, they'd be red, and we're going to show that in one second. But, when you click on a step it actually shows you the input and output of each one of those steps, so it's really really cool in that all the information that you could possible think of that you'll need to troubleshoot, to look at these things, is available in the workflow by just clicking on each one of these steps and seeing what that input and output, so if you could imagine, if you had an error there, you could quickly figure out what that is, it would tell you the error, it would tell you what's going on, or, if you needed information from a step before, you could run it, get the information from the step before, and then figure out what values you need for the next step. So really really cool in that you could look at this workflow, you get all the information you need, and it allows you to create these workflows and kind of glue 'em together, really really quick. And now what I'm going to show you, I believe, is in the next part here, I'm just going to illustrate that if you go over to the runs that we have here, it'll actually keep a list of all of the different runs we did, and you can see one is in red. Well, that one in red means that a step didn't work. Well let's click on that step and figure out "Hey, why didn't this step work?" Well this step didn't work because of an error that we got, and if we scroll down to the bottom over here, what we're going to see is the actual error that had occurred within this step. So now we know exactly what the problem was, and we can fix it within the next step, so in this particular one, we illustrated right there that there was some problem with, I think a VPC, or the way that I phrased that VPC, or that subnet, I'm sorry, and it caused the problem. But I fixed it within the next step, and now you can see that in these particular two screens that the VPC and the subnet was created automatically within that workflow. >> Pretty cool, so what would they have done to accomplish that in the past? >> So to accomplish that in the past, and this is the real thing that we see, we see that people have all these tools all over the place, those tools might be things that are orchestration engines, other products that might be things that you run from the command line. Which work great together, but what you find is that, there's no central orchestration, and what we want to provide is that central orchestration that can run those other tools, and also schedule them together. So if you use other tools besides AO, that's fine. We're happy to bring them in, and you could use the variables, you could use everything that you still would use, but now you have all the integration, you have all the variables, you have all the workflow, and not only just from AO, but from Workload Manager too, so if you bring up a VM and bring up a container, you get that information. So there's just a lot of tooling inside that allows you to really take advantage of everything you might already even have. >> Correct, I mean that was a good demo, and one of the things I'd like to point out here is that, compared to some of the competitors that are out there with this orchestration engine, I don't want to name anyone particular, but if you look at it, the schema that Michael just showed us in that demo is JSON-based, versus others out there are some still in XML. The other very beneficial to this is that since this is a component of our CloudCenter Suite, it also gets installed on-prem, and what that means is footprint is extremely important when it comes to on-prem especially. And with the technology and the cloud-native solutions, that the team has done inside Cisco, our footprint is very small, due to the technology choices that we use in writing our services in Go, and et cetera, versus outside competitors are doing it in Java, which have a much more larger footprint on the infrastructure, that clients and customers get to install, so there are a lot of features with this orchestration engine that comes when we're trying to compare them with the market and the competitors of that are out there. Conditional logicking, what Michael just showed us inside the workflows, right, it makes it super simple for someone who has not had any experience coding, to put together the workflows and introduce conditions, either for loops or if else statements or conditional blocks, whereas in the competitors, you have to know a certain amount of programming skills in order for you to do those conditioning, so, I feel that that's a great advantage that we have here, so. >> And so does a lot of things come packaged out of the box? Standard processing, standard workflows, standard processes? >> Yep. >> And then what do they code it in, then, if it is a custom workflow that you don't have, how do they go in and manipulate the tool? >> Good question, because like I mentioned, competitors, you would have to know a certain language in order for you to code those logical flows that you want inside your orchestration, right? Inside AO, it's all driven by the DSO, which is all JSON-based, right, and the DSO is so powerful that you can introduce if and else conditions, you don't have to know a language per se, it's just you define your logic, right, and the tool actually allows you to provide those flows, those if conditions, the loops that are required, and also defaulting onto fallbacks or et cetera. >> Think Michael, you were going to show us a little bit more on that, and kind of set up some of these actions. >> Yeah, I think that's absolutely key, is that what we're talking about is extensibility here, so the extensibility is one thing that we kind of tout, because you don't need to be a programmer, but we live in an API world, so we need a way to consume these APIs. How do we do that in companies and businesses that think developer is expensive, and it's very hard to get into. So we're trying to take that out of that and say "Hey, we have this engine." So let's take a look at some of that extensibility on the next video that I have here. >> Jeff: Kay, pulling that up. >> Michael: So what you're seeing here is Postman. So this is a regular tool that a lot of people use, and what I'm showing is just a call, which is in Postman. And this particular call just gets a Smartsheet, so this gets a Smartsheet from Smartsheets, and it just lists what Smartsheets are available. And in AO, I want to be able to create this, and if we look at the timer, I'm doing this in less than five minutes. So I have no calls for Smartsheets, but I want to create a call, so what I did is I created a target for Smartsheets, that's an http target. And what that means is that I can connect to Smartsheets, and if you look at the bottom I list the API address, and I list the default path, so you don't have to enter that path a million times, so we know that API/2.0 is the path that we're always going to use. On top of that, there's always some other kind of element to that path that we're going to need in each particular action that we want to call. So what I'm going to do here is showcase what I did. So, in this first step, what I've done is I actually did a generic http request, so no programming needed, all I had to do is use a URL. People have used the World Wide Web, they know how to use URLs. In this one, the call is /sheets. It doesn't take a brain surgeon to figure this out. So, really I did /sheets is what I'm calling, and I'm using the target, and then the next step what I'm doing is I'm setting up a variable that's going to be my output variable, so what am I going to call this, maybe I'll call it Sheets, and really all I'm doing is just setting this up and saying that we are going to call this Sheets, going out of it, and that's about it. So what I've done within a couple minutes is created a new action that's going to be shown on the left-hand side. So now you can think of a reusable element, and what I'm showcasing here is I'm actually going to turn it off and turn it back on just to showcase, but there's something called atomic actions. So I'm just validating that this is running, I'm going to take a look at the atomic action, I'm going to give it a category, so I'm going to put this under the Smartsheet category, so if you can imagine, I had a lot of these Smartsheet actions, I could just put 'em all into one category where I'll find 'em on the left-hand side. But, I'm just going to validate that the atomic action is good, and now what I'm going to show you is that when I call up a new workflow, I could just drag that right from the left-hand side, and it'll be under Smartsheets, it'll be under get those lists, list Smartsheets, and what it's going to ask for now is a token, because you need a token in order to authenticate with Smartsheet, that's a Smartsheet requirement, so what I'm going to do is just go over to Postman, and grab that token real quick, and then come back over to this page and enter that token in. So, the first thing I'm going to do is create an input variable, and that input variable is going to ask for a token, so what that does is it, when I run this, in this particular workflow, I can ask for an input variable, and that means every time it runs it's going to pop up with that variable. Right now what you're seeing is I'm associating that variable that I created with that token parameter, and this is a secure string, so you can never see what that string is. It's hidden, it's made so that it's not ever seen. And so now if I run the run, you'll see it asks for a token. Now is actually when I'm going to go over to Postman, I'm going to grab that token, so you'll see I'm going into Postman, and Postman, again, is just what we use to test these calls, a lot of people use it, it's very industry-standard, and I'm just grabbing the token from here. It's blurred out so that the public can't see it, but I grabbed it, and now I'll go back out into here, and I hit run, and you'll see that I created that action, I brought the action into a workflow, I ran it, it's running, and now it's giving me that exact same output that I would've got in Postman, but now it's a reusable element. So this just illustrates the extensibility that's available within our product. Again, only took a couple of minutes, and I have an action that I might have needed that wasn't available in this tool, but it was created, and it works out of the box now. >> Very slick, and so that was with Smartsheets, how many connectors do you guys already have preconstructed? >> There are so many, I mean I don't want to list a lot of different vendors, but you can imagine every DevOps tool is in there, there are connections to Amazon, to Google, to Kubernetes, to, internally through ACI, through Meraki, through a lot of the Cisco ecosystem. So really, there's just a lot available, and it's growing, it's growing tremendously and we're building communities and we just want people to try it, use it, I think they'll really like it once they see what it can do. >> Yeah, and I'm just curious, Ali, is this something then that people are going to be working on all the time, or are these pretty much, you set your configs and go back to work, you set these relationships and go back to work, or is this, this is not your working screen. >> This is, I mean how cool was that, right, creating those atomic actions and being able to templatize those and building those building blocks like Lego, right, that in the future you can just build more and more out of, and just add to the complexity without it being complex at all, right? But going back to your question is, a lot of these toolings that are build with AO, one of the other advantages that we see that unfortunately some of the competitors don't have outside, is that you have the ability of four different type of events that inside AO is supported. So you, as DevOps engineers, they tie them up to scheduling, they tie them up to events coming in from a message queue, so these workflows that are created get triggered by these events, which makes it possible for them to execute at a certain time, or for a certain event that gets triggered, right, so again, reusable atomic workflows and actions that Michael just demonstrated, along with having both engineers and, application developers and DevOps, and I kind of stress it out, because of how flexible this is. For them to define it one time, and then have it reusable whenever they want. >> I'm just curious, what's the biggest surprise when you show this to people in the field? What do they get most excited about? >> They love it, they immediately say, "How can we start using it the next day?" And we also have, CloudCenter Suite has a SaaS offering where it's made it very easy for us to get them a trial access so that they can come in, get their foot wet and try it out. And once they start doing these calls and building these workflows and as Michael demonstrated, these actions where they perform API calls at the very least, they just get hooked to it, right, and then start using it from thereon. >> Michael, what about you, what's your favorite response from clients when you demo this, what's the one, two things that really grabs 'em, gets their attention, gets a big smile on their face? >> Yeah, well first and foremost you see people's minds spinning on what use cases have been bothering them that they haven't been able to fix, because maybe they're not programmers, or maybe they are, but it's just, they thought it would be too complex and too much work. So, I think it's just, it's so open-ended but you just see the interest in people's faces, it's like the first time, I have a three year old, the first time I gave him Legos and he's like, "I can build stuff, I can do stuff myself?" I mean it's just like that, I mean that's the amazing part of it is that it's so extensible, and to build onto what Ali was saying, there's so many ways to trigger it, too. So this can work standalone and work by itself, or it can be triggered by an API call, it can be scheduled, it could be called from Workload Manager, it can be triggered from a RabbitMQ, it could be triggered from Kafka. There's so many different things that you can do to trigger these workflows, that it just makes it so that it can integrate with other products, and you can integrate other products, so it really becomes that glue that kind of ties everything together, I mean we really really think about it as building blocks or Legos, or something like that. It just is really extensible, really easy to use, and we think it's a real game-changer. >> Great, all right, Ali, so last word, where do people go to get more information if they can't see that cool demo on that itty-bitty screen on their phone? >> So, we definitely recommend them to go to CloudCenter Suite, if you easily Google it on Cisco website or on Google itself, you'll see it apart from first or second links, but definitely check out CloudCenter Suite, Action Orchestrator is where you would like to visit and learn more about this tool and this component. >> All right, well thanks for stopping by, and thanks for joining us from New Jersey, Michael. >> Oh, thank you, and I'll send you a cheese steak. >> All right. I don't know if I want that in the mail, but we'll see if we can maybe fast shipment, all right, thanks again for stopping by, he's Ali G, he's Michael, I'm Jeff and you're watching theCUBE, we're in our Palo Alto studios, thanks for watching, we'll see you next time. (jazz music)

>> Live from Barcelona, Spain, its theCUBE, covering Cisco Live! Europe, brought to you by Cisco, and its ecosystem partners. >> Hello everyone, welcome back to theCUBE's live coverage here in Barcelona, Spain, for Cisco Live! Europe 2019, I'm John Furrier, with my co-host Dave Vellante as well as Stu Miniman has been co-hosting all week, three days of coverage, we're in day two. We're here with very special guest, we're in the DevNet Zone, and we're here with the leader of the DevNet team of Cisco, Susie Wee, Senior Vice President, CTO of Cisco DevNet, welcome, good to see you. >> Thank you, good to see you, and I'm glad that we have you here again in the DevNet Zone. >> You've been running around, it's been super exciting to watch the evolution, we chatted a couple of years ago, okay we're going to get some developer-centric APIs and a small community growing, now it's exploding. (Susie laughs) Feature of the show, the size gets bigger every year. >> It was interesting, yeah, we took a chance on it right? So we didn't know and you took this bet with me is just that the network is becoming programmable, the infrastructure is programmable, and not only is the technology becoming programmable, but we can take the community of networkers, IT infrastructure folks, app developers and get them to understand the programmability of the infrastructure, and it's really interesting that, you know, these classes are packed, they're very deep they're very technical, the community's getting along and, you know, networkers are developers. >> Yeah you know, you nailed it, because I think as a CTO, you understood the dev-ops movement, saw that in cloud. And I remember my first conversation with you like, you know, the network has a dev-ops angle too if you can make it programmable, and that's what it's done, and you're seeing Cisco's wide having this software extraction, ACI anywhere, hyperflux anywhere, connected to the cloud, now Edge. APIs are at the center, the DNA Center platform. >> Yes! >> API First, very successful project. >> Yes yes, it's-- >> This is the new DNA of Cisco is APIs, this is what it's all about. >> It is, it is and you know, like at first, you know, when we started this journey five years ago a few of our products had APIs, like a few of them were programmable. But you know, you don't take your network in overnight, it's programmable when you have this type of thing. But we've been building it in, and now practically every product is programmable, every product has APIs, so now you have a really rich fabric of yeah, security, data center, enterprises and campus and branch networks. Like, and it can now, put together really interesting things. >> Well congratulations, it happened and it's happening, so I got to ask the question, now that it's happening, happened and happening, continuing to happen, what's the impact to the customer base because now you're now seeing Cisco clearly defining the network and the security aspect of what the network can do, foundationally, and then enabling it to be programmable. >> Yeah. >> What's happening now for you guys, obviously apps could take advantage of it, but what else is the side effect of this investment? >> Yeah so, the interesting thing is, if we take a look at the industry at large, what happens is, you kind of have the traditional view of, IT, you know, so if you take a look at IT, you know, what do you need it for? I need it to get my compute, just give me my servers, give me my network, and let's just hope it works. And then it was also viewed as being old, like I can get all this stuff on the cloud, and I can just do my development there, why do I need all of that stuff right? But once you take it, and you know, the industry has come along, what happens is, you need to bring those systems together, you need to modernize your IT, you need to be able to just, you know, take in the cloud services, to take the applications come across, but the real reason you need it is because you want to impact the business, you know, so kind of what happens is like, every business in the world, every, is being disrupted right, and if you take a look, it has a digital disruptor going on. If you're in retail, then, you know, you're a brick and mortar, you know, traditionally a brick and mortar store kind of company, and then you have an online retailer that's kind of starting to eat your lunch, right, if you're in banking, you have the digital disruption like every, manufacturing is starting to get interesting and you know, what you're doing in energy. So all of this has kind of disruption angles, but really the key is that, IT holds the keys. So, IT can sit there and keep its old infrastructure and say, I have all this responsibility, I'm running this machinery, I have this customer database, or you can modernize, right? And so you can either hold your business back, or you can modernize, make it programmable and then suddenly allow cloud native, public, private cloud, deploy new applications and services and suddenly become an innovative platform for the company, then you can solve business problems and make that real, and we're actually seeing that's becoming real. (laughs) >> Well and you're seeing it right in front of us. So a big challenge there of what you just mentioned, is just having the skills to be able to do that but the appetite of this audience to absorb that knowledge is very very high, so for example, we've been here all week watching, essentially Cisco users, engineers, absorb this new content to learn how to basically program infrastructure. >> That's right, and it's not Cisco employees, it's the community, it's the world of like, Cisco-certified engineers like, people who are doing networking and IT for companies and partners around the world. >> And so, what do they have to go through to get from, you know, where they were, not modernized to modernized? >> Yeah, and actually, and that's a good way 'cause when we look back to five years ago, it was a question, like we knew the technology was going to become programmable and the question is, are these network guys, you know, are these IT guys everywhere are they going to stay in the old world are they really going to be the ones that can work in the new world, or are we going to hire a bunch of new software guys who just know it, are cloud native, they get it all, to do it all. Well, it doesn't work that way because to work in oil and gas, you need some expertise in that and those guys know about it, to work in, you know, retail and banking, and all of these, there's some industry knowledge that you need to have. But then you need to pick up that software skill and five years ago, we didn't know if they would make that transition, but we created DevNet to give them the tools within their language and kind of, you know if they do and what we found is that, they're making the jump. And you see it here with everyone behind us, in front of us, like they are learning. >> Your community said we're all in. Well I'm interested in, we've seen other large organizations infrastructure companies try to attract developers like this, I'm wondering is it because of the network, is it because of Cisco? Are there some other ingredients that you could buy, is it the certified engineers who have this appetite? Why is it that Cisco has been so successful, and I can name a number of other companies that have tried and failed, some of them even owned clouds, and have really not been able to get traction with developers, why Cisco? >> Well I mean, I think we've been fortunate in many ways, as we've been building it out but I think part of it, you know like the way any company would have to go about you know, kind of taking on programmability, dev-ops, you know, these types of models, is tough, and it's, there's not one formula for how you do it, but in our case, it was that Cisco had a very loyal community. Or we have, and we appreciate that very loyal community 'cause they are out there, workin' the gear, building the networks like, running train stations, transportation systems you know, running all around the world, and so, and they've had to invest a lot into that knowledge. Now we then, gave them the tools to learn, we said, here's coding 101, here's your APIs, here's how to learn about it, and your first API call will be get network devices. Here's how you automate your infrastructure, here's how you do your things, and because we put it in, they're grabbing on and they're doing it and you know, so, it was kind of having that base community and being respectful of it and yet, bringing them along, pushing them. Like we don't say keep doing things the old way yes, learn software, and we're not going to water down how you have to learn software. Like you're going to get in there, you're going to use Rest APIs, you're going to use Postman, you're going to use Git, and we have that kind of like first track to just get 'em using those tools. And we also don't take an elitist culture like we're very welcoming of it, and respectful of what they've done and like, just teach 'em and let 'em go. And the thing is like, once you do it, like once you spend your time and you go oh, okay, so you get the code from GitHub, I got it, now I see all this other stuff. Now I made my Rest API call and I've used Postman. Oh, I get it, it's a tool. Just, once you've done just that, you are a different person. >> And then it's business impact. >> Then it's business, yeah no and like then you're also able to experiment, like you suddenly see a bigger world. 'Cause you've been responsible for this one thing, but now you see the bigger world and you think differently, and then it's business impact, because then you're like okay, how do I modernize my infrastructure? How can I just automate this task that I do every day? I'm like, I don't want to do that anymore, I want to automate it, let me do this. And once you get that mindset, then you're doing more, and then you're saying wait, now can I install applications on this, boy, my network and my infrastructure can gives lots of business insights. So I can start to get information about what applications are being called, what are being used, you know, when you have retail operations you can say, oh, what's happening in this store versus that store? When you have a transportation system, where are we most busy? When you're doing banking, where is like, are you having mobile transactions or in-store transactions? There's all this stuff you learn and then suddenly, you can, you know, really create the applications that-- >> So they get the bug, they get inspired they stand up some quick sandbox with some value and go wow-- >> Or they use our DevNet Sandbox so that they can start stuff and get experi-- >> It's a cloud kind of mindset of standing something up and saying look at it, wow, I can do this, I can be more contributing to the organization. Talk about the modernization, I want to get kind of the next step for you 'cause the next level for you is what? Because if this continues, you're going to start to see enterprises saying oh, I can play in the cloud, I can use microservices. >> Yes. >> I can tap into that agility and scale of the cloud, and leverage my resources and my investment I have now to compete, you just mentioned that. How is that going to work, take us through that. >> Yeah and there's more, in addition to that, is also, I can also leverage the ecosystem, right? 'Cause you're used to doing everything yourself, but you're not going to win by doing everything yourself, even if you made everything modern, right? You still need to use the ecosystem as well. But you know, but then at that stage what you can do and actually we're seeing this as, like our developers are not only the infrastructure folks, but now, all of the sudden our ISVs, app developers, who are out there writing apps, are able to actually put stuff into the infrastructure, so we actually had some IoT announcements this week, where we have these industrial routers that are coming out, and you can take an industrial router and put it into a police car and because a police car has a dashboard camera, it has a WiFi system, it has on-board computer, tablets, like all of this stuff, the officer has stuff, that's a mobile office. And it has a gateway in it. Well now, the gateway that we put in there does app hosting, it can host containerized applications. So then if you take a look at it, all the police cars that are moving around are basically hosting containerized apps, you have this kind of system, and Cisco makes that. >> In a moveable edge. >> And then we have the gateway manager that does it, and if you take a look at what does the gateway manager do it has to manage all of those devices, you know, and then it can also deploy applications. So we have an ability to now manage, we also have an ability to deploy containers, pull back containers, and then this also works in manufacturing, it works in utility, so you have a substation, you have these industrial routers out there that can host apps, you know, then all of a sudden edge computing becomes real. But what this brings together is that now, you can actually get ISVs who can actually now say, hey I'm an app developer, I wanted to write an app, I have one that could be used in manufacturing. I could never do it before, but oh, there's this platform, now I can do it, and I don't have to start installing routers, like a Cisco partner will do it for a customer, and I can just drop my app in and it's, we're actually seeing that now-- >> So basically what's happening, the nirvana is first of all, intelligent edge is actually possible. >> Yes. >> With having the power at the edge with APIs, but for the ISVs, they might have the domain expertise at saying, hey I'm an expert on police, fire, public safety, vertical. >> Yes. >> But, I could build the best app, but I don't need to do all this other stuff. >> Yes. >> So I can focus all my attention on this. >> Yes. >> And their bottleneck was having that kind of compute and or Edge device. >> Yes. >> Is that what you're kind of getting at? >> Yeah, and there's, exactly it was because you know, I mean an app developer is awesome at writing apps. They don't want to get into the business of deploying networks and like even managing and operating how that is, but there's a whole like kind of Cisco ecosystem that does that. Like we have a lot of people who will love to operationalize that system, deploy that, you know, kind of maintain it. Then there's IT and OT operators who are running that stuff, but that app developer can write their app drop it into there, and then all of that can be taken care of. And we actually have two ISVs here with us, one in manufacturing, one in utilities, who are, you know, DevNet ISV partners, they've written applications and they actually have real stories about this, and kind of what they had to say is, like in the manufacturing example, is okay, so they write, they have this innovation, I wrote this cool app for manufacturing, right? So there's something that it does, it's building it, you know, they've gotten expertise in that, and then, as they've been, they're doing something innovative, they actually need the end customer, who does, the manufacturer, to use it, and adopt a new technology. Well, hey, you know, I'm running my stuff, why should I use that, how would I? So they actually work with a systems integrator, like a channel partner that actually will customize the solution. But even that person may not have thought about edge computing, what can you do, what's this crazy idea you have, but now they've actually gotten trained up, they're getting trained up on our IoT technologies, they're getting trained up on how to operationalize it, and this guy just writes his app, he actually points them to the DevNet Sandbox to learn about it, so he's like, no let me show you how this Edge processing thing works, go use the DevNet Sandbox, you can spin up your instance, you can see it working, oh look there's these APIs, let me show you. And it turns out they're using the Sandbox to actually train the partners and the end customer about what this model is like. And then, these guys are adopting it, and they're getting paying customers through this. >> Did you start hunting for ISVs, did they find you, how did that all transpire? >> It kind of happens in all different ways. (laughter) >> So yes. >> Yeah yeah, it happens in all different ways, and basically, in some cases like we actually sometimes have innovation centers and then you have you know, kind of as you know, the start-up that's trying to figure out how to get their stuff seen, they show up, we look for it. In our case in Italy, with the manufacturing company, then what happened was, the government was actually investing and the government was actually giving tax subsidies for manufacturing plants to modernize. And so, what they were doing was actually giving an incentive and then looking for these types of partners, so we actually teamed up with our country teams to find some of these and they have a great product. And then we started, you know, working with them. They actually already had an appreciation for Cisco because they, you know, in their country, they did computer science in college, they might've done some networking with the Cisco Networking Academy, so they knew about it, but finally, it came that they could actually bring this ecosystem together. >> Susie, congratulations on all your success, been great to be part of it in our way, but you and your team have done an amazing job, great feedback on Twitter on the swag got the-- (laughter) Swag bag's gettin' a lot of attention, which is always a key important thing. But in general, super important initiative, share some insight into how this has changed Cisco's executive view of the world because, you know, the cloud had horizontal scalability, but Cisco had it too. And now the new positioning, the new branding that Karen Walker and her team are putting out, the bridge to tomorrow, the future, is about almost a horizontally scalable Cisco. It's everywhere now so-- >> Yeah the bridge to possible, yeah. >> Bridge to possible, yes. >> Yeah well I mean, really what happens is, you know, there was a time when you're like, I'm going to buy my security, I'm going to buy my networking, I'm going to buy my data center, but really more and more people just want an infrastructure that works, right? An infrastructure that's capable that can allow you to innovate, and really what happens, when you think about how do you put all of these systems together, 'cause they're still individual, and they need to be individual in best in class products, well the best way to put 'em together is with APIs. (laughs) So, it's not that you need to architect them all into one big product, it's actually better to have best in class, clearly define the APIs, and then allow, as kind of modularity and to build it out. So, really we've had tremendous support from Chuck Robbins, our CEO, and he's understood this vision and he's been helping, kind of, you know, like DevNet is a start-up itself, like he's been helping us navigate the waters to really make it happen and as we moved and as he's evolved the organization, we've actually started to get more and more support from our executives and we're working across the team, so everything that we do is together with all the teams. And now what we're doing is we're co-launching products. Every time we launch a new product, we launch a new product with the product offer and the developer offer. >> Yeah. >> So, you know, here we've launched the new IoT products. >> With APIs. >> And, with APIs, and IOX and App-posting capabilities and we launched them together with a new DevNet IoT developer center. At developer.cisco.com/iot, and this is actually, if you take a look at the last say half year or year, our products have been launching, you'll see, oh here's the new DNA Center, and here's the new DevNet developer center. You know, then we can say, here's the new kind of ACI, and here's the new ACI developer center. Here's the new Meraki feature, here's the new ACI-- >> And it's no secret that DNA Center has over 600 people engineers in there. >> Yeah (laughs) >> That public information might not be-- >> You know, but we've actually gotten in the mode in the understanding of you know, every product should have a developer offer because it's about the ecosystem, and we're getting tremendous support now. >> Yeah a lot of people ask me about Amazon Web Services 'cause we're so close, we cover them deeply. They always ask me, hey John, why is that, why is Amazon so successful I go, well they got a great management team, they've got a great business model, but it was built on APIs first. It was a web service framework. You guys have been very smart by betting on the API because that's where the growth is, so it's not Amazon being the cloud, it's the fact that they built building blocks with APIs, that grew. >> Yes. >> And so I think what you've got here, that's lightening in the bottle is, having an API strategy creates more connections, connections create more fabric, and then there's more data, it's just, it's a great growth vehicle. >> Absolutely. >> So, congratulations. >> Thank you. >> So is that your market place, do you have a market place so it's just, I guess SDKs and APIs and now that you have ISVs comin' in, is that sort of in the plan? >> We do, no we do actually so, so yeah so basically, when you're in this world, then you have your device, you know, it's your phone, and then you have apps that you download and you get it from an app store. But when we're talking about, you know, the types of solutions we're talking about, there is infrastructure, there is infrastructure for you know, again, utilities companies, for police stations, for retail stores, and then, you have ISV applications that can help in each of those domains. There's oftentimes a systems integrator that's putting something together for a customer. And so now kind of the app store for this type of thing actually involves, you know, our infrastructure products together with kind of, and infrastructure, and third-party ones, you know, ISV software that can be customized and have innovation in different ways together with that system integrator and we're training them all, people across that, but we actually have something called DevNet Exchange. And what we've done is there's actually two parts, there's Code Exchange, which is basically, pointers out to you know, source code that's out in GitHub, so we're just going out to code repos that are actually helping people get started with different products. But in addition, we have Ecosystem Exchange, which actually lists the ISV solutions that can be used as well as the system's integrators who can actually deliver solutions in these different domains, so you know, DevNet Ecosystem Exchange is the place where we actually do list the ISVs with the SIs you know, with the different platforms so, that's the app store for a programmable infrastructure. >> Susie, congratulations again, thank you so much for including us in your DevNet Zone with theCUBE here for three days. >> Thank you for coming to us and for really helping us tell the story. >> It' a great story to tell and it's kickin' butt and takin' names-- (laughter) Susie Wee, Senior Vice President and CTO of DevNet, makin' it happen just the beginning, scratching the surface of the explosion of API-based economies, around the network, the network value, and certainly cloud and IoT. Of course, we're bringing you the edge of the network here with theCUBE, in Barcelona, we'll be back with more live coverage day two, after this short break. (upbeat music)

>> Announcer: From Gillette Stadium in Foxborough, Massachusetts, it's theCube! Covering VTUG Winter Warmer 2018. Presented by SiliconeANGLE. (energetic music) >> Hi, I'm Stu Miniman and this is theCube's coverage of the VTUG Winter Warmer 2018, the 12th year of this user group, fifth year we've had theCube here. I happen to have on the program a first-time guest, Kyle Ruddy, who's a Senior Technical Marketing Engineer with VMware, knows a thing or two about virtualization. >> Maybe a couple of things. >> Stu: Thanks for joining us, Kyle. >> Oh, thank you for having me. I'm happy to be here. >> All right, so Kyle, I know you were sitting at home in Florida and saying, "What I'd like to do is come up in the 20s. "It kind of feels like single digits." Why did you leave the warmth of the south to come up here to the frigid New England? >> (chuckles) Yeah, well, it was a great opportunity. I've never been to one of the VTUGs before, so they gave me a chance to talk about something that I'm extremely passionate about which is API usage. Once I got the invite, no-brainer, made the trip. >> Awesome! So definitely, Jonathan Frappier who we asked to be on the program but he said Kyle's going to be way better. (Kyle chuckles) Speak better, you got the better beard. (Kyle laughs) I think we're just going to give Frappier a bunch of grief since he didn't agree to come on. Give us first a little bit about your background, how long you been VMware, what kind of roles have you had there? >> Yeah, absolutely! So I've probably been in IT for over 15 years, a long-time customer. I did that for about 10 to 12 years of the IT span doing everything from help desk working my way up to being on the engineer side. I really fell in love with automation during that time period and then made the jump to the vendor side. I've been at VMware for about two years now where I focus on creating content and being at events like these to talk about our automation strategy for vSphere. >> Before you joined VMware, were you a vExpert? Have you presented at VMUGs? >> Yes, yes, so I've been a vExpert. I think I'm going on seven years now. I've helped run the Indianapolis VMUG for five to six years. I've presented VMUGs all over the country. >> Yeah, one of the things we always emphasize, especially at groups like this, is get involved, participate, it can do great things for your career. >> Yes, absolutely! I certainly wouldn't be here without that kind of input and guidance. >> Indy VMUG's a great one, a real large one here, even though I hear this one here has tended to be a little bit bigger, but a good rivalry going on there. I want to talk about the keynote you talked about, automation and APIs. It's not kind of the virtualization 101, so what excites you so much about it? And let's get in a little bit, talk about what you discussed there. >> Yeah, absolutely! We were talking about using Ansible with the vSphere 6.5 RESTful APIs. That's something that's new, brand new, to vSphere 6.5, and really just being able to, when those were released, allow our users and our customers to make use of those APIs in however way that they wanted to. If you look back at some of our prior APIs and our SDKs, you were a little more constrained. They were SOAP-based so there was a lot of overhead that came with those. There was a large learning curve that also came along with those. So by switching to REST, it's a whole lot more user friendly. You can use it with tools like Ansible which that was just something that Jon knew quite well. I thought that was a perfect opportunity for me to finally do a presentation with Jon. It went quite well. I think the audience learned quite a bit. We even kind of relayed to the audience that this isn't something that's just for vSphere. Ansible is something you can use with anything. >> For somebody out there watching this, how do they get started? What's kind of some of the learning curve that they need to do? What skillsets are they going to build on versus what they need to learn for new? >> Sure. A lot of the ways to really get started with these things, I've created a ton of blog posts that are out there on the VMware {code} blog. The first one is just getting started with the RESTful APIs that we've provided. There's a program that's called Postman, we give a couple of collections that you can automatically import and start using that. Ansible has some really good documentation on getting started with Ansible and whichever environment you're choosing to work or use it with. So they've got a Getting Started with vSphere, they've got a Getting Started with different operating systems as well. Those are really good tools to get started and get that integrated into your normal working environment. Obviously, we're building on automation here. We're building on... At least when I was in admin, I got involved in automation because there was a way for me to automate and get rid of those tasks, those menial tasks that I didn't really enjoy doing. So I could automate that, push that off, and get back to something that I cared about that I enjoyed. >> Yeah, great point there 'cause, yeah, some people, they're a little bit nervous, "Oh, wait, are these tools going to take away my job?" And to repeat what you were just saying, "No, no." There's the stuff that you don't really love doing and that you probably have to do a bunch. Those are the things that are probably, maybe the easiest to be able to move to the automation. How much do people look at this and be like, "Wait, no, once I start automating it, "then I kind of need to care, and feed, and maintain that, "versus just buying something off the shelf "or using some service that I can do." Any feedback on that? >> Well, it's more of a... It's a passion thing. If it's something that you're really get ingrained in, you really enjoy, then you're going to want to care and feed that because it's going to grow. It's going to expand into other areas of your environment. It's going to expand into other technologies that are within your environment. So of course, you can buy something. You could get somebody from... There are professional services organizations involved, so you don't have to do the menial tasks of updating that. Say if you go from one version to a next version, you don't have to deal with that. But if you're passionate about it, you enjoy doing that, and that's where I was. >> The other thing I picked up on is you said some of these things are new only in 6.5. One of the challenges we've always had out there is, "Oh, wait, I need to upgrade. "When can I do it? "What challenges I'm going to have?" What's the upgrade experience like now and anything else that you'd want to point out that said, "Hey, it's time to plan for that upgrade "and here are some of the things that are going to help you"? >> We actually have an End of Availability and End of Support coming up for vSphere 5.5. That's going to be coming up in here later this year in September-October timeframe. So you're not going to be able to open up a support request for that. This is a perfect time to start planning that upgrade to get up to at least 6.0, if not 6.5. And the other thing to keep in mind is that we've announced deprecation for the Windows version of vSphere. Moving forward past our next numbered release, that's going to be all vCenter Server Appliance from that point forward. Now we also have a really great tool that's called the VCSA Migration tool that you can use to help you migrate from Windows to the Appliance. Super simple, very straightforward, gives you a migration assistant to even point out some of those places where you might miss if you did it on your own. So that's a really great tool and really helps to remove that pain out of that process. >> Yeah, it's good, you've got a mix of a little bit of the stick, you got to get off! (Kyle chuckles) I know a lot of people still running 5.5 out there as well as there's the carrot out there. All the good stuff that's going to get you going. All right, hey, Kyle, last thing I want to ask is 2018. Boy, there's a lot of change going on in the industry. One, how do you keep up with everything, and two, what's exciting you about what's happening in the industry right now? >> As far as what excites me right now, Python. That's been something that's been coming up a lot more with the folks that I'm talking to. Even today, just at lunch, I was talking to somebody and they were bringing up Python. I'm like, "Wow!" This is something that keeps coming up more and more often. I'm using a lot more of my time, even my personal time, to start looking at that. And so when you start hearing the passion of people who are using some of these new technologies, that's when I start getting interested because I'm like, "Hey, if you're that interested, "and you're that passionate about it, "I should be too." So that's kind of what drives me to keep learning and to keep up with all of the latest and greatest things that are out there. Plus when you have events like this, you can go talk to some of the sponsors. You can talk and see what they're doing, how to make use of their product, and some of their automation frameworks, and with what programming languages. That kind of comes back to Python on that one because a lot more companies are releasing their automation tools for use with Python. >> Yeah, and you answered the second part of my question probably without even thinking about it. The passion, the excitement, talking to your peers, coming to events like this. All right, Kyle Ruddy, really appreciate you joining us here. We'll be back with more coverage here from the VTUG Winter Warmer 2018. I'm Stu Miniman. You're watching theCube. (energetic music)