Member-only story
10 Fundamental Cloud-Native Architecture Patterns
Sidecar/Sidekick, Ambassador, Scatter/Gather, BFF, Anti-Corruption Layer, CQRS, Event Sourcing, Service Mesh, Dumb-Smart Components, Unidirectional Architecture
Software Architecting might take a slightly different approach in applications that are build in cloud-native environments. These applications are extensively built in forms of microservices. Beside that, these applications should be able to run in dynamically orchestrated and containerized environments in order to take advantage of cloud computing model.
Cloud native computing is an approach in software development that utilizes cloud computing to “build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds”.
The motivation behind software architecture in cloud environment is separation of concerns, especially for modularizing software components in containers. Following patterns help to achieve this purpose.
1.Sidecar/Sidekick…
This pattern is helpful if you want to abstract away some peripheral part of your main application in different microservice. This aids to result in independence between services, breaking tightly coupled components.
Sidecar/Sidekick pattern is helpful choice if application uses a same languages and libraries and service is needed that shares the lifecycle but can be independently deployed. It would be bad decision to implement a Sidecar/Sidekick pattern to the application if resource cost of deploying sidecar service for each instance is not worth the advantage of isolation. The functionalities like logging, configuration etc. can be abstracted away to another microservice, as shown in example below. This pattern has 1:1 relation with Primary Service
2.Ambassador…
Ambassador pattern is often used to extend network abilities of existing service, especially for the cases that this service is old or complex enough to modify.
