 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 IO 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 Omni IT, runs the search 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, you know, 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 in a new bottle. However you want to look at it. DevOps trend, you were talking and saying, eh, 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 were 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 backend 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, we call it 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 wanting a new bottle? So I mean, talk about DevOps or you guys. DevOps and general communities. I think the, so I mean I, my bread and butter is building backend infrastructure systems. So I build system software from, you know, down in the kernel level up to backend database technology and web server technology. And there are not so many new problems there. They're 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 backend code, I think there's a lot of, 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 code 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 you're just, it's an unfamiliar terrain. So you need more computer science on the backend? 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 backend 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 Dev 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 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 a lot and one of my tag lines that I'm known for, I think someone called me Troll-O Shloss-Nangle. Is that I say DevOps is bullshit and I mean 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 that 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 fucking 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 Oren from Heroku and TNT stands for the no team. When 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 a URL to a 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 you know, 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 was that simple. If you are a network guy and a software guy, you know, kind of like, oh, you know, screw you, you know, kind of thing. I guess I got a war, a 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 got 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. And 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 see, 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 Program and 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 the forecast of? Maybe perhaps in context, in times of discussions you expect to unfold at surge. 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, you know, 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, you know, where do we belong in sort of a service platform, delivery platform context? Are we, do we power embedded devices? Do we power, you know, 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 in Node, so why couldn't it 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 are, who've learned JavaScript. And PHP to some extent, I mean 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, live out of it. I'll try to remember what it feels like to be that way. Elementary school to teenager. Yes, so I mean 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 of 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, in 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, the 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.