“We have a product installer built around it. We have a controller framework that monitors instances of the Node engine, scales it up, scales it down, that runs it isolated per service,” said Jung, adding that its support features include a built-in, web browser-based, interactive debugger.
Also, on hand for the discussion was RedMonk principal analyst and co-founder Stephen O’Grady, who said of SAP HANA’s Node.js support, “it’s embracing the lightweight nature, the versatility of the platform, its embed-ability.”
“It’s essentially a platform that solves a very specific set of needs very neatly,” O’Grady observed.
Listen to all TNS podcasts on Simplecast.
This podcast is also available on YouTube.
“When HANA was still quite young, we were looking at what customers and partners were doing,” said Jung. “They were putting a lot of their logic in the database itself. We saw an opportunity there to deliver an embedded application server inside the database, so that when you’re building these applications if you could put almost all the logic in the database anyway, it kept you from having to go out and find a Java or a .NET — in our case, sometimes, an application server — to put in front of that.”
“We didn’t want the traditional application server — large-scale, stateful, necessarily takes a lot of memory. We wanted something lightweight and pass-through that was just there as part of the database, and that could do basic RESTful server enablement and web serving, and not a whole lot else,” Jung recalled. “It’s not an area where you write a lot of application logic intentionally designed that way. We would want that in the database itself, to take advantage of the parallel processing and in-memory capabilities that HANA has.”
“We started off focused on reducing the cost of ownership of the total application, by having this application server in the database,” he said. “Every database instance of HANA has this application server already up and running in it. So it’s not something extra that an administrator has to turn on or configure.”
“It’s basically no extra cost to maintain this because it’s hidden behind the scenes in the database itself.”
“It also simplifies the development model,” Jung added. “When you’re building an application, you’ve got one archive to deploy, and it’s got the application server artifacts and the database artifacts in it.”
“I think if we zoom out a little bit from an industry perspective,” he added, “we see a tremendous amount of fragmentation and diversification of languages and runtimes used, and frameworks used, in enterprise context.”
“Ten years ago, there were one or two, maybe three, different sanctioned languages, typically something on Java or .NET; if you built an application, that’s how it got built,” O’Grady continued. “Today, both of those technologies are still around; they are still quite popular; they’re still used in a wide variety of contexts. But we see used alongside them a tremendous amount of different technologies, different runtimes, different languages.”
“We see this huge explosion — a flowering, if you will — of different languages employed,” he said, “essentially, different tools for different jobs, trying to take advantage of the relative strengths and weaknesses of a given platform.”
Jung stated that the SAP HANA team feels good about the technical foundation for installing and scaling Node.js. “We obviously have the continued item of keeping up with Node,” he said, adding that they’re on an aggressive schedule, so as not to fall behind releases.
“We have a major release of HANA twice a year, and at each of those we want to keep up with the latest Node versions. We are already using Node 4 internally and ready to roll that out, and then planning for the release later this year to move up to 5. There is a lot of work keeping up because of the fast-moving foundation to the runtime,” he said.
“The other area we’re really focused on is a lot of investment on the tooling and framework side. We want to build more framework pieces, more reusable node modules.” Jung also said that, besides already shipping a web-based development tool, “we want to automate more things, make development more comfortable, do some cute tricks behind the scenes so that debugging is easier so that you don’t have to restart the Node service to debug it.”
“We’re building a unit test framework for Node,” he added. “Things like that are almost like convenience features, but expected in the enterprise.”
“We’re not building them all from scratch ourselves,” he explained. “We had to pull various pieces together, and then fill in the last mile to make it all work together in our environment.”
“It is a big, new world for us, both from the containerization standpoint, and part of the larger Node.js community,” said Jung. “We want to start looking at how we can take some of the things we’ve built — some of our modules, the wrappers, the frameworks to pull together several popular open source modules — how we can contribute those back to the community so that they don’t remain SAP-specific. There are some that will probably always be SAP-specific, but then there are some that just extend the overall platform, and it would be good to contribute them back.”
“This first year, we’ve dealt internally before we released it. We have been consuming things from the community, but until things were finished, we couldn’t contribute back. Now we want to come up with a good model where we can do that.”
SAP is a sponsor of The New Stack.