Microservices: Design patterns
This is the first part of series on microservices design patterns
Microservices are like a hot cake today, most organizations are shifting monolithic applications to microservices. This involves a lot of refactoring efforts, testing, and releases.
With so many resources and costs being incurred, it's important to do it the right way. The services being developed should be scalable, independently deployable, testable, resilient, loosely coupled, and performant.
To build Microservices the right way, let us look at some of the important design patterns that help us create better services and migrate existing monoliths to microservices.
Strangler fig pattern
This pattern is used to phase out the existing legacy systems for newer applications. The pattern is so named because the behavior is similar to a strangler fig tree, that starts on a host tree and then totally encompasses it, strangulating the host to death.
While migrating the legacy apps to microservices it is important to consider that not all features can be migrated at once. Migration is a continuous incremental development process.
A certain amount of traffic would have to migrate first followed by others. the migration can be basis features or sometimes just a user-targeted migration, something like a beta release for model users before a mass rollout.
This phased rollout ensures the business is not impacted, while new/selected users are redirected to the new applications, other users continue to use the legacy apps.
It is important to note that the new applications would also be called legacy applications in some years, hence they must be created in a way to ease the migration to future development.
Points to consider
This pattern can be used when trying to migrate legacy applications to the new architecture.
This can also be used for piloting users on some new feature without impacting other users.
This pattern may not be suitable for fairly simple applications that do not have much complexity or features.
Downstream applications or backing services like databases, message brokers, or other services being consumed by these might have to be shared, but it would be good to build independently.
If you like this article, please support me by following me, liking it. Would also love to have feedback on this article. You can follow me on Twitter where I tweet on various subjects including development, architecture, and best practices.