>> Hey welcome back everybody, Jeff Frick here with theCUBE. We are in downtown San Francisco at the Mission Bay Convention Center at Node Summit 2017. We've been coming to Node Summit off and on for a number of years. And it's pretty amazing, the growth of this application for development. It really seems to take off. There's about 800 or 900 people here. It's kind of the limits of the facility here at Mission Bay. But we're really excited to be here. And it's not surprising to have me see Intel is here in full force. Our first guest is Monica Ene-Pietrosanu. And she is the Director of Software Engineering for Intel, welcome. >> Thank you, hello, and thank you very much for inviting me. It's definitely exciting to be here. Node is this dynamic community that grows in one year, like others can. So it's always exciting to be part one of these events. And present about the work we are doing for Node. >> So you're on a panel later on Taking Benchmarking to the Next Level. So what is that all about? >> That is part of the work we are doing for Node. And I want to mention here the word stewardship. Intel is a long time contributor in the open source communities. And has assumed a performance leadership in many of these communities. We are doing the same for Node. We are driving, we are trying to be a steward for the performance in OJS. And what this means, is we are watching to make sure that every check in that happens, doesn't impact performance. We are also optimizing Nodes, so it give the best of the hardware, Node runs best on the newest hardware that we have. And also, we are developing, right now new measures, new benchmarks which better reflect the reality of the data center use cases. The way your Node is getting used in the Cloud. The way Node is getting used in the data center. There are very few ways to measure that today. And with this fast development of the ecosystem, my team has also taken this role of working with the industry partners and coming up with realistic measures for the performance. >> Right, so these new benchmarks that you're defining around the capabilities of Node. Or are you using old benchmarks? Or how are you kind of addressing that challenge? >> We started by running what was available. And most of the benchmarks were quite, let's say, isolated. They were focused on single Node, one operation, not realistic in terms of what the measurements were being done for the data center. Especially, in the data center everything is evolving. So nothing is just running with one single computer. Everything is impacted by network latencies. We have a significant number of servers out there. We have multiple software components interacting. So it's way more complex. And then you have containers coming into the picture. And everything makes it harder and harder to evaluate from the performance perspective. And I think Node is doing a pretty good job from the performance perspective. But who's watching that it stays the same? I think performance is one of those things that you value when you don't have it, right? Otherwise you just take it as granted, like it's there. So, my team at Intel is focused on top tier scripting languages. We are part of this larger software organization called Software and Services Group. And we are, right now, optimizing and writing the performance for Python, No-gs, PHP HHVM, and for some of the top tier languages used in the data centers. So Node is actually our interesting story in terms of evolution. Because we've seen, also, an extraordinary growth. We've seen, it's probably the one who's doubled for the past three years. The community has doubled. Everything has doubled for Node, right? Even, the number of commits, it depends on which statuses you look-- >> They're all up and to the right, very steep. >> Yeah, so then it's a very fast progress which we need to keep pace with. And one thing that is important for us is to make sure that we expose the best of our hardware to the software. With Node that is taking an interesting approach. Because Node is one of, what we called CPU front end bounce. It's having a large footprint. It's one of the largest footprint applications that we've seen. And for this we want to make sure that the newest CPUs we bring to market are able to handle it. >> I was just going to say, they have Trevor Livingston on it from HomeAway. Kicked off things today. We're talking about the growth. He said a year ago, they had one Node JS project. And this is a big site that competes with, like, Air B&B. That's now owned by Expedia. Now they say, he said, they had, "15 projects in production. "22 almost in production, and 75 other internal projects." In one year, from one. So that shows pretty amazing growth and the power of the application. And from Intel's point of view, you guys are all in on cloud. You're all in on data centers. You've all seen all the adds. So you guys are really, aggressively taking on the optimization, for the unique challenges and special environment that is Cloud. Which is computing everywhere, computing nowhere. But at the end of the day, it's got to sit on somebody's servers. And there's got to be a CPU in the background. So you look at all these different languages. Why do you think Node has gone so crazy? >> I think there are several reasons. And my background is a C++ developer, coming and security. So coming into the Node space, one thing amazed me. Like, only 2% of the code is yours, when you write an application. So that is like-- >> Jeff: 2%? >> So where is the other 98% coming from? Or it's already pre developed. It's an ecosystem, you just pull in those libraries. So that's what brings, in addition to the security risks you have. It brings a fantastic time to market. So it enables you as the developer to launch an application in a matter of days, instead of months or a year. So time to market is an unbeatable proposition. And I think that's what drives this space. When you need to launch new applications faster and faster, and upgrade. For us, that's also an interesting challenge. Because we have, our super road maps are not days, right? Are years? So what we want to make sure is that we feed back into the CPU road map the developments we are seeing into this space. I have on my team, I have several principal engineers who are working with the CPU architects to make sure that we are continuously providing this information back. One thing I wanted to mention is, as you probably know, since you've been talking to other Intel people, we've been launching recently, the latest generation server, Skylake. And on this latest generation Nodes. So all the Node workloads we've been optimizing and measuring. So one point five x performance improvement, from the prior generation. So this is a fantastic boost. And this doesn't happen only from hardware. It happens from a combination of hardware and software. And we are continuing to work now with the CPU architects to make sure that the future generation also keeps space with the developments. >> It's interesting, kind of the three horsemen of computing, if you will, right? There's compute, there's store, and there's IO. And now we're working, and it's interesting that Ryan Dahl, it's funny, they brought up Ryan Dahl. We interviewed him back at the Node JS, I think back in 2011? Still one of our most popular segments on theCUBE. We do thousands of interviews a year. He's still one of the most popular. But to really rethink the IO problem, in this asynchronous form, seems to be just another real breakthrough that opens up all types of capacity in compute and store. When you don't have to sit and wait. So that must be another thing that you guys have addressed from coming from the hardware and the software perspective? >> You are right on spot, because I think Node, comparing to other scripting languages brings more into the picture, the whole platform. So it's not only a CPU. It's also a networking. It's also related to storage. Also, it makes the entire platform to shine if it's optimized to the right capability. And we've been investing a lot into this. We have all our work is made available is open source. All our contributions are up-streamed back into the mainstream. We also started an effort to work with the industry in developing these new workloads. So last year at Node Interactive, we launched one new workload, benchmark, for Node. Which we called Node DC. With his first use case, which is an employee information system, simulating what a large data center distributed application will be doing. This year, now at Node Summit, we will be presenting the updated version of that, one point zero, this time. It was version zero point nine, last time. Where we added support for containers. We included several capabilities to be able to run, in a configural manner, in as many configurations as needed. And we are also contributing this back. We submitted it to the Node Foundation. So it becomes an official benchmark for the Node Foundation. Which means, every night, after the build system runs, this will be run as part of the regressions. To make sure that the performance doesn't degrade. So that's part of our work. And that's also continuing an effort we started with what we call the languages performance portal. If you go to languagesperformance.intel.com we have an entire lab behind that portal, in which every night we build this top tier scripting languages. Including Python, including Node, including PHP, and we run performance regressions on the latest Intel architecture. So we are contributing the results back into the open source community, to make sure that the community is aware if any regression happens. And we have a team of engineers who jumps on those regression center root causes and analyzes it. So to figure it out. >> So Monica, but we're almost out of time. But before I let you go, we talked before we got started, I love Kim Stevenson, I've interviewed her a bunch of times. And one of the conversations that we had was about Moore's Law. And that Moore's Law's really an attitude. And it's kind of a way to do things more than hitting the physical limitations on chips, which I think is a silly conversation. You're in a constantly, the role of constantly optimizing. And making things better, faster, cheaper. As you sit back and look at, kind of, what you've done to date, and looking forward, do you see any slowdown in this ability to continue to tweak, optimize, tweak, optimize? And just get more and more performance out of some of these new technologies? >> I wouldn't see slow down. At least from where I sit on the software side. I'm seeing only acceleration. So, the hardware brings a 30%, 40% improvement. We add, on top of that, the software optimizations. Which bring 10%, 20% improvements as well. So that continuously is going on. And I am not seeing it improving. I'm seeing it becoming more, there is a need for customization. So that's where when we design the workloads, we need to make them customizable. Because there are different use cases across the data center customers. So they are used differently. And we want to make sure that we reflect the reality. That's how they're in the world. And that's how our customers, our partners can also leverage them, to measure something that's meaningful for them. So in terms of speed, now, we want to make sure that we fully utilize our CPU. And we grow to more and more cores and increase frequency. We also grow to more capabilities. And our focus is also to make the entire platform to shine. And when we talk about platform we talk about networking. We talk about non volatile memory. We talk about storage as well as CPU. >> So Gordon's safe. You're safe, Gordon Moore. Your law's still solid. Monica, thanks for taking a few minutes out of your day and good luck on your panel later this afternoon. >> Thank you very much for having me here. It was pleasure. >> Absolutely, all right, Jeff Frick checking in from Node Summit 2017 in San Francisco. We'll be right back after this short break. Thanks for watching. (upbeat music)

