There are two popular approaches to application design – monolithic architecture or architecture that relies on microservices. Each has its benefits and drawbacks, and each is suitable for specific projects. In this series, we'll cover the topic extensively and hopefully shine a light on the matter.
Look before you leap. This old saying sums up what you should do in the initial stage of any project – plan, outline, and research. Become familiar with all the context and describe the application's required functionality and available resources you'll need along the way. Strong foundations will help you build a scalable, robust, and extendable service.
The initial stage in the context discovery process contains functional requirements or specifications of what the app should offer to end-users. Elaborate on the following, and you'll get excellent areas to start with:
Secondly, you should review the resources that will help you with the project's implementation. Start with the following:
With a clear grasp of functional needs and available resources, choosing between monolithic and microservice-based designs may be a lot easier. The engineering team must choose the best application architecture before a company can design a product. As we mentioned, there are two main models – monoliths and microservices. Whatever approach you choose, keep in mind that the goal is to create an app that provides value to consumers and is easily adaptable to new features.
In addition, each architecture encapsulates an application's three primary tires:
In a monolithic architecture, application tiers share the following characteristic:
Let's imagine that team uses a monolithic approach to create a booking application. How is the app going to look?
The user interface is the website with which the user interacts. The code that offers features like search, booking, payment, and so on is part of the business logic. All components are stored in a single repository and written in a single programming language (e.g., Java or Go). The data layer includes functions for storing and retrieving customer information. All these components are handled as a single unit, and the release is accomplished with only one binary.
In a microservice architecture, application tiers are managed separately as stand-alone components, and they share the following characteristic:
Let's return to our example with the booking application. How is it going to differ if the team chooses microservice architecture over a monolithic one?
The user interface stays the same. It's still a website with which user interacts. On the other hand, the business logic is broken down into smaller, self-contained pieces such as login, payment, confirmation, etc. These units have their repositories, and their programming language can differ (e.g., Go for the payment service and Python for login service). Each unit has a defined API for interacting with other services. Finally, the data layer includes methods for storing and retrieving customer and order information. Each unit is released using its binary, as planned.
Monolith: Application design where all application tiers are managed as a single unit.
Microservices: Application design where application tiers are managed as independent, smaller units.
Alright, we covered the main differences between monoliths and microservices. In the upcoming part II., we'll discuss the pros and cons of each approach.
Reach out to get more information.
Artyom, sr. software engineer