Read the first part of this article here: “Microservices: an Agile architecture — Part 1”.
Using Domain Driven Design (DDD) to create microservices
By relying on model separation offered by DDD, we can easily join the same concept at the basis of microservices. We only need to break down the business model in several parts (with the domain’s model pattern) to end up with a representation of the system that uses the same vocabulary and specifications as day-to-day reality. Visually, in the case of an online ordering application, we get a diagram like this one:
With a bit of analysis, the vision becomes clearer and each of the domain’s models happens to belong to a parent entity. In DDD vocabulary, they are called aggregates. They consist of a grouping of models that can be treated as a whole. In our example, “Order” and “Client” are domain aggregates. We can centre all operations relating to orders on the “Product” object and take for granted that its pictures and category will be well managed.
By creating a list of these aggregates and their responsibilities, the API’s entries are almost already defined and ready to be configured in the API Gateway. The goal of this gateway is to be the unique doorway for all requests. Aside from managing security with authentication and permission, it does nothing other than sending an event or redirecting toward another entry, be it on the same server or not.
Think about it for a moment, can you establish a link with certain models of your existing business domains?
For example, it is possible that business logic relative to products and catalogue is already well divided and that there are not many interconnections. This case can then be a perfect candidate to begin establishing the basis of a microservices architecture. This way, if it happens that your catalogue would be more solicited if certain additional features were added, it is easier for a team to assimilate knowledge of this specific domain and to make it evolve.
If on the contrary, the demand is too big, we can easily install another copy of the service and manage the workload on the gateway’s level. It is by tackling small pieces that we can see more clearly and make them evolve well and quickly.
Before trying, here are a few questions you should consider before you commit to using a microservices approach.
How small do microservices need to be?
This is a question only you can answer. When you plan on splitting microservices of an existing monolithic application, you need to ask yourself if your service is small enough to achieve better flexibility and Agility. If your service is crucial to the rest of the application’s operation and if there are a lot of interconnections, it might be preferable to maintain the status quo.
How can microservices evolve?
Modularizing the applications’ services distinctively by using a container technology like Docker offers a good approach for horizontal scaleability (more machines). The concept also applies to monolithic structure since this technique can be used in both cases by creating a network of services sharing the workload.
Are microservices more Agile?
With DevOps practices, containers and Domain Driven Design, microservices clearly offer better Agility and more optimal productivity. Since each component is segmented and independent, the architectural decisions can be considered for each component, instead of all of them. By having the opportunity to relay dependency management to containers, efforts to be invested in integration during development are less important.
For small and simple applications, the monolithic structure can still offer better development speed, while being as Agile.
What is the best way to deploy microservices?
If you think of an application with several services, it implies that these need to be managed properly, otherwise you quickly end up overloading the operations team. That is why it is important to be equipped with automation and instrumentation tools from the beginning (like Kubernetes). This effort can make the initial learning curve steeper and seem of little use with just a few services, but as services multiply, you can see the interest.
Are microservices more complex?
As mentioned in the previous answer, there are many more challenges involved in deploying microservices than a monolithic application. To make services independent, the team has to make sure to cover the entire lifecycle of a microservice, from coding to deployment. This appropriation can result in important organizational and configurational changes. Each microservice will require its own compilation process and a deployment mechanism supported by rapid interconnection between each service.
Are microservices causing an increase in response time?
The more microservices you have, the more chances of your users seeing repercussions on performance, caused by numerous server requests. To make sure you respect a schedule that does not influence the application’s quality, you need to always try to reduce the number of requests and if possible, execute them in parallel. If your system requires answers in real time, it might not be a good candidate for a microservices structure, unless you encapsulate the infrastructure in real time inside a microservice.
Are microservices resilient?
Keeping microservices in different processes brings a great advantage on the resilience level. Indeed, some parts can fall without affecting other processes since server resources are separated. If error management is properly developed, it is possible to simply try again if there is a problem. Pushing a little further, if there are too many errors following a deployment, we can automate a regression.
Need help?
Whether you need help with microservices or other services, at Done the expertise of our multidisciplinary teams allows us to support companies that wish to develop the skills of their development teams. To learn more about training and technical coaching, click here.
Conclusion
Microservices offer several benefits, as much to users as to developers:
- Modules are isolated so errors have fewer consequences;
- Experimentation with new technologies is less risky;
- Teaching new team members is easier.
Many big businesses like Walmart, Spotify or Amazon have turned toward microservices and obtained results going beyond their expectations. On the other hand, it is primordial to consider complexity and automation of the infrastructure to make sure not to fall in the trap of investing too much effort in the bottomless pit of deployment and configuration.
References
- Introduction to Microservices (https://www.nginx.com/blog/introduction-to-microservices/).
- The CxO Guide to Microservices (https://www.thoughtworks.com/insights/blog/cxo-guide-microservices).
- Pattern: Microservice Architecture (http://microservices.io/patterns/microservices.html).
