We’ll also talk about some possible team structures that support each architecture. Here’s an easy stage
migration away from a monolithic architecture towards micro service’s.<\/p>\n\n\n\n
![\"Organization](\"https:\/\/www.devopsschool.com\/blog\/wp-content\/uploads\/2020\/09\/Organization-level-Benefits.png\")
You can see that most of the functionality is still in the monolith. However, the monolith differs out from this microservice to analyze uploaded images. One of the benefits that kind of architecture can bring is that you can begin quarantining the legacy monolith and establishing policies so that the monolith is no Lee, modified when necessary, New functionality should be built in Microservice is as much as possible. An architecture like this can often be the proving ground for whether or not a micro service’s approach would work in a given environment or given organization. It may be that only a handful of people are working on this image analysis service, while the remainder of the global Mantex large team continues to maintain the monolith as different teams conceived. A new microservice is over time. The monolith can be shrunk and eventually retired, potentially leaving something like this hub and spoke architecture, where requests to the application enter through the hub, also called an API gateway, and then get deferred out to various service is this is a relatively simple architecture and demonstrates a couple of key advantages.<\/p>\n\n\n\n First, these back End service’s functionality is aligned toe logical separations in the global Mantex business. meaning that we can concentrate domain expertise onto the teams that maintain the code that represents each domain. Next, let’s also say that the API Gateway handles authorization, which simplifies the implementation of the back and service is significant by removing the burden of authorization. Checking from those back in service is this API gateway. <\/p>\n\n\n\n A microservice in and of itself is an example of a cross-cutting concern like authorization, being isolated to concentrate expertise and simple the other portions of the architecture. The team that is responsible for the API gateway will likely be staffed differently than the back end service teams. This team needs little domain expertise. This team is primarily concerned with performance and security. This may be a place to emphasize high availability and resiliency since it’s the point at which API requests would be measured for success or failure.<\/p>\n\n\n\n Here is a different kind of micro service’s architecture, where all of It’s also common to see a situation like this where the communication mechanism between service is a hybrid where some service communicates directly with others in an R.P.C style and another communication is facilitated by the message bus. In an architecture like this, we can take advantage of the simplicity of RPC style communications in some places and larger the flexibility of message![\"\"](\"https:\/\/www.devopsschool.com\/blog\/wp-content\/uploads\/2020\/09\/even-driven-Architecture.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.devopsschool.com\/blog\/wp-content\/uploads\/2020\/09\/hybrid-Event-driven-RPC-Architecture-1024x519.png\")
<\/figure>\n\n\n\n
the microservices communicate with one another by way of a message bus passing information to one another in the form of an event. In this kind of
event-driven architecture, new service is can be brought into the architecture with a minimum of change to other services is data that passes across the
message can be observed by any service, creating opportunities to combine existing types of data in new and interesting ways. Message
buses aren’t required for micro service’s architectures, but they are common.<\/p>\n\n\n\n
bus communication, In another<\/p>\n\n\n\n