The choice between Monolith, Microservices or Serverless architecture is one of the most crucial first steps in any contemporary application development process. This decision will go a long way to defining the app’s future. In todays post, we look at all three types of architecture and their strengths, weaknesses and scenarios to which they can be applied.
These days, a monolithic architecture is a kind of ‘a black sheep’ in the modern IT world. But is it fair? To tell the truth, yes but no. There are obvious reasons why you can safely choose the monolithic architecture as well as why not.
-Appropriate for small applications. If your app is not big and you have little time for development, then your best choice is the monolithic architecture.
-Convenient testing and production processes. You can start and test an application on the developer’s computer and apply a standard deployment process to check on changes before putting it into production.
-Horizontal scaling. It’s possible to scale horizontally by starting several physical servers after a load balancer.
–Straightforward transaction controls and data integrity. Since monolithic applications usually use a single database for storage, they benefit a lot from straightforward transaction controls and different mechanisms of the data integrity maintain provided by the RDBMS.
–Simple infrastructure. Here, we have a single server for multiple things at once: front-end, back-end, and database. It will come as no surprise that monitoring in this case is performed more easily.
Disadvantages of Monolithic Architecture
–A single structure. Any changes will lead to the rebuild and deployment of the whole monolith.
–Hardly keeps the good modular structure. The changes in the logic of a module tend to affect other modules’ codes.
–Limited opportunities. When dealing with monolithic architecture, you’re bound to some common technology, which was chosen for the application at the very beginning. It results in a specific work organization: all specialists must literally sit back-to-back to each other in order to communicate effectively. However, they as well as certain parts of functionality could benefit from using different technologies a lot.
–Tight coupling and low cohesion. If you need to change one component, there is no way to make it instantly because the logic is spread through the whole app, thus, every part of the app has to be thoroughly tested even if not all components were changed, because it would be hard to predict what implication even a small change could cause with a tightly coupled code.
The main problem of monolithic architecture is that it’s not flexible enough for this fast-pacing world. The businesspersons whose applications are built according to the described approach are struggling a lot today. The only decision is to change everything in order to stay afloat and remain competitive.
At K&C, we’ve faced such a challenge. It was a web-application developed as a kind of a Liferay Portal. It had been in development for a long time (mainly in free form) and eventually it became clear that it made no sense to proceed further in this way.
So, the dedicated K&C team started the process by dividing the app into separate modules. We did not use OSGI, but we tried to divide the app into modules just inside the Liferay. As a matter of fact, this division was our first step towards the whole separation. And just after that, we began dividing the application into microservices.
Now let’s divide your monolithic app into microservices too!
1.Take your web-application;
2.According to the principle of bounded context, divide your monolithic app into ‘building blocks’;
3.Divide your app into modules;
4.Turn your modules into separate microservices.
Sounds easy 😉 But if you do have any uncertanties or need additional support you can contact the K&C agile development team for consultancy or development capacity.
When talking about microservice architecture, the easiest thing to do is to highlight its pros.
–Steady development. There is no need to write the whole app at once. Instead, development can be performed gradually.
–Flexible development. This means you can hire several teams and each will work with its own service.
–Dynamic lifecycle. This implies that you can launch and develop the app in a prompt manner.
–Unlimited technological potential. Compared to a monolithic approach, you can use any languages, any frameworks, and any technologies while developing an application.
–Unlimited scaling potential. A developer is able to independently scale the different parts of application.
–Communication. Remote calls are slower than the calls in the frames of a process; that is why the API must be coarser-grained.
–Application unavailability. The consequence of using microservices is the need to create an app so that they can function even if specific services fail to work. The problem is that any invoke to the service may malfunction because of its unavailability.
–Complicated infrastructure. There are many moving parts.That challenges developers to monitor all of them more carefully in order to maintain and manage the infrastructure effectively.
–Intricate transaction management and data consistency trade-offs. One of the major issues is the way transactions work when they span over different services. It’s assumed that the solution is in the distributed transaction approach or custom-made transaction manager, yet they both can come with other issues (e.g., deadlocks and data inconsistency). In some cases, we must rely on the eventual consistency approach. This means that instead of a strict boundary when the system is in the consistent state straight after the transaction is fixed, we allow our system to reach that state at some point in the future when some processes on the backend will have successfully cleaned up the inconsistency.
The only condition while working with microservices is that all services must work in a single environment – services have to be able to communicate with each other. This can be realized, for example, with the help of Kubernetes.
How the K&C agile development team approached the problem. Our decision is based on the framework Spring Cloud Netflix. It lets us integrate various applications built upon the Spring Boot framework. However, you can choose whatever you like. It can be NodeJS, Python, or what you are used to working with.
A Serverless approach would harnass the evolution of Cloud computing that goes beyond Microservices. In this type of architecture, we’re talking not about a set of services or functional modules but a set of functions that live their life and have their life cycle, beginning from deployment and ending with the approaches to scalability.
Is the architecture good or bad? Let’s look at its most significant pluses and minuses.
–Lightweight mechanism of functioning. This type allows the creation and running of the app and services without the necessity to manage infrastructure.
–Infrastructure. The whole infrastructure is maintained by an outside provider and needed functionality is provided in the form of services, which are responsible for the processes of authentication, message transfer and so on.
–This perfect for arranging business logic; especially when there are some functions that we need to bind as an asynchronous data stream. Moreover, we don’t have to include them into our application because the functions are based on a host platform of the application.
–An insufficient set of functions. Thus, we can’t build substantial chains of functions. This leads, in turn, to the complication of architecture and infrastructure, as far as it’s somewhat tricky to make so many separate modules interact.
–Tight coupling among all the functions. This results in the same problem as monolithic architecture.
However, today we can observe that many modern applications benefit from the serverless approach. It’s convenient, easy, and pleasant.
If Serverless sounds like the best solution for your next app, just drop us a line. K&C’s experienced Serverless development team will be delighted to offer you an
It’s safe to say that the days of a monolithic architecture are fading. The monolith is appropriate only for a very small application, if at all. Although even in this case, there is the possibility to face numerous problems in the future. With this, such type of architecture belongs in the past as well as SOA technologies.
Considering the microservice and serverless architectures, or let’s name it more accurately ‘function as service’, they both are auspicious technologies. Most likely, the future lies with a mix of these two approaches – when part of the functionality is represented in the form of microservices, and another is in the form of serverless functions that are deployed in a host environment or cloud technologies.
For the K&C team, the future lies with self-improvement. We invest in our developers to keep them uptodate with the latest tech stacks. It’s the only way we can guarantee optimal execution of your projects.