When traditionally building a Node server, you'd start with a new repo, install Express or Nest, and create routes based on your needs. Inevitably, as the project grows, you'll end up making more and more routes as well as more and more files. Eventually, you end up with an unwieldy monolith, where making even the slightest change leaves you with a sense of dread; you're just waiting for the house of cards to come tumbling down.
Maybe that was a little too dramatic, but it describes a real issue developers face when developing a backend. We have different architecture models to choose from to address this and other issues. The one we'll highlight today is microservices architecture.
What is microservices architecture?
Microservices architecture is a design paradigm where applications get broken up into multiple distinct and separate services. The benefit of this is that each service is a mini-application that ends up being independent of the others, making it easier to maintain and test independently. In addition, with each service responsible for its business domain, individual teams can be responsible for its complete development cycle. They're not beholden to other teams or parts of an application. This makes it easier for teams to ship often, use the best tools or technologies for the job, and not worry about the impact a change in the codebase would have on other services.
This development style differs from traditional monolithic architecture. In monolithic architecture, as an application increases in functionality, small codebases become larger ones. As a result, multiple teams working in the same codebase can create bottlenecks for others, especially in maintaining shared dependencies. By breaking up large codebases into smaller modules grouped by their relevant parts, we can avoid the headaches and difficulties of monolithic architecture.
The cons of the monolith
Monolithic architecture has other disadvantages. For example, larger deployments become more challenging as an application's single point of failure can cause the entire deployment to fail. In addition, even the most minor changes require the whole application to be tested, end to end, before deployment. Worse yet, the scalability of an application gets ugly.
Imagine that you manage a mall that has a trendy coffee shop. As traffic increases for that coffee shop, would you want to create a whole new mall, filled with hundreds of stores, to handle serving coffee to your patrons? Or would you instead open an additional coffee shop?
Suppose you designed your application with monolithic architecture in mind. In that case, you'd end up opening that second mall, as you'll likely be spinning up more servers running your complete application to handle an increase in traffic, even if that traffic is only looking for one thing. Compare that to a Microservice Architecture application; you'll only spin up servers that serve some hot and steamy Java(Script). This was a joke; please feel free to laugh.
The microservices’ promise
With microservices, we can develop independently shippable applications that are smaller, domain-focused, and easier to maintain compared to their monolithic counterparts. Each service can be built using whatever technology a team deems is best. They can also be scaled separately, minimizing redundancies.
Learn how to build NestJS Microservices with Amplication.
There is much more to say regarding microservice architecture; we haven't even touched on microservices communication, synchronous vs. asynchronous operations, potential disadvantages, and more. However, we'll pause here, as over the next few months, Amplication's VP of Research & Development, Ariel Weinberger, will be giving us a deep dive into microservices architecture. So be sure to stay tuned for that.
In the meantime, I invite you to watch our recent conversation on everything you need to know about microservices to get up to speed with this topic:
