 Live from Boston, Massachusetts, extracting the signal from the noise, it's theCUBE, covering Red Hat Summit 2015. Brought to you by Red Hat. Now your host, Stu Miniman. Welcome back to Red Hat Summit 2015 here in Boston. So much discussion about software reading the world and how open source involved in it. Of course, Red Hat has been in the center of this discussion for a long time. Really excited to have as our final guest for Red Hat Summit 2015, Sarah Navantny, who's an evangelist with EngineX. Sarah, you and I were both at DockerCon earlier this week. We made the cross-country trip to come here. You've been doing the whole developer microservices thing, so first of all, thank you for joining us. And I'm glad we can both still be upright at this point of the week. It's been a long week and a lot of travel, but it's always great to get an opportunity to go in front of our users, who of course are developers. I got to give a talk at DockerCon on Monday and I got to give a talk here at Dev Nation. Very different audiences, but great fun. All right, yeah, we're going to dig into it. I mean, the pros and cons of microservices. I mean, I'm still trying to figure out the 12-factor applications and all these things that fit. Containers is something we're all been keeping a close focus on in the last year plus. But for our audience, it's your first time on theCUBE. Just give us a little bit about your background, what led you into being a speaker at developer conferences, and then we'll talk about NGINX and the rest of it. Sure, happy to. So my background comes out of operations, much like yours. Infrastructure and the underpinnings of what eventually got named WebScale. I cut my teeth as a systems administrator at Amazon before WebScale had a name. So we were making it up as we went along. After that, I founded a company that did remote database administration as a service and provided remote databases as a service before the cloud existed. Did that for several years and have worked with Chef, have worked with a lot of open source. I'm program chair for OSCON, which is coming up here in July. It'll be a great program. I hope you guys will be there, of course. And then, and I've now focused with NGINX as their head of developer relations and doing evangelism for them. Wow, so your career has been hipster basically, doing every cool thing before we knew it was cool. We can hope so, but that means that NGINX, you don't know that NGINX is cool yet. So let's talk about why. Yeah, so let's talk about NGINX. Sure. So NGINX began 10 years ago as an open source project that was trying to solve the simple problem of putting 10,000 concurrent web connections on 2002 hardware. Now, as you may remember, you probably are old enough, 2002 hardware is roughly what we carry around in our pockets today in a phone. So imagine trying to put 10,000 concurrent web connections on your Android device. We do have an ARM built, by the way, which is very nice to know from NGINX. Oh, Dave Vellante is going to be sorry you missed this. He said, he's mentioned this a couple of times. He had somebody who knows that just graduated from school, Carnegie Mellon, and said, you know, I want to like start a company, you know, I want ARM, you know, Linux on ARM, and super excited about how that's going to drive IoT. And IoT is a whole separate space of awesome in Tipsterland if we want to go there. But NGINX, we should stay focused for just a few minutes. Squirrel. What? So NGINX began as this open source project trying to solve the C10K problem, and then has grown over these 10 years to encompass not only static asset delivery, reverse proxy, load balancing, caching, SSL termination, basically all that edge of network application acceleration that exists that a developer wants control of, but used to live in the network. Wow, so yeah, I mean, I think about 2002, I was working with Red Hat back then, I worked for a large storage company, and Red Hat advanced servers, what turned into RHEL, eventually, boy, it was making it easier for us to at least support that and test that thing. But, you know, so limited in, open source was the stuff that was used kind of in the back corners by like Bob that we don't talk about. But you couldn't afford the real stuff. Yeah, yeah, I would talk to the CIO and say, are you doing Linux? He's like, no, no, no, we're using it back over here. Shh, shh, don't talk about it. It's under my desk, we don't talk. We had that real flip over the last, three years I feel, it used to be, open source was something you didn't talk about if you're doing, to now like, it's like you're using open source, right? Because that's the way, maybe, can you talk, what have you seen in that? Because you've been involved through that whole landscape. When was that bit flipped, and why is it so critical and a must as opposed to a maybe? So, there are a lot of different theories on this. 2010 is when I really saw the flip from it being suspect in the enterprise to it being a default. And you're watching the open source community at this point change from being in opposition to the big players and instead trying to learn to embrace. You were speaking a little bit earlier about OpenStack. They're trying to embrace the big players in this space. But this big evolution has happened, I think in part, because we know that software is now differentiating within businesses and it's no longer this command and control structure of the boss says we have to use these things. It's now the developers who are the king makers and they want to control and manage and understand and play with tooling before they're told what to use. And so, having something available as a download to play with it and have it proved out in meritocracy is the way that you get software adopted these days. Yeah, so, as an operation person, I mean the thing I've been kind of yelling about for too many years now is, IT would make temples bespoke silos of infrastructure with lots of geek knobs and over orchestrate that and kind of the web scale, hyper scale model was we start with the application and I don't necessarily have people doing all that. Optimize for the application, not for the infrastructure and that's something we're talking about a lot. So maybe get into that a little bit. Yeah, sure. So I think we're seeing a new alignment of interests and that's what's driving some of that. We saw it sort of codified in the description of DevOps. But basically 10 years ago, the developer and the operations teams, the developer teams and operations teams had different interests. The developer was tasked with giving new features and the operations team was tasked with stability and those are in opposition. If you say let's put in new features but I don't care how it behaves in production, then that's not going to move you forward. That's not actually going to, that's going to get you the boff, the guy who always says no, because he doesn't want to risk his goal of stability. So we had developers and operations in contention as opposed to together. But as we've seen businesses evolve and learn and know that what differentiates them is the feature set in their software, is their ability to change the user experience, to respond to their user experience, then you have an alignment of the interests of both stability and feature sets around better delivery and faster delivery and the user experience. All right, so you've been speaking on microservices. I know you spoke at DockerCon. Did you speak about that here also? I did here as well, yeah. All right, so I don't know if it was the title but somebody tweeted about the pros and cons of microservices. They're the same. So yeah, let's get into that because something we always look at is, everybody's like Docker and it's like, well, where are we with Docker? What's it good for? What's it not good for? Where should I put it? Is Google's using containers at scale for years and years, Red Hat's been using it. So please elucidate for us the pros and cons of microservices. Sure, so one of them to the point you're making is speed. You can get from my container on my desktop to my container in production in no time flat. And that speed is great. And it's also, it's a double-edged sword. We can get it out in no time flat but we can also break things in no time flat. So again, that tension between development and operations shows up there. So that's one of the examples of ways that the same things that help our challenges. Complexity. I'm going to now build microservices. Instead of having one big monolithic application that I have big meetings about deploying slowly, I now am deploying two, three, five, 10 times a day an hour. And that brings in new complexity, new tracking challenges. I think the jury's still out on orchestrating containers completely. In 2013 and 14, it was roll your own. End of 2014, we started seeing some open source projects coming to fruition. I'm not so ashamed of this code that I'm not willing to share it anymore. So we've got Kubernetes out. We've got Swarm out. We've got Docker Compose out. There are a dozen other open source projects working at this. And so now people have so many options but what are the best practices? What is going to be the convergence point? What is the tool set that is going to emerge from this? I hope late 2015, 2016 as the standard in order to make the enterprise more comfortable. Because again, operationally, it's very difficult right now to run containers without having the depth of skill that someone like Google or Red Hat or the larger web scale companies have. Yeah, can you help just lay out for us kind of the DevOps movement, Docker and microservices? I saw somebody on Twitter said, Docker was all anybody talked about last year. Now it's like microservices is all there. But I mean, they're all interrelated a little bit. So can you just help lay out for us those three? So I'll harken back to Chef in say 2011 or so when DevOps was being coined as a term. And when the description was infrastructure as code. So you have now the concept of a trackable and version controlled infrastructure. So I say definitively this is the state that my infrastructure should be in and I run these tools to build this infrastructure state. So that was Chef in 2011. That was the beginning of DevOps. It was all about repeatable, maintainable, orchestratable infrastructures. And then we saw containers show up and then it becomes, well, we saw cloud being a big mover in that and a big operational backwind for or wind in the sales of DevOps. Then containers existed and containers have existed for years, but Docker has made them more accessible to your average developer or operator for lack of a better term DevOps person administrator. So putting a wrapper around that makes it simpler to interact with means that you have more people adopting it and more people trying to put it into production. DevOps, again, is looking at this as an evolution from infrastructure as code to immutable infrastructure. We never actually change anything. This is moving from the idea you were talking about these silos and enterprise where this was my favorite server and I have saved it and worked with it. We did, we did, we spent hours thinking of naming conventions for them. One of the largest arguments I ever saw on Amazon was about the naming convention for servers at 1.97. So naming conventions. Could you imagine Amazon trying to name how many servers they have? No. So we used to, this is the servers as pets. So we knew them. They had personalities. They were our friends. They called us at two in the morning. And now we've moved to a space where it's servers and container servers or instances or containers kind of taking the logical extension of compute units as cattle. If it's not doing what you think it is, shoot it. Eat it, move on to the next one, build another one. So you have this logical evolution from the I know everything about this as a systems administrator to the everything is in my code repository of infrastructure as code to I'm never changing it but this Docker file builds it and then if it doesn't work, I kill it. And now you're in a mutable infrastructure where we would never change a running instance or a running container but you would instead build the new one with the new requirements and be moving things in and out of load balancing or application delivery platforms in order to, or pods or service collections. Yeah, one of the most interesting data that I saw at DockerCon was how long an application lives in a container. It actually came out of New Relic and they said some are, they were saying it's like bacteria lifespan. I mean, you know, minutes if you're lucky because it spins up, there's like Google with what, it's a two billion a week that they spin up and down and then there's some that live a little bit longer and some that live a long time, more like VMs which they said, you know, VMs, the great analogy I saw in a blog post once, it was, oh geez, it's like, you know what, are you dinosaurs or you mayflies because there's the change types of life cycles. When you talk about, you know, what's the DevOps mindset on that? Building applications is very different if you're spinning up for a short period of time versus long period of time. It is, it ends up being again that repeatability and then discrete inputs and outputs. So you no longer are looking at, this ties right into microservices, you're no longer looking at something that does multiple business functions, you're looking at a piece of code that does one thing. I put in this type of data, I expect this other type of data out or I ask, I query a container at an API endpoint for something and then I expect something out. But they're much more short lived. This AWS and Lambda is much like this. So you just, you define the service that you expect, the code base that's going to run, which is usually a few hundred lines and you have an input and you unexpected output and that's it. It lives only as long as it needs to. So you worked at Amazon. Long before AWS, so let's be clear. Long before AWS, you worked at Amazon, you know, you're heavily involved in open source. If I'm a developer, should I develop for AWS? There's some great tools. We've got things that run on AWS, but if you come here at Red Hat, I mean, they work with AWS, they live there, but what do the developers think about Amazon, about Google, who leverage and use open source but aren't putting everything back upstream versus things like OpenShift and OpenStack and things that Red Hat does. Right. I think that you find a big divergence in that space. The people who have no infrastructure at this point are landing in the public clouds. It could be Azure, it could be Google Compute, it could be AWS and they're all vying for that ecosystem. And those are the newer companies, the younger companies, the non-regulated companies, those that don't have high levels of compliance. And those people are by default saying, well, we won't put in any CapEx, so we'll just do it this way. And then you have longer-lived companies, that have been around, that may be highly regulated, that may have requirements for compliance, that have to know more granularly, more specifically, and with more control where their data lives, what their applications are running. And those end up being in the space of the OpenShifts, the OpenStacks, even something like Rackspace, offering the private cloud as a service or BlueBox, now IBM. So those, you have a split. If you're going for the super fast, I just need to get a thing out and I'm three developers in a garage, you're putting it on a cloud without, you're putting it on a cloud and it may be within containers, even in this case. I mean, there's container engines for both, both Google and, well, actually all three of the major clouds now, so. So you went to DockerCon, you're at DevNation. I am. Developers are not a homogeneous group. They are not. Can you speak to kind of the developer events that you're seeing, how do we parse that out? Are there different segmentations that we can easily call out from the different developers? Yeah, so I tend to think that there are two very broad groups of developers, those who are always looking at the new thing, the shiny thing on the Vanguard. And those were the people that were at DockerCon. Now, they could live within an enterprise and be tasked with evaluating what's new and shiny. They could be just out on their own, they could be in the hipster world, as you described it. And then there are the developers who are much more comfortable pushing forward with the tool sets they know, making use of them, and even extending them and growing them beyond their original intent in a way that is interesting technologically on its own. And there was a very different vibe between DockerCon in here. DockerCon microservice is yay, you asked, you know, how come this is all we're hearing about right now? Who knows, it's a buzzword right now. Everybody loves it. We went from zero proposals last year for OSCON that had microservices in the title to 30 out of 1200. That gives you an idea of how buzzworthy it is right now. It is service-oriented architecture with new evolutions, with new changes. But here, sorry, at DockerCon, nobody said, well, how is this really different from SOA? And here at DevNation, there was a lot of, well, how is this really different from SOA? We've been doing this. What is different? Why is it more interesting? Why is it better? What are the pros and cons of it? And it was very interesting to have that pushback going. It's not just shiny, and it's not everybody on the bandwagon. Yeah, and sometimes it's just the technology catching up and being ready for it. I was at the CTO office at EMC, and Jeff Nick, an IBM fellow in there, he talked about enterprise service bus and SOA architectures and restful APIs and everything in 2007 and me being an infrastructure and networking guy who wasn't ready for it. And today, talk about platforms and APIs and plugins and everything, it's like, oh wait, it's an extension of what we're there. So, you said before, you quoted the book, Developers of the New Kingmakers. How much of the world does this take over? How much are companies ready for it? And how much of a shift is this going to be for IT staff as we see it? I think IT staff are adapting and adopting and learning. One of the best parts of tech is that you are always learning. It is always changing. But again, it's that double-edged sword. So I think you see a lot of operations people responding sometimes with a bit of fear that if they don't adapt, they will be left behind. But if they can take that fear and flip the coin to excitement and take this opportunity to learn more programmatic skills and learn more of the new tooling and see how it can make their lives better, especially as you align those interests between building new features and stability and pushing the pager out to those who say wrote the code, then you'll see a lot of, you'll see a lot faster movement in organizations and you'll see a happier enterprise. Yeah, friends of ours, if you say, if I'm a technologist that means I'm excited about the change and the opportunity because change can be scary, but it's also that opportunity to kind of move things forward. I want to give you the last word, NGINX, yourself, how do we learn more? What do you recommend? This great way to end, last year we had Gene Kim on the program for everybody that hadn't read. His book is usually one of the first ones, Phoenix Project, to say to learn more about this. Help us close it out on the definition piece. So Phoenix Project, a great book metaphor and story around the evolution of the enterprise. NGINX.com, of course, has lots of information about both open source and our commercial product and the differentiation we're doing there. I'll be at OSCON the whole third week of July, so any of you who wants to visit there, it's a great show, and people can find me on Twitter, which is just Sarin Avatni. Awesome, Sarah, thank you so much. Appreciate you coming. It's great to finally meet you in person. Absolutely, I mean, it's what we love as always, knowing each other through Twitter for all these years, get to meet in person, have the kind of conversations that we've had through the transfer and bring it out to our environment. So great way to wrap it up. Thank you, Sarah. I'll be right back with a wrap up here from Red Hat Summit 2015. Thanks for watching.