Not only for the giants
Microservices architecture is a popular topic, and its popularity has only been amplified by the media writing about how the biggest online services like Netflix and Amazon use it. The truth is, small web services can also benefit from microservices architecture. Actually, many already do so. Scalability is one of the most important qualities of microservices architecture, and that is exactly why organizations of all sizes choose to invest in it when building their online services.
What is it?
Back in the day, most web services were built on a monolithic architecture. A single application took care of most or all functionalities needed by the web service. An example of such architecture is a service built solely on Drupal: It consists of a frontend that offers a user interface, a backend for content management, and a database for storing the content.
Microservices architecture splits the different functionalities into separate applications that communicate with each other using APIs. Each application then does its own share of the work and can be separately evolved and scaled. In addition, each application can be built using a technology that best suits the function given to that application. In that regard, you could say that monolithic architecture puts all eggs in one basket whereas microservices architecture does not.
Why opt for microservices architecture?
It saves money
Setting up a monolithic or a microservices system can cost the same. Very simple web services can even be more affordable to set up monolithically. But when dealing with more evolved systems, the choice to opt for a microservices architecture starts to pay off.
Maintaining a microservices application can also be more affordable, as each piece can be maintained separately, and no single action to one part is likely to break another. And let us not forget the key ability of microservices architecture: scalability. When the business grows, web applications based on microservices are likely more cost efficient to scale up.
The other way to save money with microservices is hosting. When the amount of traffic increases, it usually is enough to only scale up the front end. In a monolithic system however, all the parts would need to be scaled up simultaneously, as they are not separated in any way. Microservices architecture is ideal for a highly dynamic hosting solution, where the service gets more traffic only occasionally. It can automatically scale up for that, and then scale down for night time and weekends. Another opportunity to cut costs with microservices is to utilize a serverless service model where the provider only charges for used resources. When there are no interactions with the system the cost is next to nothing.
It improves the UX
Microservices architecture splits a web service into a group of smaller applications, each built to perform its own function optimally. For example, a CMS (content management system) can focus on content management only and work strictly as a backend application. Drupal is a great open source platform for it, but the frontend features of Drupal have sometimes been criticized for being limited. In a microservices architecture frontends can be built by using more optimal technologies such as ReactJS, which was built to a large extent by Facebook to maximize its UX (user experience). Here, a maximal UX would mean a fast response time, as well as the widest possible selection of features for building a premium service with great visual design.
ReactJS or other separate front-end applications can be optimized for maximum performance and thereby best possible service quality for the website users. There are opportunities to make user interactions become just a bunch of file reads in the front-end application. This makes user interaction response feel instant, compared to monolithic solutions where each user interaction may require access to backend and database.
It is more secure
In microservices architecture, like in a decoupled web service, the backend applications do not usually need to be accessible by the public internet. Backends can be completely isolated from the internet and thereby far more secure against hacking attempts. The publicly accessible frontend might be just a bunch of files to be read when browsing a web service. As all vulnerable parts are securely isolated from the internet, there is little to be gained from hacking such a web service.
Web services of a microservices architecture are also more secure to build as development is focused only on targeted components. The risk of breaking something elsewhere in the system is minimal, unlike in a monolithic application.
It is future proof
In addition to easier and more affordable scalability, microservices architecture makes web services future proof by reducing the burden of platform upgrades. When this article was written in February 2020, the Drupal platform was in the middle of a major upgrade from version 7 to 8, which requires an almost complete rebuilding of an application. In microservices architecture, only the components in need of an upgrade have to be upgraded. The other applications can be implemented using other technologies that do not need massive upgrades. Or at least it is less likely that upgrades of different parts occur all at once.
Alternatively, it is possible to not upgrade the backend, like in Drupal 7 CMS when it is isolated from the internet and security upgrades become less relevant. It is naturally a good idea to upgrade it eventually, but there no longer is an equally pressing need to upgrade to Drupal 9 by the end of 2021.
Who is it for?
The media mostly talks about microservices architecture being utilized by Amazon, Netflix, and other giants, but smaller web services, like a number of Wunder’s clients, can also benefit from it. Some examples of these are Ruutu.fi, Traficom.fi and NKL.fi, the new site of the Finnish Federation of the Visually Impaired (Näkövammaisten liitto).
NKL.fi was made as a decoupled web service despite its extreme accessibility requirements. It was not only the legal requirements that dictated the accessibility requirements of the site, but most of its users are visually impaired and depend on the accessibility of the site. The service now also has accessible administrator functionalities, enabling visually impaired employees to manage the content of the web service. Accessible administrator features were implemented using features of Drupal CMS, while the accessibility of the front-end was made using ReactJS.
Traficom.fi is also a decoupled web service. It has a Drupal CMS completely isolated from the public internet, like an intranet. Only internal users can access the CMS and manage its content. When changes are made, these are replicated to an Elasticsearch cluster containing all the public content outside the firewall. A NodeJS application gets content from the ES cluster using GraphQL, and it is displayed to the user through a ReactJS application. This is a truly modern and also highly secure solution.
Ruutu.fi (a TV program/video streaming service) has a ReactJS frontend that fetches data from several backend applications and draws the user interface based on this data. The data includes user data, content, content structure and the user’s viewing history. The service is highly responsive thanks to these capabilities of ReactJS and it works pretty far like a native app on mobile devices.
We believe that in the future, more and more small and mid-size companies will view microservices architecture as a solid choice for the future.