 Extracting the signal from the noise, it's theCUBE. Covering VMworld 2015. Brought to you by VMworld and its ecosystem sponsors. Now your host, Brian Grace Lee. Welcome back to Silicon Angles, wall-to-wall coverage here, VMworld 2015, here in Moscone North in San Francisco. I'm Brian Grace Lee, contributing cloud editor for Wikibon. And in this session, we're going to talk about cloud native applications. Pat laid out a really great vision for where the future's going, VMworld's future, how technology is really changing, software is really changing the industry. And one of the words, one of the big buzzwords, one of the technology topics that everybody's talking about is this idea of how modern applications are really changing business. And so in this panel, we're going to talk about cloud native applications. I've got Matt from Pivotal, got Ridesh from Red Hat, I've got Kevin from HashiCorp. Guys, first off, welcome to the conference, welcome to the panel. Why don't you introduce yourself, tell us what you do. Okay, I'm Matt Stein, I work for Pivotal. My day job primarily is focused specifically on working with customers in cloud native architecture. I run product management for a suite of services called Spring Cloud Services for folks who aren't familiar with Spring. It's an enterprise Java framework that's been around since around 2005. And recently we have been doing a lot of work in using Spring as a way to help people apply distributed systems patterns better, which is something that you start to run into as you go and embrace microservice architectures and so forth. So I do a lot of that, when I'm not doing that, it events like this doing evangelism topics and so forth, right? Pradesh. Hi, Radesh Balakrishnan, general manager for OpenStack at Red Hat. So as you must know, OpenStack is on a six month cadence and our approach here in this space is making available a standard distro that customers can embrace, which comes with the trust and the security that customers have been placing traditionally on Red Hat. So the offering is called Red OpenStack platform. The context we're talking about from a cloud native perspective, clearly agility is the core benefit that customers are trying to get to. I have a peer organization that's focused more on the application side, OpenShift is our offering. Hopefully we'll get to touch upon those aspects and excited to be here. Great, Kevin Fisher. So Kevin Fisher, I'm the director of customer success at HashiCorp. So I help our customers and users with our open source tools. So Vagrant, Packer, Terraform, Console, Serve Vault. We have a bunch as well as our commercial tool Atlas. So helping customers design distributed systems, applications ready for kind of cloud native. Yeah, yeah. So one of the big themes that we've seen at all sorts of conference, especially this year is, we're hearing more and more people talk about how Tesla is a software company even though they make automobiles. Uber's a software company even though they do hotel or automobiles, cabs, Airbnb. We hear it talked about as cloud native applications. We hear it as 12 factor. We hear it at microservice. There's sort of a lot of buzzwords around these modern applications. What does it mean to any of you? Matt, you've written a book called cloud native applications, but what do these modern applications look like? I have people all the time ask me what, give me an example of one so I know what it looks like because I know what a typical three tier platform looks like. Well, it's hard to start at the bottom like that because ultimately why we're interested in this idea of cloud native is that we want to somehow become like these internet web companies that have these unique characteristics and I've kind of boiled that down to four different things. These companies are able to move quicker than your traditional enterprise, but they're also able to move quickly without breaking things. One of the reasons that we traditionally move slower in the enterprise is because we don't like failure and what you see a lot of these companies have now done is as we know what, even when we try to prevent failure, we don't do a terribly good job of it. So why don't we just embrace this and figure out, well, how do we deliver, let things fail and still build reliable systems out of unreliable components? And then the third one obviously is scale. Ubiquity, you've got thousands, millions of customers who are interacting with your services. And sometimes unpredictable usage patterns so you want to be able to elastically scale in and out and all of that boils down to that idea of Ubiquity. Why is Tesla a thing? Why is Netflix a thing? Because their customers are able to interact with them at any time from anywhere, in many cases using any device that they choose. And so cloud native in my mind is the ability to do those things and it turns out that there's a lot of application patterns like 12 factor, like microservices and then platforms that enable you to deliver that type of software that actually allows you to have those characteristics. But ultimately it's not about the fact that I want to build this type of app is that I want to be those four things and what enables me to get there. Okay, so this is really not only a shift in technology but it's got to be a shift in how you do business and how you think about delivering digital products if you will. I think sometimes that's tricky for people because they like to say just throw some technology yet and throw some DevOps at it, whatever it might be. From an open stack perspective, we start to get into talking about software defined infrastructure. VMworld, while we've got DevOps days, we've got developer thing is still somewhat infrastructure centric. What is these new applications mean when we're talking about sort of software infrastructure like open stack and some other things that are out there? Right, we tend to think in terms of why, how and what, so why I think he touched upon the fact that it's all about continuous delivery of applications with a feedback loop that's very vibrant, right? So that's the why part. And then how is where the whole notion of DevOps comes in where you're talking about agility which is unprecedented in terms of being able to get access to resources as well as the division between DevOps and DevOps kind of disappearing and them teaming together if you will. And then what is where things such as microservices architecture as well as an agile infrastructure that's powering that comes in and that's where open stack fits in. See, when you're talking about microservices architecture immediately you're talking about containers and containers also need an infrastructure. So open stack has its innate ability to provide a rapidly scalable infrastructure point that he mentioned just now. Scale is of essence here, right? And on unpredictable usage pattern, right? When you're throwing out an app you really don't know. So that's where open stack squarely fits in being able to be the platform that can scale with the needs of the application. Right, so it's really the taking that new business model of how I'm going to build applications which have to go faster, have some unpredictability and you've got to match that from an infrastructure perspective that's probably going to be much more software centric, API centric and so forth. As well as well managed if you will. All the resources need to be orchestrated well enough so that you have the right set of resources at where the demonic exists, right? So Kevin, Ashikor for a lot of people is probably most well known because of a tool called Vagrant. Literally hundreds of thousands of people using it. A lot of what you guys do, not only is very interesting technology and some folks would look at it as tool centric and architectures but it's being driven by community feedback. It's being driven by open source. Like talk about how when you're working in the open source space you've got users using your product, users giving you feedback. How is that helping to accelerate how all of you are building technology? Yeah, definitely. So the way we've designed the open source tools is to each kind of have a functional core and then it's easily extensible to different providers. So I guess Packer, which is our tool for building machine images that has the core of taking configuration and building a machine image with that but it works on AWS, Google Cloud, Azure, VMware, VirtualBox. So in terms of the way that we direct the products is we give a lot of guidance around that functional core and where we think that should be going and then the community is amazingly helpful in directing those providers and saying actually this provider for building AMIs could be tweaked in this way or maybe I have a different provider in mind that isn't particularly covered for Packer or Terraform for example. So we allow basically HashiCorp to drive that main core vision and then the community is responsible for filling in where we might have missed. But I mean having thousands of contributors versus only 10 or 20 is, it's an amazing resource to have. Right. And I think it really highlights in all of you because you're all active in the open source space. It really highlights that if you're an end customer, you're an end user, your interaction is going to be as much with an end vendor as it's going to be with communities and you kind of have to learn how to work with them. You have to understand the pace at which they're building things. I know we were at DockerCon, Docker's releasing every two months so the container space is going fast. We were at Cloud Foundry Summit, there's our new release every two, three months. Even OpenStack is on a six month bit. You compare that to 12, 18 months for VMware and that compression cycle is difficult for customers. They got to figure out how to deal with it. We've been doing some research as far as Wikibon in terms of these platforms. We're trying to help customers kind of make sense of, all of you make different things. Some cases they sound the same and other cases they're different. We sort of laid them out as there's more structured platforms, there's some that are sort of unstructured. Talk about kind of as you think about, for each one of you, and it could be OpenStack or OpenShift, talk about how you explain your platform to people and are certain platforms a better fit for types of organizations? So smaller organizations, more technical or more compliance or multi-tenant types of organizations and go ahead and start with that. Yeah, so I think if I were to latch on to, let's say Gartner framework of mode one and mode two. So there's a traditional approach of applications which are well-known, well-defined and there's a set of infrastructure requirements around that so our customer conversations centered around Red Hat Enterprise Linux, KVM and management tooling around that satellite, et cetera. The other mode, mode two is where we're talking about the net new set of applications which as you mentioned behave fundamentally differently. The approach you have to take is very different as well. So that's where we bring in our new sets of technologies that we have starting from Rail Atomic as the atomic host to from an infrastructure as a service perspective, open stack and open shift as the past layer that helps abstract away some of the complexities associated with getting to a DevOps destination all managed with CloudForms which is our cloud management platform which can not only help you stitch together one infrastructure within your premises but also tied to external public cloud. So you're really looking at building sort of a vertical stack that's going to let you help with some of today's applications but then you've got options for moving forward. Kevin, you guys have taken a little bit different architectural approach. We've talked in the past about there are certain types. What's a core customer for you? What's their skill set? Maybe what's the type of product they're trying to build, the type of application they're trying to build? Yeah, it really ranges and it's really not technology focused. We only really emphasize the workflows. I think with operations we see a lot of technologies changing and we might lose side of the end goal a little bit where the end goal is to safely move an application from development to production and the technologies within that workflow are prone to change but the workflow itself is consistent. So in terms of the customers that we see are the folks that do want to move quickly and go from development to production through an automated fashion. So companies that are still hesitant towards automation are going to be a little bit tougher for us but those that embrace automation and try to reduce human error through that are really our core competency. All of our tools are automation focused and then when you stitch them together underneath the full Atlas platform you have continuous delivery from development to production. So vagrant irresponsible for making changes to the application and once that's ready you ingest the application code with Packer, build a deployable artifact, terraform provisions it, console monitors it. So you have full automation dev to prod. That's our core competency there. Okay. So Matt I know there's been some stuff on Twitter lately, some of the events lately. People have been talking about this concept of opinionated platforms and non-opinionated. There's kind of a debate about more and more people are using containers as a packaging mechanism and then how do you get those into a pack form? Like in sort of layman's terms like what does all that mean to a customer? Like why would they care about opinionated versus unopinionated or how I manage containers? Like help us understand that from a platform viewpoint. So basically what I think we have done is we've doubled down on the idea that your resources are better focused on building things that are actually gonna differentiate you from your competitors. So I could spend my time stitching together and customizing and building a platform that I think is gonna meet my needs or I could just embrace a set of opinions that exist and are already integrated and get back to the business of actually delivering software. I mean if you look at, again, you look at the unicorns and then you look at the companies that the unicorns have been able to take down, it's become pretty clear that the ability to actually deliver software is no longer a differentiator. It's a matter of survival, whether or not you're able to deliver software or not. So everybody's going to have a platform and everybody's going to get it from somewhere. Some people are gonna build it, some people are gonna buy it, but everybody's going to have one. Everybody has one today, it just may not be very good. And so coming from that, we have in a sense taken on a trusted advisory role with our customers and said, okay, we have an extensive background in building these types of systems and we have extensive background in building distributed systems of microservices to solve business problems. We kind of have an idea that if you do this, this, this and this and you integrate that together from the IS layer all the way up to the application framework stack and much the same way Apple decided to say, okay, we're gonna deliver an iPhone and we're going to tell you how you get to write code and ship code for that platform and you're not going to get to have this massive menu of choices. But because you don't have that massive menu of choices and because we have essentially taken a set of simple rules and explicit contracts, we're able to make very strong promises about if you live within this set of constraints, we can make this long list of promises of things that we're gonna deliver to your application in terms of resiliency, in terms of scale, in terms of the ability to ship new code continually. And so we've just doubled down on that idea that hey, we want you to focus on the thing that makes you different and the thing that's actually going to help you win and we'll give you the tools that you need to do that. If I could jump in, if you believe in choice is a great thing. So there are a set of customers with inherent resources internally within their firewall that they can do that DIY approach and some customers want more of an opinionated offering so we try to address both the spaces of the market. So somebody wants to take Relatomic, Relatomic platform with Kubernetes and Docker as the core foundations, if you will, and built around RHEL and use OpenStack and then stitch together their environment that approach is available to. We also have a quote-unquote opinionated offering which is our OpenShift offering which packages all of that and then comes with some of the constraints that he was referring to. So that way we can address a broad swath of customers, if you will. Okay, so I'm going to sort of give you guys all a last sort of as we wrap this up. I think I'm seeing some consensus here in terms of saying, obviously these new applications are changing business. I get a sense, all of you generally agree that in one way or the other, you're going to do that in some sort of platform, whether the platform is very opinionated as we talked about or maybe less so depending on what your technology skillsets are today. Customer comes to you and says, how do I get from A to B, right? They love the premise. They want to go compete more using software. Kevin, I'll let you go first. How do you get started? CIO comes to you, VP of application says, look, a lot of monoliths, how do we move forward? What's the first step? Yeah, that's a tough question and it's different per customer and I think the way that we approach it because our platform is built on these modular pieces, the open source pieces, we can adapt to the culture of that company and the challenges they're facing today really easily. So if they're today struggling with service discovery because they're starting to split up their monolith into a service oriented architecture, it makes sense to start with console and then you start asking questions about, well, how are you provisioning the hosts that are running these applications? Well, with this homegrown solution, it might not be the best choice. Well, how about you try Terraform to provision that environment and kind of manage that process? So each of the tools that we have fit in to kind of the overall workflow, but we can adapt to the exact challenge that the company is facing. But I think the biggest win for most companies is in our case, using Terraform to automate full environment provisioning on the different infrastructure providers. So that's the one that we recommend first if there's more choice, but depending on where you are on the stage to go from monolithic to service oriented and continuous delivery. Radesh. So from my perspective, given the fact that historically, we've had infrastructure business as well as middle way business with our J-boss offering, we have a good context in terms of where they are perceptually and their propensity to adopt a new thing. Are they brave and bleeding edge or are they more incrementally improving? So depending on that, if it's the former camp of, look, I want to make improvements, it's bringing more automation into that environment kind of approach. If it's more of, look, I'm willing to take some risks. In fact, that's the only way I can move forward. That's my changing agenda. Then we lead with open shift, open stack, that kind of conversation, right? So, and to his point, you know, he's always a function of which industry we're talking about, which particular customer we're talking about. There's no one single boilerplate answer, if you will. Matt, final word. After they go read your book and they understand cloud native, what's the best way to get that first win with a cloud native application or something that's just better software? Well, there are three challenges. Everybody's different, but there are three primary challenge areas. You've got the technology challenge of being able to deliver software. You've got the organizational challenge of being structured around being able to deliver software. If you look at something like Conway's Law, that basically says, your software is going to look like the structure of your organization, whether you like it or not. So if you want fundamentally different software, you actually need a fundamentally different organization in many cases. And then you've just got the challenge of once you've addressed those two things of being about the business of doing what you need to do. So we're primarily positioned to help you most extensively with that first challenge of let us put our platform in place in Cloud Foundry and on your infrastructure of choice and help you start delivering that net new application functionality, whether it's a completely brand new application or new functionality that is going to integrate into an existing legacy system and help you get good at that. At that point, then we can start to think about, well, if we do want to migrate some of this legacy into a cloud native world, what does this look like? But you don't want to start there because then you're solving two problems at the same time. You've got to get the foundation right and align to the business and start. So let's get good at building new stuff this way first, then start looking at legacy. But once you start to feel good at that, then you kind of have the brain power free to step back and say, okay, how is my organization structured and am I really set up to deliver software this way? Or is the fact that I'm built into these particular silos versus this continual value stream of idea to delivery, what do I need to do to restructure my people around producing the type of systems that are going to enable me to have those four characteristics that I started out with. Okay, guys, I'm going to wrap it up right there. I want to thank all of you for being on the panel, folks. Dev Office has been a big theme this week. A lot of people learning about it. We talked about this is going to impact your infrastructure. This is going to impact how you work in an IT perspective. And ultimately, if you're getting it right, you're leveraging one of the, you know, the right platform for your organization, it's going to change your business. So a huge area around cloud native guys, thanks for being on. We're going to continue to have coverage all day long here on theCUBE here at VMworld 2015. Stay tuned for more information.