This article is intended for developers and software architects from any platform, as a matter of fact, this is not a direct code-related topic, this is an architectural concept that is not related to any specific technology, we can say that this is the way for building and prototyping software products differently than the ways that were done (and still do!).
Software nowadays demands better code with speed record delivery time in order to achieve and test software to solve complex problems.
Years ago the called Monolithic architecture became the “traditional” software approach, this architecture stated a “ Whole in One” kind of project, where the UI, the business logic, the Data Access (or Databases) were presented in a single block with not-so flexible configurations, tech-dependent, and prone to errors if is not well written, or stated in programming design patterns and best practices.
On the other hand, let’s say that Microservices is a new way of building modern software.
This concept empathizes on generating small and autonomous services that can work together in order to generate independent and unique responsibilities using the Single Responsibility Principle.
Microservices presents a new approach for building software, that tries to resolve Monolithics approach, actually tries to split a monolith into many parts and connect it.
In order to create robust products in software, we need to cover a lot of items, like authentication, user management, orders, and products handling, etc. So, we can imagine each element as a Microservice, that works independently and usually should handle its own database.
Let’s stop this for a minute, before going into the Microservices features in-depth, we need to talk a little bit about the working background of IT and software today.
IT labor yesterday and today
So, for delivering software, the IT and coding teams from a company (from the very starting point) need to buy hardware, configure them, install services and software applications, and then start working on the business requirements and continuously generate features for been relevant in the market. Sadly, this does not work anymore because software demands quick features releases and changes.
At this point, we have clear that this Monolith vs Microservices is a never-ending comparison but it will depend strictly on the size of the project. before going to the pros and cons, this IT background brings tons of tools for handling the development cycle from the coding phase to the last deployment detail.
The following terms have a particular approach to Microservices in a certain way, consider it as mandatory category elements needed to create a good Microservices environment.
SOA (Service-oriented architecture)
This architecture approach establishes a comparison with Microservices in a theoretical way, the most focused on the communications between services than breaking logic responsibilities. This actually has been around for more than 10 years.
This particular architecture is not a mandatory element for Microservices but there’s a lot of systems that are built focused on this way to distributing features. Microservices (in my opinion) rescue some features of SOA but is focused on real-life uses.
This approach specifies a domain logic as first place.
You can find a pretty good article for this here
Refers to a simple software delivery in short cycles that software can deliver anytime
Containerization & Docker
This focuses on approach when developers act together for handling dependencies, by avoiding broken local environments and generating isolated sandboxes
100% deployment duty, this is related to cloud operations, basically, this will help on provisioning new infrastructure rapidly with a few lines of code, using tools like Chef or Puppet
This goes toe-to-toe with coding operations because helps ensure high-quality releases, automating tests, code versioning, and deployment in single actions.
Enough theory, let’s explains the advantages and disadvantages of implementing Microservices
- Agility: the server application is a set of small services which contains small pieces of software. This helps on build, deploy and test independently which represent faster iteration cycles upon users feedback or bug fixes.
- Technology heterogeneity: with this, we can adopt new technology quickly, there’s no dependency between different programming languages for any microservice. We can make use of different technologies.
- Resilience: simple, if one service instance fails (can happen, btw) is not that catastrophic. Failure doesn’t cascade.
- Scaling: on Monolithic architecture, the scaling must be out as a unit, so you need to decide to do it or not. Microservices can scale-out independently, of course, this represents more control on how to scale application and control costs more effectively.
- Deployment: Microservices can be deployed independently but Monolithic developments are deployed as one big piece. Deploy is easy and simple compared and more when you apply DevOps strategies.
- Composability: this consists of well-defined interfaces, using a Single responsibility principle we can create an application by composing of existing microservices. Codeless applications: popular approach for composability.
- Replaceability: Switch from one dependency to another. Switch from one version of dependency to another (bug fixes and performance) this concludes on rolling migration rather than big coding replace.
This disruptive way of building software represents the complexity of distributed systems, the automation process is recommended on deploy, code generation, testing suite, etc.
On the other side, the presence of multiple databases and transactions generates a simple question: How to handle distributed transactions across databases?
Don’t forget testing, testing distributed systems with dependencies is not quite simple.
And finally, from Monolith to Microservices
Let’s grab a monolith E-commerce as a system example and let’s split it into a Microservices system
Starting from a Monolith Application which has Databases, Data access controls, Business logic, and the UI interfaces we need to set a strategy context based on DDD, UI separations and databases replications (schemas).
The resulting Microservices are:
- Catalog: contains products
- Sales: responsible for orders, shipping, payments and related.
- Customers: evidence, activity logs, CRM activities.
- Content Management: news, posts, comments, reviews, etc.
- Configurations: system settings, currencies
- Reports: sales statistics
What can conclude from this?
- For small projects, Monolith can work very well
- The simple fact of splitting a robust project into Microservices can lead to independent scaling but the complexity grows
- Most of the techniques applied to the Microservices creation and deployment process are very good practices in general software, actually, some of them can work easily on Monolith applications.
- Simple, Microservices can deliver software faster.
To join our community Slack 🗣️ and read our weekly Faun topics 🗞️, click here⬇