Simplifying the Complexity of Node.js with InfluxDB

Hi, everybody. My name is Mariam Vila. I'm a full stack product designer at Node Source. Today I'm going to talk about simplifying the complexity of Node.js with InputDB. It is important to note that this talk will not be possible without the incredible team of Node Source engineers who curate the content and as an expert navigator, they've managed to simplify JavaScript-specific Node.js for me and why we use InputDB in our infrastructure. But then, let's get started. At Node Source, 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, and thus, in production. We are experts in Node.js guides that help organizations and developers use Node to its fullest to our tools and consult. For years, we have been known as the Node company. All we do is focus on Node.js. What began as an idea became the ideal. 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're doing is we are essentially making some augmentations 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 bidirectional control mechanism to control what's happening in the runtime and how the runtime behaves. So with Nsolid, you have analytics, diagnostic, security, and best of all, it's directly in production. Also, with Nsolid, you have flexible integration, specialized alerts, cloud native and container ready, and probably you're thinking, how does it work? So we're using Influx to keep track of all the process data. With all 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 data aggregation. Influx gave us rich views, each individual process in terms of line metrics, diagnostic data, capture CPU profiles or memory snapshots in order to detect memory leaks, and also security out. So we knew we kind of wanted to lean into a time series database, and InfluxDB quickly rose to 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 Nsolid is the real-time aspect. So there are a lot of APM stores across the board, from Datatab 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 actually a staging period, and what we'll see sometimes is anywhere between a minute to five minute delay 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 seconds latency between what's happening and what you are actually seeing and what you are being alerted on. So because there's a huge amount of processes occurring, InfluxDB is really poised to deliver on 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 is 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're kind of a unique user of size. We're packing InfluxDB into our 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 up to tougher order dates. 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 typical, very gentle to get in. The documentation is great, the community is excellent. But if you need just forward features and you go under the hood a little bit more, there's actually all kinds of bells and whistles and flags to kind of fine tune it for your needs. So we can say where we look at some of those things in our use case, what are some of the challenges that we face with using 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 using 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 thrown at it. The new thing for us that InfluxDB offers is actually really easy to test and debug. The good sign 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 node-source.com and check it out, we firmly believe that then solid 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 your solid. Thanks for watching.