Orchestration Pattern
Perspectives to keep in mind when working with microservices on your projects and products —
Here at Grupo Boticário we truly believe in the benefits of writing APIs to every functionality that your software provides, but that doesn’t mean the APIs will be created at will, we need some patterns and control points. In this series of articles about microservices architecture, we will go over a few basic concepts to help you on your journey!
When we design and develop software with an API centric approach, you should begin mapping all of the needed interactions with your domain, to then begin the development of APIs that will serve such interactions. Only then you begin thinking of a user interface.
This is rather a very popular approach already embraced by the development community, as there are a lot of benefits to it:
- Faster development (not necessarily from the product delivery perspective).
- Technology agnostic between components.
- Easier understanding.
- Monitoring and tracing become much simpler, if you have the right tools. If you don’t, it gets a little bit more complicated, but that’s a topic for a future post.
- Easier testing.
- Integration readiness.
In practice
Taking the API first approach, I wanted to go over some tips on how to leverage that on a digital product.Assuming your digital product is being developed following an agile approach, such as the Scrum sprint cycle or PDCA cycle (Plan-Do-Check-Act), you will work through an iterative process with incremental changes.
The first delivery should look like something like this:
After a few iterations, your product will grow with additional services:
With a product built with a microservices architecture, the main goal of maintaining the loose coupling pattern (micro services architecture patterns) gets harder and harder. With the ever increasing number of services, developers and teams, both technical and administratives challenges grow proportionally.
Growth is good, but it comes with its own challenges.
As your product grows with functionalities, exposing such functionalities to other consumers will take its toll. Keeping different endpoints and API contracts up to date will require a significant effort from the team owning the services. The orchestrator pattern comes in handy, as this new service will orchestrate all of the calls among your existing services.
It also provides some soft benefits, such as better organization, simpler user interfaces and ease of use for external consumers.
With this quick introduction to orchestration pattern, you can see how this is a good approach for the majority of projects and products designed with a microservices architecture.
When we get to a corporate level, chaos can reign:
What can you do to control such chaos? Well, the answer is choreography pattern! Which we will talk a little bit more in our next article, right here at Medium!
Stay tuned and let us know what you think of these patterns in the comments section!
Glad to share and co-auth this article with Marcus Machado.
References
