Topic: Software Design Level: Intermediate
Decomposition Patterns - What?
Breaking down the architectural design with respect to a defined context
1. Strangler Pattern
Extracting a specific functional component from the application into an independent service component, then an intermediary facade is placed for routing the request traffic in tandem to both the legacy (for facilitating the functionality that is still not extracted) and the new component (for conducting the migrated functionality), and upon correctness completely decommissioning the functionality from the legacy design (by which strangling the primary application by component elimination).
Thereby gradually and iteratively, achieving a microservice design transformation by decoupling the functionality.
Eliminates complete big-bang migration risk.
At a high-level overview, the Strangler pattern is developed in the below stages,
- Transform - Extract and develop the new independent component
- Co-Exist - Application to host both the legacy and new component
- Eliminate - Decommission the legacy component for the new component alternate
Image Source: https://microservices.io/patterns/refactoring/strangler-application.html, as time lapses the monolith is decomposed into multiple microservices (strangling the monolith by replacing its functionality from the microservice)
Attributes of the ideal component for extraction are,
- Simple independent in operation
- Comprehensive test coverage and negligible technical debt
- Cloud compatible with scalability specifications
- Subject to frequent business adaptations with momentary release cycles
2. Bulkhead Pattern
The term bulkhead originates from naval engineering, which is a structured barrier partitioning the quarters of the ship, restricting cascaded failure propagation and providing fault isolation within the barricaded section.
Following a similar fault tolerant design strategy in software engineering, for distributed systems with failure confinement that guarantees the application service availability without any downtime is a Bulkhead pattern.
The service boundary serves as a bulkhead to isolate any failures. Breaking out functionality into separate services isolates the effect of failure in the service itself. But this isolation is not enough because our services consume each other. Excessive load or failure in service will impact all consumers of the service
For instance, in our RideAvailabilityService, we check the geological region for available vehicles to facilitate a ride service. RideAvailabilityService depends to 3rd party location identifier APIs, FeeEstimateCalculatorService, and RiderTripManagementService to fetch us the details of available rides with fees in our locality.
However, if the location identifier APIs (or) RiderTripManagementService is down or not able to accommodate the user request, then we would have an inconsistency in determining the ride availability.
An organizational case where RiderTripManagementService is unable to facilitate requests and failure cascades through the Application; solution re-route requests to standby services or confine the error propagation
This situation can be addressed with the Bulkhead design pattern by either providing a default fall-back case (the circuit breaker pattern) or re-route the requests to a standby load-balanced service.
3. Sidecar Pattern
The analogy of a motorcycle having a sidecar which attributes to off-load (or) abstracts away a few of the supporting value add-on functionality and co-exists by sharing the identical lifecycle to the bound parent.
In a relevant context, a sidecar for a microservice application is one that provides additional functionalities like cross-cutting concerns ie., monitoring, logging, configuration, caching, proxy redirects, auditing and network services that run alongside augmenting the primary application instance.
Wherever the primary application goes so does the auxiliary follows utilizing the same host resources while being cohesive, and continuing to function appropriately even when the primary encounters problems.
Image source: https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
Sidecars are decoupled and independent components and are often used as a plug-and-play utility complementing the required services without demanding additional host infrastructural capabilities other than what the primary mandates.
Disclaimer:
This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual. All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Downloadable Files and Images
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
- Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to :
- Comments deemed to be spam or questionable spam.
- Comments including profanity.
- Comments containing language or concepts that could be deemed offensive.
- Comments containing hate speech, credible threats, or direct attacks on an individual or group.
The blog owner is not responsible for the content in the comments.
This blog disclaimer is subject to change at any time.
Comments
Post a Comment