RESTful APIs and Microservices: How to Make the Leap and Why It Can’t Wait
Modern RESTful microservices can give you a competitive edge. Learn how to get an early start implementing and deploying them now.
Join the DZone community and get the full member experience.Join For Free
Delivering microservices requires more agility than ever before: IDC analysts call it “Digital Transformation.” But this curse can easily turn into a blessing if you have the right tools.
Microservice architecture is the new competitive edge for businesses. In this article, we’ll go into why you should make the jump to modern RESTful microservices, and how to implement and deploy them.
The goal here is to equip you with the knowledge necessary to quickly launch RESTful services and break down monolithic apps. This unlocks efficiencies and agility, as well as potential new revenue sources from data exposure to third parties.
Why Make the Leap?
First, as you know, monolithic apps can be a drag! Even small changes may require the reassembly and deployment of an entire product. Besides, they’re slow to build, and they create team dependencies as well as a many-year commitment to a technology stack.
Microservices, on the other hand, give us flexibility and diversity—of teams, programming languages, and storage technologies. This greatly simplifies both product development and maintenance.
However, there are things you may stumble upon when developing a modern microservice:
Even if you have a decent and seemingly simple service, it may not be fast and it may suddenly turn out to consume extra machine, human and financial resources.
Traditional relational databases are not designed to support rapidly changing microservice system requirements. So when implementing microservices, you may encounter issues with speed, query processing time, and scaling. And the usual memory caches you may try to use to help out are severely limited in their capabilities. In other words, you may still need transactions, stored procedures, secondary indexes, and many other things: “there's no life without SQL,” as they say.
But let’s start with the overall picture.
Two Wings of Agility
The major problem is that although we are thinking of butterflies, we still develop elephants sometimes. A typical microservice multicomponent architecture “flies heavily,” as it includes at least:
A web proxy, i.e. NGINX, to handle slow clients (with an unstable Internet connection).
An application server, such as Apache or Django, to implement business logic.
A caching system, like Memcached or Redis, to cache content from your DBMS.
A database proxy or a DB connection pool for your DBMS to be really efficient.
A DBMS itself to store your data.
“Well, it looks OK,” you say. However, it is a big, fat, heavy elephant with four legs and one trunk.
You need to feed it, i. e. hire at least three pros, including a DBA, an admin, and a developer. Being multicomponent, it adds latency, increases the number of failures, and causes problems with data synchronization between the cache and the DBMS.
You’d better turn these five limbs into two wings instead. You can do this by combining components #2, #3, and #5 into one instance, in order to get a proxy server and storage tandem.
This tandem will need to serve a huge number of parallel client sessions so it should include a fast, multifunctional and flexible proxy, plus an equally fast and persistent storage, sitting next to the proxy. Two more requirements for the tandem are:
A full and fast algorithmic scripting language with support for non-blocking I/O;
Enough functionality to be a full-fledged replacement for a classic RDBMS, though it should have nothing of its flaws.
Use an Agile-First DBMS
Now back to databases. Each time you choose the right DBMS, one tiny kitten happily purrs somewhere. And very few solutions in the space can fulfill our requirements.
Almost all DBs:
Use their own proprietary language, usually based on a SQL sublanguage;
Can’t stand the weight of the modern high-load web;
Have no appropriate toolkit, i.e. HTTP, a connector to another database, and so on;
Have ridiculous and sophisticated application-level models.
In addition, not every database has transactions.
Tarantool, on the other hand, is uniquely designed for our purposes because it is a full-fledged database with SQL support, ACID transactions, primary and secondary indexes, and it works on disk and in memory. It also has an onboard Lua-based application server.
Basically every instance of your database is its own microservice—out of the box.
You can easily implement the processing of REST requests with the built-in server, which will save you time. Powerful speed and sharding and replication were designed for global web-scale performance, although the architecture also enables easy independent management. Thus, with its many-in-one functionality, Tarantool can easily replace at least three of the microservice elephant “legs” described earlier.
We will use the Tarantool NGINX upstream module, which makes our magic two components out of the original five. To get more specific, “legs” two, three and five are replaced by Tarantool. Number one is handled by NGINX, while number four, a database proxy, is also part of NGINX. For an explanation by the originator of the module, see here.
Basically, a user sends REST or JSON RPC requests to NGINX with the Tarantool upstream module. The latter connects directly to one Tarantool instance, or even balances workload among many instances. NGINX and Tarantool communicate via a MessagePack-based protocol. And here's what Tarantool actually helps you with:
Since Tarantool is not just an effective in-memory DBMS but also a full-fledged application server (apps can be written in Lua, C, C ++), you can write logic of any complexity with it. To top it all off: the application works in the same address space as the DBMS, which greatly simplifies your app zoo, plus reduces the userspace<->kernel switching overhead, network interaction and other "dances of daemons.”
Of course, we don’t suggest moving all business logic to this system, i.e. completely replacing a separate application server and DBMS. Instead, you may consider, for example, singling out the most heavily loaded parts of your project for microservices, where and when traditional solutions aren’t performing. For the rest, you could consider using Tarantool as a general-purpose DBMS via connectors from various programming languages (or you could, of course, maintain your existing DBMS and backend language).
The practical examples in my next article, RESTful Services Made Simple: How to Get Started in 3 Steps, will help you simplify your service architecture and will show you how to remove in detail the extra “legs” mentioned earlier.
Opinions expressed by DZone contributors are their own.