Table of Contents
Here at Apiumhub, we always help our clients build solutions that are complex in multiple areas and our primary work is to define a software architecture adapted to their needs. Software architecture doesn’t only search about technical requirements like scalability, performance or reliability. That’s the easiest part. We also need to take into account what is already done (and paid), what is the cost of developing new parts of the software and the price of having that software on production. Not meeting these requirements may cause the endemic project to close. Let’s talk about micro services!
WHAT IS A MICRO SERVICES ARCHITECTURE?
Classic Micro services Architecture
Nowadays a big community found a new architecture that seems the panacea of software architecture. It’s called Micro service Oriented Architecture.
The main idea of Micro service Oriented Software is that the software is bundled in a group of little applications that send messages between them to do the work. Every part of this software is called a “physical Micro service”.
A single physical Microservice is very cheap because it’s a little piece of software that is easy to distribute. But a common fallacy is that, a Microservice doesn’t require strict tests because it’s that small that you can rewrite it when needed. Here people forget about the principle of “fast feedback” that you solve with TDD.
Microservices Architecture with a Queue
Nevertheless, a growing Micro service Architecture is very expensive because it breaks the following criteria about software architecture.
- Don’t over architecturize your solution. Having a complex architecture means a greater cost in production and development that you probably can’t afford.
- The major part of your software components need to scale under the same conditions; having them as different pieces make the deployment harder.
- Development is slower because you need to take into account service transactionality and communication and not only on your business logic.
Here we need to apply our agile process: Red Bar, Green Bar and then Refactor.
HOW TO GET FAST FEEDBACK
In software development, the first thing you need to do is a research on how to get fast feedback of the development. With our current knowledge base, we found that the fastest way is with a monolithic piece software in continuous integration with a high and solid test base. Once we have feedback and that the client is happy, we can refactor to accomplish our technical requirements if they are not satisfied. It’s no surprise that almost all the projects with a basic architecture work well and that the client doesn’t need anything else.
But we need a complex architecture, we need to refactor our solution.
WHAT DOES REFACTOR MEAN?
Probably we think about taking duplicated code and putting it under test in a new module.
But in software architecture we need to refactor when the monolith that we are developing is so big that it starts to be expensive to handle. When that happens (and we have fast feedback that says when we do something wrong), we can take our part of the application and put it as a new piece of software that is going to be deployed its own way.
Need to answer these questions
The question is, how do we split our software? Where do we put the knife and cut two pieces of the cake? The solution to this problem is called Domain Driven Design because applying those guidelines (they are only guidelines, not rules) you will likely have it easy because we have those layers already, though.
What does the model of DDD do? It does the domain logic, simply that.
What does the repository do? Persist the state of our solution.
What does the domain service solve? It manages the change of our domain and the coherence.
What does the application service do? It manages the transactionality between domain services and the coherence between them. For example, the owner of a “Post” needs to exist in the “User” domain.
At this point, for coherence, we can cut on the domain service or on the application service. But splitting on the domain service is a very bad idea, because handling the transactionality between domains is very hard if you need to take into account network problems, queue handling and data corruption.
So the best way is to cut on the application service, and it makes sense.
Why? Because the application service already handles that coherence between domains. If one message arrives to the application service, but the next doesn’t, you know that the data is not corrupted because its coherence is already handled by the service in an atomic operation. You can temporarily lose the coherence (having a queue system lets you enqueue the operation and dispatch it later) but your data is going to be OK.
That’s encapsulation. We have pieces of software that are independent, so we can use them the way we want without temporary coupling or without client composition. If we have a client that only adds posts, he is going to work with the Blog application service without doing anything weird.
So yes, Micro services are nothing new. I always developed Micro services with DDD, but they were logic Microservices, that’s the way to go. And of course, Microservices are a very good idea because it’s just another way to do a Service Oriented Architecture right.
If you can use technologies like AKKA that let you publish actors remotely on other machines having all the code in a monolith, don’t think about it, just do it. It’s easier, decoupled, stateless and easy to deploy.
However if you don’t have access to those technologies, before deploying different Micro services, remember that deploying the entire monolith is expensive, because most of the times it’s better to deploy the entire solution in different machines for reliability. Also, deploying today a monolith with technologies like Docker is easy and fun, so we can spend some resources on disk or memory, but they are cheaper than development, maintenance or software evolution costs. We need to focus on our solution, which is where the money comes from.