>> Hey, welcome back, everybody. Jeff Frick here with theCUBE. We're at Node Summit 2017 in downtown San Francisco at the Mission Bay Convention Center. About 800 hardcore developers talkin' about Node and really the crazy growth and acceleration in this community as well as the applications. We're excited to have our next quest. He's Nick O'Leary, Developer Advocate from IBM for Watson IoT, and you're workin' on somethin' kind of cool called Node-REDS. First off, welcome. >> Thank you, thank you very much for havin' me. >> Absolutely, so what is Node-RED? >> So, Node-RED is an open source project we started working on about four years ago now in the Emerging Technologies group in the UK parts of IBM, and it's a Node.js application that gives you a visual programming tool for Internet of Things-type applications. So when you run it, you point your web browser at it, and it gives you this visual workspace to start dragging in nodes into your canvas that represent some sort of functionality, like connect to Twitter and get some tweets or save something to a database or read some sensor data, whatever it might be, and you start drawing wires between those nodes to express how you want your application to flow, how you want data to flow through your application. So it's quite a lightweight tool and really accessible to a wide range of developers whether sort of seasoned, experienced Node developers or your kids just learning how to program because it hides complexity. And, yeah, it's Node.js-based, so it runs down on a Raspberry Pi, it runs up in the cloud like IBM Bluemix, wherever you want to run it. So really flexible developer platform. >> Pretty interesting 'cause we just had Monica on from Intel, and she was talking about one of the interesting things in this development world of Node.js is so much of the code was written by somebody else. I think she said in a lot of projects the actual original code may be 2% because you're using all these other stuff, and libraries have already been created. And it sounds like you're really kind of leveraging that infrastructure to be able to do something like this. >> Absolutely, so, one of the key things we enabled very early on was to, 'cause we recognized the power of our tool, is those nodes in our palette that you drag on. So we built the system so that people could write their own nodes and extend the palette, and we used the same node packaging as the standard MPM ecosystem. And as of a couple weeks ago, we have over a thousand third party nodes people have written, so there's probably already a module for most hardware devices, online APIs, databases, whatever you want. People are creating and extending the platform in all sorts of ways just building on top of that incredible ecosystem that Node.js has. >> And then how does that tie back to Watson? You said you're involved in Watson. So Watson people don't think of necessarily a simple, simple interface but not necessarily a simple application. So what's the tie between Watson and Node.js and Node-RED? >> So, Node-RED is a development tool. I say it all hinges on those nodes and what they connect to, so we have got nodes for the Watson IoT platform, so that's great for getting, if you're running node-RED on a Raspberry Pi, connected up to our IoT platform, connect to applications in the Bluemix space. But we also have nodes for the Watson cognitive services, like the machine learning things, visual recognition, text to speech, all of those services we have nodes for. So, again, it allows people to start playing with the rich capabilities of the Watson platform without having to dive straight into understanding lines of code and you can start being productive and create real meaningful solutions without having to understand whether it's Node.js or Java, whatever language you would normally write to access low-level APIs. >> And can the visual tool connect to things that are not necessarily Node specific? >> So, anything that provides some sort of API. If it's got a programmatic API, then it's easier to do with Node 'cause we are in a Node ecosystem. But we've got established patterns for talking to other languages but also things often provides like a rest API, HTTP, MQTT, many other protocols, and we have all of that support built straight into the platform. >> Right, and so what was the motivation to build this, just to have an easier development interface? >> Yeah, it was twofold really. One was in the Emerging Technologies where I was, we do proof of concepts for clients we have to turn around really quickly, so whereas we're more than capable of writing individual lines of code, having that tool that lets us experiment much quicker and solve real client problems much quicker was a great value to us. But then we also saw the advantage for the developers who don't understand individual lines of code for educational purposes, whatever it might be. Those great motivators there in the various communities we're involved with, in IoT home hobbyists, all that sort of space as well, it's found a real incredible user community across the board. >> And when it started, was it designed to be an open source project or that kind of realization, if you will, kind of came along the way? >> I think on day one it wasn't the first thing to mind. You know, we were just experimenting with technology, which is kind of how we operated. But we very quickly got to the point where we realized we didn't have the time and resource to write all the nodes that could be written, and there was a much broader audience than just us doing our day job that this tool could tap into. So, maybe not on day one but maybe on a month in we thought this has to be open source. So, it was about six months after we started it we moved to an open source project, and that was September 2013. And then in October last year, IBM contributed the project to be a founding project of the JavaScript Foundation. Whereas it's a project that has come from IBM, it's now a project that is independently governed. It's not owned by IBM, it's part of the foundation. So, look at the wide range of other companies getting involved, making use of it, contributing back, and really good to see that ecosystem build. >> Oh, that's great, so I'm just curious, you said you deal with a lot of customer prototyping. Obviously you're involved in Watson, which is kind of the pointy end of the spear right now with IBM, with the cognitive and the IoT. As you kind of look at the landscape and stuff you're workin' on over the next, I would never say multiple years 'cause that's way too long, six months, nine months, what are some of your priorities, what are some of the things you're seeing, kind of that customers are doing today that they couldn't do before that gets you excited to get up out of bed and go to work every day? >> From my perspective, with our focus on Node-RED, which is kind of where my focus is right now, it's really that developer experience. We've gone so far with our really intuitive to use tooling, but we recognize there's more to do. So, how can we enable better collaboration, better basic workflows within our particular tooling, because there are people using Node-RED, in particular happily in production today, but it's funny 'cause we don't have a 1.0 version number because, for us, that wasn't interesting to us because we are delivering meaningful function. But in the project, we have just published our road map to a one point zero to really give that firm statement to people who are unsure about it as a technology that this is good for production. And we've got a wealth of use cases of companies who are using it today, so, that's very much our focus, my focus within Node-RED, and all of it does then tie back to yes, it's a JS foundation project, but then with my developer advocate hat on, making sure that draw from Node-RED into the Watson platform is as seamless and intuitive as possible because that helps everyone. >> Right, right, okay, so before I let you go, two things: One begs the question what version are you on, and where can people go to find more information so they can see when that 1.0 and obviously contribute? >> So as a Node project, we've stuck to Symantec versioning, so we are currently version naught dot 17. So we've done 17 major releases over the last about three and a bit years, and that's where we're moving forward. We've got this road map to get to 1.0 first quarter of next year. And if you want to find out more, nodered.org is where we're based, or you can find us through links by the JS Foundation as well. >> Alright, well, Nick, thanks for takin' a little bit of your time and safe travels home at the end of the show. >> Thank you very much. >> Alright, he's Nick O'Leary from IBM. I'm Jeff Frick, you're watchin' theCUBE. Thanks for watchin', see ya next time. (bubbly electronic music)

(click) >> Hey, welcome back everybody. Jeff Frick here with theCUBE. We're at Node Summit 2017 in San Francisco at the Mission Bay Convention Center. We've been coming here for years. A really active community, a lot of good mojo, about 800 developers here. About to the limits that the Mission Bay center can hold. Now we're excited to have our next guest. He just came off a panel. It's Jacob Groundwater. He's an engineering manager for Electron at Github. Jacob, welcome. >> Thank you, it's great to be here. >> So really interesting panel, Electron. I hadn't heard about Electron before, I was kind digging in a little bit while the panel was going on, but for the folks that aren't familiar, what is Electron? >> Yeah. Electron, there's a good chance that people who haven't even heard of it might already be using it. >> (chuckles) That's always a good thing. >> Yeah. Electron is a project that's started by Github and it's open source and you can use it to build desktop applications but with web technologies. We're leveraging the Google Chrome project to do a lot of that. And Node. And Node. Node.js is a big part of it as well. >> So build desktop apps using web technologies. >> Yep. >> And why would somebody want to do that? >> You know, I think at the root of that question, it's always the same answer which is just economics right now. Developers are in demand, software developers are in demand. The web is taking over and the web is becoming the most common skillset that people have. So you get a few benefits by using Electron. You get to distribute to three platforms automatically, you get Linux, Mac, and Windows. Sometimes it's like super easy. Sometimes you do a little bit of building to get that to happen, but it's, you know, you could cut your team size down by maybe two thirds if you do it that way. >> Wow, that's a pretty significant cut. Now you said one 1.0 released year, and how's the, how's the adoption? >> I actually can't even keep up with the number of applications that are being published on top of Electron. I'm often surprised, I'll go to a company and I'll say, oh I work on Electron at Github. And they'll be like, oh we're developing an Electron app, or we're working on an Electron app. So it, it's kind of unreal. Like I've never really been in this situation before where something that I'm working on is being used so much. I think it's out, it's out there, it's in production, it's running in millions of laptops and desktops. >> Yeah. That's great though, 'cause that's the whole promise of software, right? That's why people want to get into software. >> Yeah. >> 'Cause you can actually write something that people use and you can change the world. It could be distributed all over the world with millions of users before you even know it. >> There's this wonderful thought of like writing something once and then it running in millions of places potentially. I just love it. I love it. I think it's super cool. Yeah. So as it's grown what have been some of the main kind of concerns, issues, what are some of the things you're managing within that growth that's not pure technical? >> Yeah. That's a great question. One of the biggest things that I found interesting is when I got on our website and check the analytics, it's almost uniform across the globe. People are interested in it from everywhere. So there's challenges like, right now I had to set up a core meeting to talk about some of the like, updates to Electron and that had to be at midnight pacific time because we had to include the Prague time zone, Tokyo time zone, and Chennai in India. And we're trying to see if we can squeeze in someone from Australia. And just the global distributive nature of Electron, like people around the world are working on this and using it. >> Right. The other part you mentioned in the session, was the management of the community. And you made an interesting, you know, we go to a lot of conferences, everyone's got their code of conduct published these days which is kind of sad. It's good, but it's kind of sad that people don't have basic manners it seems like anymore. We've covered a lot of opensource communities. One that jumps to mind is OpenStack and watch that evolve over time and there's kind of community management issues that come up as these things grow. And you brought up, kind of an interesting paradigm, if you've got a great technical contributor who's just not a good person for, I don't know you didn't really define kind of the negative side but got some issues that may impact the cohesiveness of the community going forward, especially because community is so important in these projects. But if you got a great technical mind, I never really heard that particular challenge. >> I think it comes up a lot more than people realize. And it's something that I think about a lot. And one thing I want to focus on is, what we're really zeroing in on is bad behavior. >> Bad behavior. That was the word. >> And not a bad person. >> Right, right. >> One of the best ways to, to maybe get around that happening is to set an expectation early about what is acceptable behavior and alert people early when they're doing things that are going to cause harm to the community or cause harm to others. And also frame it in a way where they know, we're trying to keep other people safe, but we're also trying to keep those offenders, give them the space to change. If you choose not to change, that's a whole different story. So I think that by keeping the community strong, we encourage people around the globe to work on this project and we've already seen great returns by doing this far, so that's why I'm really focused on keeping it, keeping it a place where you know you can come and show up and do your work and do your best work. >> Right. Right. Well hopefully that's not taking too many of your cycles, you don't got too many of those, of those characters. >> Every hour I put in, I get like 10s and 20, like hours and hours back in return from the people who give back. So it's well worth it. It's the best use of my time. >> Alright good. So great growth over the year. As you look forward to next calendar year, kind of what are some of your priorities? What are some of the community's priorities? Where is Electron going? And if we touch base a year from now, what are we going to be talking about? >> Excellent question. So strengthening, formalizing some aspects of the community that we have so far, it's a little ad hoc, would be great. We want to look to having people outside of Github that feel more ownership over the project. For example, we have contributors who probably should be reviewing and committing code on their own, without necessarily needing to loop in someone from my team. So really turning this into a community project. In addition, we are focusing up on what might go into a version 2 release. And we're really focusing on security as a key feature in version two. >> Yeah, security's key and it's got to be baked in all the way to the bottom. >> Yeah. >> Alright Jacob, well it sounds like you've got your work cut out for you >> Thank you. and it should be an exciting year. >> Yeah, thanks very much. >> Alright. He's Jacob Groundwater. He's from the Electron project at Github. I'm Jeff Frick. You're watching theCUBE. We'll see you next time. Thanks for watching. (sharp music)