Data in Microservices Architecture — Introduction
This post is the first part of Data in Microservices architecture series that will not talk about concerns that are usually present in a discussion about microservices such as configuration management, service discovery or load balancing. We will bring your attention on the data. A critical part of a system that often barely involved when discussing microservices.
Why Microservices?
Even though the term “microservices” has been around since 2011, the surrounding discussion never gets old. Many organisations, as they learn the benefit for their business, identify their need to adopt microservices into their software development technique. Technology like Kubernetes boost the adoption momentum even further as it addresses many microservices implementation concerns.
The feedback loop is an important process in human development, so does for software. As with everything we do in life, the longer the feedback loop, the worse the results are. Before we have real time syntax highlighting in our Integrated Development Environment (IDE), we should compile our code to check if the syntax was correct. Before automated testing tools, we have to wait for the tester team to inform us if our works broke anything. These are some examples of how reducing the lead time generated better results in the software development process.
One of the improvement areas for the feedback loop is microservices. Another one that tightly related with microservices is DevOps. If you are new to microservices, we recommend you to start with DevOps. Let us give you a short introduction.
DevOps
We need the DevOps team, which objective is to make the entire teams of software development fully own their work, both on the Developer (Dev) and Operations (Ops) side.
They must be responsible for the outcomes of the application. This responsibility is rather to fulfill a common expectation that every business build: a software release with no bugs.
But just like Thanos, bugs are inevitable.
Changes introduced, both in code and environment, cause bugs. And changes is a certainty in a growing business. So what more realistic as the outcomes from a software development team is a release with fewer bugs. Because changes causes bugs, so that smaller changes should introduce fewer bugs. Smaller changes also make it easier to spot the source of bugs. Therefore, it should be easier to fix them.
DevOps is a combination of culture, processes and tools that enable an organisation to release software faster. The sooner we release the feature, the faster feedback acquired. To deliver it faster, organisation must reduce the size of the changes in each release.
And remember, smaller changes lead to fewer bugs.
To deliver the software with fewer bugs, organisation need an automated software deployment pipeline. Ranging from the code repository run through to the production infrastructure.
Why microservices?
Scalability is one of the reasons why you want to adopt microservices. Another reason is regarding to decreasing our lead time and reducing the changes of software releases. Currently Ralali.com ultimately adopt the second reason.
By adopting this system, we split a monolithic codebase into a smaller loosely coupled part, colloquially known as microservice. Each part will have a separate service functionality. Because those microservices is loosely coupled, we release them gradually. By doing that, we improve our lead time and change size of the feature.
How to start microservices?
In his article on monolith-first approach, Martin Fowler suggests that you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile.
That approach requires you to have a stable monolith. This will help you define boundaries between the domain model. Wrong boundaries will force you to deal with cascading changes and bugs. There is even a name for the pattern: strangler pattern. Basically, you would start small with microservices and grow around a monolith.
How to choose we should split which part of the monolith out as a microservice? This is where Domain-Driven Design comes handy.
Domain-Driven Design
Domain-Driven Design (DDD) is an approach to software development that tackles complex systems by mapping activities, tasks, events, and data from a business domain to software artifacts (in our context: microservices).
Failure in splitting a piece of a monolith will lead us to have a microservice that depends too much on information confined in another microservice. Worse, this also could force us to synchronize changes from a microservice to another microservice.
Having a stable monolith will help us decide the bounded contexts of our domain model. This is essential because we should have mature knowledge around our business domain model first.
What is a domain model?
Things that are grouped together and achieve high cohesion and low coupling. When you just develop a software system for your business, it is hard to define which of the system changes together and which one’s change separately.
Microservices characteristics
Martin Fowler suggested a common set of characteristics of the microservices architectures. Each characteristic worth its own explanations. Since we have told you about how data should be managed in microservices architecture in this article, so the next big thing about single characteristic that we will discuss is: why each microservices should have its own database.
If you enjoy this post and want to be part of the Ralali.com Engineering team building the data management in the microservices architecture as part of the mission to empower MSMEs and people in Indonesia, why don’t you visit our Career page and see where you can fit.
