Introduction
Oracle Mobile Cloud Service (MCS for short) is Oracle’s Mobile Backend as a Service (MBaaS) offering. MCS enables companies to create and deploy scalable, robust, and secure mobile applications quickly and easily, and empowers developers to leverage enterprise IT systems—without having to get IT involved.
Mobile Cloud Service does not only provide a rich UI to manage and develop your mobile API’s, it also provides a well designed architecture that delivers a highly available, scalable and productive environment.
This article will go into the details of the MCS environment and will explain what to expect from it architecture.
Main Article
The article is divided in following section:
- MCS Architecture
- Scalability
- Productivity
MCS Architecture
One of the key architectural components in MCS is Node.JS.
Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
Node.JS in the marketplace
Wallmart used Node.JS to handle all their mobile users during black Friday. They received over 200 million users on that day while the CPU never exceeded 1%!
Additionally, Groupon re-implemented their system in Node.JS and they saw a reduction of 50% in response times.
A last example that shows the power of Node.JS is LinkedIn. When they changed their mobile back-end from Rails to Node.JS they could drop the amount of servers from 30 to only 3 while the new system performed 20 times faster!
For some more examples, you can read following article: Why Node.JS is becoming the go-to technology in the enterprise
The reason why Node.JS is so good in handling huge amounts of traffic is mainly because of the unique architecture of Node.JS.
Node.JS Architecture
Node.JS is an event based, non-blocking I/O framework. What this all means is that Node.JS has an event loop that will delegate requests to the appropriate code. Whenever a request is send to MCS, it will be put onto the event loop of the Node.JS container. This will call the appropriate code from your implementation in an asynchronous way. The asynchronous property of the event loop is very important for the performance in Node.JS. It won’t wait for your custom code to complete before processing other requests. Each request put on top of the event loop will be handled separately in an asynchronous way.
The same goes for your own custom code. Every time you use a callback function, you hook into the event loop of Node.JS and make use of the asynchronous property of the container. There is nothing that can block another request. The only request that can be blocked is your own request.
This in contrast to the thread based request handling where you have a set amount of threads. If all the threads are busy, no resources will be available to handle further requests so they are put on hold until a thread becomes available.
Image may be NSFW.
Clik here to view.
Although there is only a single thread to process events, it’s more than enough because the thread’s only responsibility is delegating between the incoming requests and asynchronous threads. Those threads will delegate the I/O operations to non-blocking operations so they don’t block other requests.
Although we say it’s a non-blocking architecture, there are cases where you could starve the environment from resources and that’s mainly limited to the CPU. Because there is only a single thread, if the CPU has no available cycles than the event loop won’t be able to process further events and it will have to wait until the CPU is available.
This can be solved by spawning multiple workers which can be spread out over CPU’s so you can make use of multi core environment.
So how does this architecture fit in with MCS?
MCS and Node.JS
Because MCS is like a service bus, it will have to deal with a high volume of requests. For this reason, Node.JS is a perfect fit for MCS. A lot of the time requests will call into your back-end services, whether they are other cloud services or on premise service, MCS will have to wait for the response to come back. Therefore it is important that you have an infrastructure that doesn’t block other requests when a back-end call takes a lot of time. While a request is waiting for those back-end connectors to respond, they won’t take up resources so a maximum throughput of request will be made possible through such an architecture.
Scalability
The drawback of a single threaded event loop is it doesn’t fully optimize multi-core systems. It also can cause throughput limitations when you have CPU intensive calculations however because MCS is acting as a service bus, the CPU intensive work will be done by the back-end and most likely you only will need to aggregate data from different connector calls which isn’t that CPU intensive unless you deal with huge amount of data from a single connector call.
Fortunately, these limitations can be mitigated by spawning multiple Node.JS containers as the concurrency gets higher. That’s where MCS while help you. You aren’t limited to a single Node.JS container but MCS will handle the orchestration of multiple Node.JS containers.
This means that if your throughput increases, MCS will spin up additional Node.JS containers to handle the high volume of request. If the throughput goes down, those additional containers will be taken offline, freeing resources for other use.
All this orchestration is handled seamlessly in the background.
Productivity
Node.JS is JavaScript based which means that your developers who build API’s on MCS do not need to learn a new, complex language. They can reuse their already known skills.
Because of this architecture, the silo between front-end and back-end developer will vanish and both your front-end developers and API developer will be able to talk and help each other as their skill can be used in multiple areas. In most cases you probably won’t have people assigned to the API and other people assigned to the front-end. They will be the same team and share the same tasks. They will work together as a single unit which will increase efficiency.
If a front-end developer is missing an API resource or a change need to be made on the API, he can simply do it by himself because.
Short learning curve
Because the main programming language in MCS is JavaScript, t he learning curve is short. This is mainly because most of the developers who have to build assets on MCS will at least, have a basic understanding of JavaScript. In addition to this, JavaScript is an easy to pick up language.
There is also no additional tooling to learn because you can write JavaScript in your favorite IDE or even in an advanced text editor like Notepad++ or Sublime.
We noticed this first hand when we first got introduced to MCS. Most people on the team had extensive experience with server side java but little to non experience with JavaScript however it only took us a day or so to go over a few tutorials on JavaScript before we were productive on MCS.
Productivity through community
Node.JS has a huge community backing it. Many people and companies contribute modules to the global Node.JS repository. All the modules available on the Node Package Manager (NPM) repository can be freely used by anybody else which means you don’t have to reinvent the wheel.The current NPM repo has over 173000 modules available with over 90 million downloads/day.
If you need to build something complex, there is a good change there are modules available on the repository that can help you so instead of spending two weeks writing complex code that might be error prone, you simply install a module from the repository and benefit from its development and experience.
For example, a common task in MCS is aggregating JSON payloads from multiple connector calls. This involves traversing complex JSON objects and merging them into a single one.
If you look on the NPM repository, there are hundreds of modules available that can help make this task easier.
Below you can find a list of modules that are useful in MCS:
Asynch: Module that enabled you to have a lot of control of multiple asynchronous events. It allows you to chain calls and pass values from one asynchronous call to another.
xml2js: Although MCS allows you to work nativaly with JSON, sometimes you will have to work with XML and this module allows you to easily convert XML to JSON objects.
xml-parser: A similar module as xml2js
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission