1. Microservices foundation
This is part one of the microservices series
The intent of the series is one for the practical aspects of microservices, however, some fundamentals need to be perused.
Microservices behoves one to take a holistic view of the computer science fundamentals and if possible dig into the history of so many of the tools that developers use, while understanding at a fundamental level why they were invented and acquiring a great sense of what the best practices are.
At its core, microservices are solving the problem of modularity. We’ve all used modularity in one form or another while using the UNIX terminal, importing modules in code or reusing objects in OOP. However, on the microservices level, the main objective is the independent deployability of modules or services.
The main objective is the independent deployability of modules or services
Loose coupling and strong cohesion
While modularity and independent deployment may be the goal of microservices, the oil that runs the machine is loose coupling. We’ve all worked on those codebases with the authentication module making calls to the payment module and notification module, with a change in one thing affecting a change in another.
The best practice is to have loose coupling between modules/services(preferably in monolith before transitioning to microservices) because, without that, all you will build is a distributed monolith.
This really starts with identifying the domain boundaries within the project and deftly extracting them, a skill that requires some practice and won’t be straightforward. Because it’s from this that you determine the number and size of microservices that you will require
Like anything in software architecture, loose coupling is a tradeoff that comes with some challenges;
- How to design separate databases for each service?
- How many and how big should the services be?
- How will the services communicate?
- How much should each service expose(interface design)?
- How will the services be tested?
Loose coupling is only one of the few principles to keep in mind while designing microservices or software for that matter.
Built around teams
To even further enforce the separation of services, each team should own their service/services, with full autonomy to build, test and deploy the service at will without breaking other services(through the use of a well-defined interface)
You cannot build microservices without CI/CD
CI/CD
As a common saying goes, You cannot build microservices without CI/CD. While this is hard to set up depending on the size and amount of resources available, the benefits are enormous. This ensures that changes can quickly and easily be rolled out, systems are not failing, as well as ensuring communication between services is not broken as this would nullify the essence of using microservices in the first place.
Well defined interfaces
While microservices encourages a polyglot mindset, the use of multiple tools, languages and techniques can also pose challenges. One needs to start by properly defining the interface(using swagger of some other tool) of each service, ensuring that the service exposes as little as possible to the outside world(to prevent coupling down the road).
To further enforce interfaces, you may employ code generators and this ensures that each service will be meekly identical. Functional programming languages like Haskell may help in writing code generators or the use of some third party tool
Conclusion
Microservices poses many challenges as well as opportunities, like anything software engineering, it's a trade-off between so many tools, techniques and principles. Hopefully, this provides the first step as you ponder how to implement microservices
