 Hey, we're back live in San Francisco at Node Summit. I'm John Furrier with SiliconANGLE.com and I'm joined with Alex Williams, our managing editor of our enterprise online publication. And we're here talking about Node.js, Node Summit. It's an inaugural conference around Node and the evolution of this phenomenon around I.O. in San Francisco and changing the developer landscape relative to cloud, mobile, a lot of success stories. And our guest is Theo Schloss-Nagel from OmniIT who runs the surge conference. Welcome back to theCUBE. We had you on strata. I think Dave Vellante interviewed you. Strata is O'Reilly's big data conference which is coming up in February which will be there with theCUBE as well this year again. And big data and Node kind of all play hand in hand. But at the end of the day it's about infrastructure. It's about infrastructure IT, infrastructure as a service. Service providers all across the board. We were talking yesterday Theo around, we haven't seen, we've seen this before. It's just old wine and a new bottle. We want to look at it. DevOps trend, you were talking and saying, it's not really about DevOps, it's about ops and dev. So first, what's your take on Node and why all the, is it hyped up? Is it real? What's going on here from your perspective? So my take on Node, I don't listen to that much hype. So I'm not sure if it's over-hyped or under-hyped. All I know is that we found it pretty valuable. We were able to save a lot of money, reduce time frames on projects. We're able to prototype things and actually launch them into production in ways that we don't have to invest a lot in ongoing maintenance. So it's real, which I think is important. And its simplicity just makes it a lot more consumable. So it's great, our engineers, not so much front end but a lot of our back-end engineers that write C++ and C and Perl, they're starting to write JavaScript just because it's easy. You've been around the block, you know infrastructure, you're what we call guru in our world and you have a lot of experience in platforms and IT. What's your take on this developer movement? It seems to be a new crossover from the front end to back end and then it's got all the new capabilities. What's new here, what's not new here or is it just winding in a new bottle? So I mean, talk about DevOps. DevOps in general. I think so, I mean, my bread and butter is building back-end infrastructure systems. So I build system software from down in the kernel level up to back-end database technology and web server technology. And there are not so many new problems there. There are interesting problems. There's a lot of history to them. There's a lot of computer science around them. There are problems that front-end developers tend to not be so intimately aware of. So now that we have front-end developers flexing their proverbial muscles in back-end code, I think there's a lot of ignorance there and that's kind of dangerous. Those things can change just through education and awareness but we see people who don't understand the problems they're facing, blindly solving them again and making all the same mistakes that were made 15, 20 years ago. Is this due to issues with concurrency and node? Largely due to issues with concurrency and node but there are also things like IO safety and system resiliency and robustness and all of those things that, I mean, you're running your JavaScript code in a browser, it's not that you don't care about them, it's that the problems are different and it's an unfamiliar terrain. So you need more computer science on the back-end? You need to take some courses in systems programming and database programming, not programming a database but building a database. Yeah, there's more computer science aspects. How are you seeing these problems surface right now? Systems that are deployed that give the illusion of correct operation that basically turn around and screw you in the end. I mean, they crash, they break, they lose data. There's just not the right acumen to the values that are so key in building back-end systems. So people build stuff that breaks. So we were talking yesterday about DevOps and you were saying when the dev gets more ops then we'll talk and the dev's saying no, we're ops. I thought that was pretty clever and I think that's interesting because it's hard to be a systems programmer. I mean, you've got to go to school for it, get a degree in operating systems or whatever. It's just not many of them, right? So what are some of the things that you're seeing relative to those stumbling blocks, if you will? So I mean, I've talked about DevOps and a lot and one of my tag lines that I'm known for, I think someone called me Troll-O, Schloss-Neggle, the other day, is that I say DevOps is bullshit and the reason I say that is actually so that people will pay attention, not so much that the movement is BS, right? It's that there are a whole bunch of developers who tend to evangelize themselves more than say the blood and the mud systems administrator that's been managing these systems. They get that, I mean, the bastard operator from hell exists for a reason, right? They're asked to do one thing, make systems run all the time and they can never exceed expectations. It's not like they can run more than all the time, right? So it's a different culture. So now the engineering groups are saying we have all these really good practices for managing projects and managing code and managing concepts and the evolution of our software. Let's take all those brilliant ideas and help these ops guys, you're just hopeless. And that attitude, I mean, you can rephrase that in a really endearing way and that's not the way it's usually phrased. And the interesting part is a lot of ops people are very resistant to that because they see the other side of that coin. It's like, wow, you know what? I'm sure you know what you're doing, but your software breaks all the time in my architecture. So your best practices clearly don't build software that's operational. So how about taking some of our operational mentality and putting it in your software engineering practices? And the only reason I say DevOps is bullshit is so that I make people aware that the pendulum has swung a little too far to one side. And it's both groups that can really benefit from each other. And we had someone on theCUBE yesterday quoted ops as TNT, they blow things up and it's Orin from Haruku and TNT stands for the no team. You go to ops and you say, can we do something? No, don't take it to the no team. But in a way, the reality is that they are taken for granted. I mean, ops has to run stuff and when it breaks, shit happens. You lose money, apps fail, customers aren't happy. I mean, it's direct impact to the business. So the interesting part is that there are things that will break. There are things that are out of your control. There are physical constraints, there are systems constraints. But then someone builds you a piece of software and gives it to you. Why does that get to break too? I mean, the software is kind of a pure thing. You don't actually have to have broken software. And if it's broken, why can't I ask questions about how it's broken? Why is that software not instrumented to make my job easier? And those things are just missing a lot of times. So what are you seeing out there that would cause this balance, cause this to be more balanced? Do you see any signs of this balance changing at all? This conversation. This conversation. You know, I talk at conferences a lot about DevOps. And it's not that I don't believe in the angle that's usually presented. It's I'm presenting the other angle to make sure that it gets fair balance. I mean, I think pulling software engineering practices into ops is a great thing. Systems automation, all this stuff is awesome. But you can't lose sight of the fact that there are software engineers that really don't understand what having an operational zero downtime, no error mentality is really about. Well, we're proud to launch DevOps angle today. We just launched it on siliconangle.com as a section soon to be propagating from the URL. Devopsangle.com and it's important. A lot of people are talking about it because IT is a cost, in a way, operationally is a lot of costs involved. I mean, you know, the old joke 70% is to run the business and 30% to actually do any innovation. So people are trying to get the operational roles kind of trimmed down and efficient. So, you know, it's a challenge. And I think it's cultural. I mean, we used to call it network and software guys. It was that simple. You are a network guy and a software guy. You know, kind of like, oh, you know, screw you, you know, kind of thing. There's a kind of war, cold war going on. You know, so I think culturally, it has to come down from the top executives. And does that, as a CIO, I mean, in your experience, how do you go into these engagements with your, with customers and what are their, what's it like? I mean, do you walk in, the CIO says, okay, Theo, you guys just run the show or change these guys? I mean, what happens? Take us through them, that process. And do you think it's top down? It is, I mean, it comes from both sides. It really depends on the engagement. Our engagements vary. So we do a lot of strategic services where we're doing consulting. Some of it's from the bottom up, where you have people on the lower level director of operations and down that they can't meet their service level agreements and feel like they're put in a position where they can't succeed. And their feedback to upper management of, you know, I need more transparency across the organization. I need to be able to say, you know, I'm enabling marketing. I don't get to see their KPIs, right? Like how am I supposed to enable them if I don't know if I'm actually enabling them? And they're not being listened to, so we're pulled in to actually have that voice in a better way. And then sometimes we're pulled in by CIO or CTO, sometimes CEO, to actually, you know, exert that sort of pressure and that sort of accountability across the organizations going down. We're here inside the queue with Theo Schloss-Nagel, who's with Omni IT systems programmer, who runs the conference surge. What's next in this evolution? In your mind, okay, you know, try to shoot the arrow forward a little bit. You know it's here today. All those challenges that you mentioned are legit, real. What's going to happen? What do you see in the forecast? Maybe perhaps in context, in times of discussions you expect to unfold at surge. Yes, sir. So surge is a systems engineering conference. So we're really talking about building enormous systems and doing it wrong. And one of the things that I've learned over my career is that I can learn so much more from someone's failure than from their success. So really what I want is I want companies to come in and talk about how they had this grand idea. They did this research. They did this implementation and they still have the scars, right? It didn't work. There were bad assumptions. There were bad ideas. And to walk us through those steps. And if you do that and you have some good storytelling, you can walk away with that. So the conversations are really about failure in a lot of ways. And then learning from those mistakes and hopefully you can get enough out of that conversation to not make the same mistakes. And the future for this community, what do you see this? Do you see it kind of meeting up to expectations? I don't know what the expectations of the node community are. The node community is incredibly young. And the product is incredibly young. But the potential that we've seen hands-on with it definitely tells us that there's a long life to it. So I think what we're going to see is we're going to see the node community growing up. Not as an insult that they're all immature. It's just that there's a lot of growing up to do in this community and feeling like, where do we belong in sort of a service platform, delivery platform context? Do we power embedded devices? Do we power control planes on networking equipment? Do we power API endpoints on the web? There's a lot of talk here about enabling mobile technology. Due to the architecture of node, it really fits well with that. We've seen that. We've used it for that. And it's an exciting technology to be using in that space. Joint would say everything's a node. So like it and encompass everything. I'm more pragmatic than that. Node is a way to tell a computer what to do. All I want is a computer to do it. So node is a means to an end. There are other technologies that work really well too. So this young community, there's a lot of young people who've learned JavaScript. And PHP to some extent, that's a little skews a little bit older. Is that becoming a reason why more companies are adopting Node.js? Because there are a lot of people who know JavaScript. There are a lot of people who know PHP. I think there are a couple of different reasons. When you say PHP is older, God, you make me feel ancient. So PHP wasn't around when I started. I was thinking like mid-20s to late-20s. I'll try to remember what it feels like to be that way. Whatever elementary school, the teenager. So the adoption of Node.js, and I think that the scalability aspects, the fact that I can write a prototype for an application and actually have that scale to a reasonable level. I mean, it's not going to be the most high performance code in the world. It's not going to scale to infinity. But I can get so much further than I used to be able to get in a scripting language like Python or Perl or PHP. That's one thing. The other, which I hear talked about a lot, that I only see a couple of companies actually embracing is the fact that I'm writing JavaScript code for the front end and for the back end, and those things that are in common, I don't have to write twice. So I don't have cross-implementation bugs that happen when you re-implement something in a separate language. I actually haven't personally experienced that utopia. We don't tend to run the same code on the back end and the front end. They tend to be somewhat separate because the way our APIs run, and almost every client we interface with. So those are the two reasons I hear, though. What have you seen here at Node Summit that caught you by surprise or surprised you in a way in good and bad around the content in the startups or anything here? The people that I thought were running Node are not running it so much, and there are a lot of people running it that I had no idea were running it. So it's kind of a way, there are a lot of people that don't talk about their uses of products, and you have to catch them in the hallway track and engage them offline in a way where they'll open up about that. So it learned a whole bunch of really interesting uses of Node.js that weren't in the public eye and still aren't. Like what example? So the infrastructure components, Rackspace guys are running Node.js for deployment platforms. The Walgreens stuff was actually really interesting. I thought the Walgreens. Interesting. Guys talked about their use of Node on both sides of the platform is, I mean, they're doing really interesting. I care about things that make money or save it. I mean, those are the things that I really care about as a CEO. So when we were able to implement some of our backend systems from C and C++ into JavaScript and Node.js, I mean, I have all of the numbers that say how beneficial that was to us financially and to have another company come in completely abstract that I've never talked to and actually have a very resembling opinion and perspective on that was both validating and speaks well for making that decision again. All right, we're here saving money and making money. That's the focus of business. Node seems to be hot. Theos, Losh Nagle, thanks for coming inside theCUBE again. Great to see you. Thanks a lot. Great knowledge. Omni IT, great firm. Omni TI. Omni TI, sorry. It's all right. We're going to set up.