Date: 2020/08/31
by Migal Lewis
Our Architecture
At Omnipresent Global (Pty) we follow a Microservice application architecture, because its benefits outweigh the benefits of a Monolithic structure. We depart from the Monolithic philosophy as Microservices allow for more efficient use of time, and assist in producing maintainable, quality code. However, that is not to say these benefits cannot be achieved with a Monolithic structure, instead, it is a lot easier to achieve these goals in a Microservice architecture. In this article, we will briefly explore the reasons why Microservices are a more suitable project architecture for large scale projects.
Understanding Microservice and Monolithic
A Monolithic application is an application with many business features in a single project. This is the traditional way of programming and has been used in numerous large organizations for many years. Therefore a Monolithic application size increases based on features, as more features are added, the larger the project will become.
A Microservice, however, is an independently deployed component of bonded scope that supports interoperability through message based communication. Microservice architecture is a style of engineering highly automated, evolvable software systems made up of smaller, capability aligned microservices.
Microservice Characteristics
Small in size
Microservices are quite small making it more maintainable, as developers would find it easier to understand. For example, if a project with 5000 lines of code was compared to one with 100000 lines of code, the project with 5000 would be a lot easier to read and debug through. As a result, smaller codebases enable reviewers to spot standards that need to be adhered to in a much quicker fashion. In a practical context, when you give a Microservice-type project to a new hire or team member, they won't be as overwhelmed as when you give them a monolithic application.
Faster
A microservice application starts a lot quicker. This might seem insignificant but having a project start in 3 seconds and being able to make changes and restarting and waiting another 3 seconds is far better than waiting for 2 or more minutes for a large monolithic application to restart. These numbers add up- time is valuable.
Using multiple languages
Some languages are better suited for certain projects, and microservices allow various languages to work together seamlessly. For instance, Python is currently the most preferred language for Machine Learning tasks and Java for RESTful APIs based on what software development communities drive. Microservices can allow you to use Python libraries for your machine learning, expose it as a Microservice and then communicate to a Java-based service, allowing developers to use the best languages for particular tasks, with minimal integration work.
Loosely coupled
The fact that a microservice focuses on one business capability it allows it to be loosely coupled which brings great advantages in downtime. In a hypothetical scenario, assume that you have a monolithic application, and you just pushed a couple of brand-new features. These features went through all the necessary testing but something was missed and one of the features is causing issues in your live deployment because of a bug or some undesired behavior. You would be forced to roll back your entire application until you fix the bug, however, this would mean all the other new features, that were working fine, have to be rolled back as well. In microservices, your business capabilities are separated so if you had a scenario like this you would only need to roll back the specific feature and the rest can still remain in the live environment.
Flexible Scaling
Scaling is something that every program, that has many users, needs. It is not only easier to scale a microservice, but it also grants flexibility in scaling. To illustrate this, assume that you have 3 microservices, called A, B and C. A is called constantly, while B gets called every now and then, and C is called often, but only at later hours. In this scenario, Service A could be scaled to have a lot more memory and CPU to manage the higher traffic, and service C could also be scaled to have more memory and CPU power, but only when it gets to late hours. This type of independent, flexible scaling will not be easy to achieve with a monolithic application.