MoleculerJS is a fast, modern and powerful microservices framework for Node.js. It helps you to build efficient, reliable & scalable services for your web and mobile apps. MoleculerJS provides many features for building and managing your microservices. These include supporting event-driven architecture with balancing, middlewares and versioned services.
You can find the full explanation of their features in the Moleculer’s documentation. But before we dive into the wonders of MoleculerJS, let’s first gain an overview of what microservices are all about.
What are microservices?
A microservice architecture, or simply microservices, is a distinctive method for developing software systems that build single-function modules with well-defined interfaces and operations. The architectural style structures an application as a collection of services that are:
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities.
The microservice architecture enables continuous delivery and deployment of large, complex applications. It also enables an organization to evolve its technology stack. With those attractive features, microservices have grown popular in recent years as everything from startups to enterprises are looking to become more agile and move towards DevOps approach with continuous testing.
Thanks to its scalability, this microservice architectural method is considered particularly ideal when you have to enable support for a wide range of platforms and devices, for example, web, mobile, Internet of Things, dapps, etc. Or simply when you’re not sure what kind of devices you are going to need to enable support for in an uncertain future.
The whole idea behind microservices architecture is that some types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together. In other words, each component is developed separately, and the application is then simply the sum of its individual components. In a microservices architecture, each service runs a unique process and usually manages its own database. This not only provides development teams with a more decentralized approach to building software, but it also allows each service to be deployed, rebuilt, redeployed and managed independently.
The flow of a user request can be segmented into the below sketch, which at first glance seems very complicated, but fear not, because Moleculer does most of the heavy lifting for you:
To put this into perspective, an example provided Moleculer.service on how a webshop can be created with Moleculer.
To ensure that our e-commerce system is resilient to failures we will run the products and the gateway services in dedicated nodes (node-1 and node-2). Running services at dedicated nodes means that the transporter module is required for inter services communication. Most of the transporters supported by Moleculer rely on a message broker for inter services communication, so that needs to be set up and run before continuing. This is shown in the figure above.
Now, assuming that our services are up and running, the webshop can serve user requests. So let’s see what actually happens when a user a requests to list all available products in the webshop. First, the request (GET /products) is received by the HTTP server running at node-1. The incoming request is simply passed from the HTTP server to the gateway service that does all the processing and mapping. In this case in particular, the user’s request is mapped into a listProducts action of the products service. Next, the request is passed to the broker, which checks whether the products’ service is a local or a remote service. In this case, the products service is remote so the broker needs to use the transporter module to deliver the request. The transporter simply grabs the request and sends it through the communication bus. Since both nodes (node-1 and node-2) are connected to the same communication bus via the message broker, the request is successfully delivered to node-2. Upon reception, the broker of node-2 will parse the incoming request and forward it to the products service. Finally, the products service invokes the listProducts action and returns the list of all available products. The response is simply forwarded back to the end-user.
Compartmentalization at its best, doing its best
The philosophy of the microservices architecture is to “Do one thing and do it well”. Services might run within the same process, but they can be independently deployable and replaced easily. Additionally, they can be implemented using different programming languages, databases, and software environments. The services are small, fine-grained to perform a single function. Microservices embrace testing and deployment automation, continuous software development processes, failures and faults, similar to anti-fragile systems. Each service is elastic, resilient, composable, minimal, and complete.
If you have heard of microservices you have probably also heard of containers and Docker. Containers are designed to be pared down to the minimal viable pieces needed to run whatever the one thing the container is designed to do. This is rather than packing multiple functions into the same machine. The ease of development that Docker provides helps to make it possible for rapid development and testing, similar to microservices.
Using containers and microservices together enhances cloud capabilities. Microservices are scalable and reusable, while containers supply efficient resources. Both microservices and containers can work independently, but it has become clear that merging them has improved runtime frequency, cloud-hosting policies, and cloud tools.
How is Moleculer unique?
Now that we have established the many benefits and use cases for microservices, let’s dive into why Molecular is unique and incredibly useful to anyone building on a microservices architecture.
Building JavaScript web and mobile applications using NodeJS have always had multiple advantages. One is that you can write both frontend and backend code in the same programming language, which ultimately results in high performance. For Moleculer, speed is at the epicenter of its value proposition to developers building microservices.
Who is using microservices?
A great number of mainstream online companies use microservices and the list just keeps growing. Based on our research, Netflix, eBay, Walmart, Spotify, Amazon, the UK Government Digital Service, Twitter, PayPal, and The Guardian are just a few of the many large-scale websites and applications that have all evolved from monolithic to microservices architecture. Let’s look at some of the success stories to see the results.
Walmart Canada
This is an awesome example of what should be done when aging architecture begins to affect large-scale businesses negatively. When it comes to enterprise, moving from a monolith system to a microservice architecture is more often than not a multi-million dollar question for the IT Department. This is the obstacle Walmart Canada had to address after they were failing on Black Fridays for two years in a row.
The problem that Walmart Canada faced was that their webshop couldn’t handle 6 million page views per minute during Black Friday and this made it impossible to maintain any kind of positive user experience. Before embracing microservices, Walmart had an architecture for the internet in 2005, designed around desktops and laptops.
Rebuilding Wallmart.ca
The company decided to rebuild its old legacy system in 2012 since it was unable to scale for 6 million page views per minute. Their website would break down for most of the day during peak events like Black Friday. The shift away from the old legacy system was to prepare for the world by 2020. So Walmart re-platformed to a microservices architecture with the intention of achieving close to 100% availability at reasonable costs. Migrating to microservices actually brought notable results:
- Conversions were up by 20% literally overnight
- Mobile orders were up by 98% instantly
- No downtime on Black Friday or Boxing Day
- The operational savings were significant as well since the company moved off of its expensive hardware onto commodity hardware
- They saved 40% of the computing power and experienced 20-50% cost savings overall
Spotify
Kevin Goldsmith, VP of Engineering at Spotify, knows better than anyone that an enterprise that intends to move fast and stay innovative in a highly competitive market requires an architecture that can scale.
Spotify recently surpassed the 100 million active users per month mark, with an average session length of 23 minutes. All this while running incredibly complex business roles behind the scenes. So, Spotify came to the conclusion instead of worrying about scaling to hundreds of millions of users, they needed to build their system in a way that they could scale components independently. Spotify built a microservice architecture with autonomous full-stack teams in charge in order to avoid synchronization hell within the organization. These teams are autonomous, and their mission does not overlap with other teams missions.
Spotify use of microservices today
Now, Spotify has more than 90 teams, 600 developers, and 5 development offices on 2 continents building the same outstanding product, so they needed to minimize these dependencies as much as possible.
Perhaps the largest benefit that Spotify reaps from using microservices is that they don’t have large failures; big services fail big, small services fail small. Building a microservices architecture allows Spotify to have a large number of services down at the same time without the users even noticing it. They’ve built their system assuming that services can fail all the time. Individual services that could be failing are not doing too much, so they can’t ruin the user’s experience of using Spotify.
Amazon
Amazon has also migrated to microservices. They get countless calls from a variety of applications, including applications that manage the web service API as well as the website itself. This would have been simply impossible for their old, two-tiered architecture to handle.
In 2001, the Amazon.com was a large architectural monolith. It was architected into multiple tiers. Those tiers had many components but coupled together in a spiderweb. As a result, they behaved like one big clunky monolith. They had a large number of developers working on one big monolithic webshop. Though each one of these developers only worked on a very small piece of that application, they still needed to deal with the overhead of coordinating their changes with everyone else who was also working on the same project.
A bumpy start
Things are not simple if someone on the team wants to add a new feature or making a bugfix. They needed to make sure that the change is not going to break something else on that project. If they wanted to update a shared library to take advantage of a new feature, they needed to convince everyone else on that project to upgrade to the new shared library at the same time. If they needed to make a quick fix, push out to their customers quickly, they couldn’t just do it on their own schedule. They had to coordinate that with all the other developers who have been processing changes at the same time.
Quick fixes never last
In the early 2000’s Amazon even had an engineering group whose sole job was to take new versions of the application and manually push it across Amazon’s production environment.
In short, a very long, cumbersome and complex process. True developer’s hell. It was frustrating for software engineers. Most importantly, it was slowing down the software development lifecycle and the ability to innovate. As a result, the Amazon team made architectural and organizational changes.
How did Amazon change?
Changes began on an architectural level. Amazon went through its monolithic application into a Service Oriented Architecture. The company also implemented changes in how their organization operated. They broke down their one, central, hierarchical product development team into small, “two-pizza teams”. This quote from Jeff Bezos later became famous. They wanted teams so small that they could feed them with just two pizzas. In reality, it’s 6-8 developers per team. Each of these teams got full ownership of one or a few microservices. So they were defining their own feature roadmap, designing their features, implementing their features, then test them, deploy them and operate them.
Amazon dramatically improved its front-end development lifecycle once these changes were made. Now the product teams can quickly make decisions and crank out new features for their microservices. Now the company makes 50 million deployments a year, thanks to the microservice architecture and their continuous delivery processes.
Conclusion
To sum up, MoleculerJS is one of the best microservices out there. By looking at companies like Amazon, Wallmart Canada and Spotify we have seen how microservices can turn around your organization’s website by making things run more efficiently. They are are the backbone for a well-oiled website, app or platform.
Whatever project you have immersed yourself in, if you are building in NodeJS you ought to think about using Moleculer as a microservice framework to deploy and service your applications. For the official Github and site. Alternatively, you can contact Wiredelta to help you with using these amazing microservices or any other web or app projects you have in mind.
Follow us here and on social media to keep up to date with the latest developments in all things tech.
