Node.js on the Road: Rakuten Node Cloud

Overview of how Rakuten uses Node.js as a foundation of a Multi-tenant, Scalable, Cloud Architecture.

Fady Matar, Director of Engineering
Rakuten USA

Hi everyone, my name is Fady, there's no other Fady, there's no way you can mistake me like TJ with anybody else. I work for Rakuten. I'm pretty sure nobody heard of Rakuten before. Anyone heard of us? Oh, wow! I'm surprised because I didn't know anything about Rakuten until they hired me. Who's Rakuten? Let's get started, Rakuten started in 1997, with one goal to become the largest internet company in Japan, and mission accomplished. So, we're the biggest internet company in Japan with 85% market share ranking number 1 and number 2 in every industry.

We are one of the top 10, top 20, top 5, most innovative companies in the world, but we're definitely one of the largest e-commerce platforms in the world. So what is the Rakuten ecosystem we're talking about? The center of our ecosystem is loyalty. We have our own virtual currency which compares to the Japanese Yen and is a very strong virtual currency.

So we built all our ecosystem around this currency. We have a marketplace, think of it like Amazon; travel websites like Expedia; portal and content credit card, like Chase; banking; securities; baseball. So all of this revolves around the Rakuten superpoint, meaning that you can do any activity, purchase certificate, and then you can earn points, and you can earn and burn at different ecosystems.

So our mission now is to grow beyond Japan and go worldwide. How we do that? You will be surprised to see that we are a number of companies. We're not only one company. Lately we acquired Viber for $900 million, last year we had an investment in Pinterest for $100 million, so all the companies you see here on the map are either bought out or invested in.

Now let's talk bit about technology and what do we use at Rakuten. We use Node, we use mongoDB, we use pretty much a lot of things you've seen before, but we'll focus today on our goal which is Node. Our goal was to build a multitenant large scale platform, and how do we do that? We had to do a lot of design in mind, a lot of backward compatibility for whatever we had, and we had to restructure our whole architecture, and be cloud compliant.

So I'm highlighting in this slide some of the features we were looking for, and were provided out of the box by Node and that's why we have opted to choose Node. So, next we are going to go for the Modular versus Asynchronous Star concept in building things. In a modular way, you start your code, you build components required for it to do from function one, function two, function three, you execute the whole cycle, and return the response.

However in a Star architecture, the whole thing is different. You need to return a response as soon as possible while executing the whole flow and all your modules are injected in the cloud, meaning that you don't want to overload your system, you need to be very stable, centralized and you can decouple things quickly.

And that led us to create the core engine. So, the core engine think of it as, I don't want to say an application server, but in the old days it used to be called an application server that will allow you to build whatever you want. Build modules, build libraries, build services, build RPC component, REST services, SaaS platforms, so our structure has been already defined, we built that engine with one thing in mind: do it lazy, and we don't like repeating ourselves.

Anyone who likes to write the same code over and over again? Good, that's what I thought. So, we have the same thing. That's why we came up with the global refactoring, so that will give you a boost of like 60% of the code you need to write, and all you need to worry about is only the business logic, and make sure everything is applied for you, so you inherit security, inherit all the REST layers, all you need to do is focus on your business logic.

We make the whole thing look easier. So how do we do things? We structure our code into libraries, modules, services. So the libraries are like small chunks of code that do specific functions. Modules contain business logic. RPC and REST services are very simple, they're only a connectivity layer. So, the whole center of our attention is libraries and modules.

So, what are the steps to build our services? If you look at the blue box and you see the Module X Business Logic, this is what our developers are concerned with. They only build the business logic, the module they require, and then they can add integration points whether it is a REST layer, RPC layer, whatever you need, you add on top of it.

Next, you need to configure your module; how do you do that? Modules usually have one configuration which is local to the module, and then we have a global configuration because we are a multi-tenant architecture that can go from not only justifying and configuring tenant, it can go down to the user.

So provisioning in that place is a mechanism by which we apply configuration to the same module and you get the customization you want. And the registry is the module awareness whereby you can connect to the registry, and then discover all the services around you, and whatever you can connect to. All of this is abstracted.

It's hidden, it's in the background. As a developer, again, you only write the business logic. Next, quality assurance. TJ just mentioned that they had red nodes for Node before and now it's going to be stable. Well, I'm the same thing, at Rakuten we focus a lot on test cases, on quality assurance.

JavaScript is, I would say, it's a revolutionary language because you can't profile it properly, so you need to trust your developers in it. But again, the steps there are very difficult, so we have make files in place that will secure a lot of coverage, that will enforce developers to write the test cases, make them pass, or else nothing is published.

And then we use some profiling mechanism to be able to determine how much code is accurate, and precise, and optimized. Then we generate the documentation, and the whole thing is integrated with open source tools like Sonar Qube and TeamCity to make that happen. Now here's the lazy part. We're very lazy when it comes to the cloud, every time I have to go online we need to add a node, we need to go on Joyent, we need to purchase a server and then we need to configure it, and then we need to deploy it, and we don't like doing that, so we automated our whole deployment mechanism by using some tools there like Ansible, Icinga, Chef, and TeamCity and some bash scripts so that whenever we need to scale, it's very easy for us to scale.

Somebody's just purchasing the nodes and that's it. The elastic cloud grows. And here's a brief description of the cloud and how it works.

Now, for tips and tricks.
OK, so for the tips and tricks, I think working with Node, and since Node is a young is project, you look at NPM, I think NPM the last time I replicated the whole registry was about 25 gigs of code, I would say that probably one gig is usable, and 24 gigs of code is pure trash, so this is good.

In a way this is good because it gets people excited about tracking code, putting it out there, publishing modules, but this is not the test lab if you're working as an organisation. So, please anyone writing open source modules, we come from the Open Source Community, we love Open Source. Make sure you follow the right coding conventions, you follow proper semantic versioning.

Don't call version Laila as your girlfriend, or whatever and jump from version 0.7 to 1.5, then go back to 0.8. And make your code structure concise, simple, straight to the point, refactor as much as you want, and use only the modules that are widely used. Don't make the mistakes I've done, because I had to spend nights, and nights, and nights fixing libraries that I did not write.

Do not flood the NPM public registry and please help us to contribute to NPM in a good way. And one important thing: do not use Node for more than it is. Don't try to write a banking system in Node. It's not meant for that. So the next steps that Rakuten is trying to do is, we're considering open sourcing our platform, and the testing frameworks, and make it available.

Why? Because we come from the open source community, and we want to contribute back, we want to see feedback. We want to get feeedback of other companies, how they're using it, and we want to grow our platform ourselves, and getting feedback from different industries would be very helpful for us. So as TJ mentioned, yes,

we are hiring, and we're looking for bright people. We 're looking for stars to join us. So please guys, if anyone is interested, we're available here and back to work. Thank you.

Sign up now for Instant Cloud Access Get Started