Even if you don't give hoot about server architecture you may find it interesting to know about how some of the biggest companies structure their back-end.
Prehistoric Monoliths
Not the giant rocks that pop-up all over the world, but the humongous rock sitting in the software of a server room.
Monolithic server architecture is a back-end built to have an entire web/app/service's UI, database, etc. all hosted together in an interconnected web. When you want to achieve a simple task, that monolithic server has to dig through the entire database and series of components that may not even be related to making that task happen.
As you may have pieced together, this is bulky and becoming more and more outdated.
Futuristic Microservices
Futuristic in the sense that we, as a tech world, are moving towards using a microservice architecture rather than a monolithic one.
The whole idea of microservices is breaking apart what could be a monolith into several hundreds and sometimes thousands of small services (hence microservice). Hundreds, even thousands of little services may sound like a crazy amount when it comes to an application or service but when looking at tech giants such as Netflix, Amazon, and Uber, it becomes pretty understandable.
Large corporations, such as Uber (with 2,200 microservices), create this back-end based on use cases. If someone wants to order a ride, Uber's back-end will spin up only the parts needed to achieve that request. This may involve running several microservices at one time (passenger UI, passenger management, billing, driver UI, driver management, notification handling, etc.) but after the request is finished and the use case has been met, those services will terminate themselves leaving room on a server for other requests.
Why?
Why are microservices worth it compared to a monolith?
The revolutionary aspects microservices provide are performance, server space and adaptability/dependability.
Performance
The performance of an application/service is dramatically improved since the back-end only needs to process a small part of the whole architecture for each request rather than digging through every bit of information to only find a few certain parts.
Server Space
Since each microservices stops running after a task has been completed, that space taken up on a server is then usable again for other tasks. This helps free up space that if used in a monolithic architecture would constantly be filled since the entire structure is always running.
Adaptability/Dependability
The two terms go hand-in-hand when in the scope of a microservice architecture. When the system is able to adapt to errors and shortages the system remains dependable. Same as if the system is dependable, it means the system is also able to adapt quickly.
This is highly prevalent when it comes to microservices since one service is able to run without the need of an unrelated service. If the first service goes down, the second is still capable of running successfully.
Monoliths, on the other hand, are not able to follow this idea since everything is interconnected. If one side of the monolith goes down due to maintenance or a crash, then the entire system crashes with it.
Video
Check out a short video using docker to explain the basic idea of containerization to deploy multiple microservices.
Top comments (0)