Application architecture is always judged on two things: efficiency and scalability. If your application is difficult to build out, then that is a sign that there was not enough experience to properly guide decisions early on. Not to say younger engineers can’t figure things out, it’s just that quality architecture takes experience in building you can’t shortcut. However, there are some industry-defined standards that help us out.
On the backend side specifically, we have microservices. This type of architecture employs combining a multitude of separate server applications running on the same location, while each being accessible from a sub path of the same root. This reduces the issues you’ll find commonly in a monolithic approach, and more or less, greatly improve overall uptime. Since we know the benefits, let’s do a dive into how we make it work.
Technologies
Docker
Docker is software that allows for applications to be packaged into isolated containers. These containers are a combination of your application code and the required OS libriaries and setup needed presented into a standarized executable. This said executable then should be able to run in any enviorment becaue all it needs is interal to itself.
Nginx
Similar to Apache, Nginx is used to serve and direct our applications through specific sub paths at root domain of the container. In more complete terms, it is used for the web server layer as a reverse proxy, load balancer, and/or HTTP cache.
Database
This is dependent on your own stack. The database layer that communicates as your data storage should be one instance. It will have several connections present for each of the applications running in your container.
Applications
This is where your source code for the actual application lives. It can be as many as you need to build out your complete application. Nothing too much needed outside of that should need to be said becuase you should know how to build and serve the BE application you build.
When It Doesn’t Make Sense
We have a good idea on the benefits of a micoroservice architecture, but that doesn’t mean that their aren’t other options for different situations. Highlighting an example, a small application has no need to be architected thorugh microservices. Using Docker may be present, that’s becoming more of a standard, but the other infrastructure would be overkill. To add more context, here are some more platforms that wouldn’t be suitable:
- Blogs
- Brochure Sites
- Landing Pages
- Microsites
- Etc.
The theme there is definatly revolving around smaller sites that don’t require much, and aren’t meant to get but so big.
In Closing
Microservices for those that haven’t experienced them can be intimitating to begin with. In truth, while the need for this architecture approach in the applications we consume is growing, the majority of professional engineers probably won’t need to do this for the most part. However, still having the understanding of them is important because that allows you to have context in deciding the best architecture for whatever you build.