Simplifying the Complexity of Node.js with InfluxDB

Hi, everybody. My name is Mariam Bilan. I'm full stack product designer at NodeSource. And today, I'm going to talk about simplifying the complexity of Node.js for Windows DB. It is important to note that this talk will not be possible without the incredible team of NodeSource engineers who curate the content. And as an expert navigator, they've managed to simplify JavaScript specifically Node.js for me and why we use InputDB in our infrastructure. But then, let's start.

At NodeSource, we are the main Node.js distributor on Linux. Our value is centered on our expertise and the ability we have to translate performance data into a product, accessible, interpretable, actionable, do so in production. We are experts Node.js guides that help organizations and developers use Node to its fullest through our tools and consult. For years, we have been known as the Node company, always focused on Node.js, what became the idea, became the idea.

Specifically today we are going to talk about our Node.js Enterprise Runtime called NSolid, which is an Enterprise version of the open source project that is available out in the web. And what we are doing is we are essentially making some implementations that allow you to access the internal behavior of what is going on inside of the Runtime, and we're exposing this to a console. We have amazing case studies supporting the unique features of NSolid. You can access performance details, performance metrics, diagnostic capabilities, security insights, but also provide a bi-directional control mechanism to control what's happening in the Runtime and how the Runtime behaves. So with NSolid you have analytics, diagnostics, security, and best of all is directing in production. Also within NSolid, you have flexible integration, specialized alerts, cloud native and container ready. And probably you are thinking, how does it work? So we're using inflows to keep track of all the process data. With all of these metrics and analytics that we're getting, we're looking at serving large installations of nodes, hundreds or thousands of processes running at the same time across different environments. And in order to do that, we are using InfluxDB. InfluxDB drives with the data aggregation. InfluxDB gave us rich use, each individual processing, their supply metrics, diagnostic data, capture CPU profiles or memory snapshots in order to detect memory leaks, and also security. So we knew we kind of wanted to lean into a time series database. And InfluxDB quickly rostered the top of the list. So we quickly worked to migrate to InfluxDB. One of the things that was really important to us is one of the unique values propositions of Ensolving is the real-time aspect. So there are a lot of APM tools across the board, from Datatank to New Relic and whatnot. And there's a variance in terms of how available the data is. It's not necessarily real time. There's actual staging period.

And what we'll see sometimes is anywhere between a minute to five minutes delayed before you actually see those results. What we want to see is be proactive. So our sampling mechanism is every three seconds. So there's a three second latency between what's happening and what you are actually seeing and what you are being alerted on. So because of there's a huge amount of processes occurring, InfluxDB is really poised to deliver that.

A single binary is all you need to run InfluxDB actually. So the ease of distributing was actually a critical aspect for us as well. It simplified a lot of the steps. So when using InfluxDB, how did we integrate this into our product? So we actually tried to limit what the customer has to do with configuring InfluxDB. So out of the box, our product just works. And InfluxDB is just kind of magically there and it's provided. However, from a security, from a configuration standpoint, we have a lot of different configuration mechanisms that customers can do to actually control the cardinality, change their permissions, and even change how the indexing works with InfluxDB.

So it's important to kind of highlight and kind of reiterate that we are kind of a unique user of size we're packing InfluxDB into a product. And as a result, we're actually offering 24-7 support to our customers on a unique set of issues. So we don't support the issues that might come up with InfluxDB related to our product and have to cover other things. So one of the great things about Influx is that it actually provides. I think the learning curve actually is very nice. It's actually very gentle to get in. The documentation is great. The community's excellent. But if you need those forward features and you go under the hood a little bit more, there's actually all kind of bells and whistles and flags to kind of fine-tune it for your needs. So we can say when we look at some of those things in our use case, what are some of the challenges that we face with Utility Influx.

So I think that integrity is one of those things that we're constantly kind of guarding our head up against. So as you look at Utility Influx, it's really important. And this is more about understanding your application, understanding your customers or your use case and the shape of your data and how you want to access that. Influx is there and it can really kind of meet those demands of huge amounts of data being provided. Anything for us that Influx DB offers is actually really easy to test and debug. The good side of a good database implementation is that the user doesn't necessarily know about it or need to build that isn't there. So we're happy with using Influx. Generally, if users were interested to go onto Nodesource.com and check it out, we firmly believe that then Ensolve is the only node you should be running in production because it gives you all the insights and magic and security goodness as well as diagnostics. So if people want to head over there, you can easily sign up, check it out, run a couple of processes, take a couple of CPU snapshots and then get going right now on Ensolve. Thanks for watching.