...
Ease of deployment Rating: Low Analysis: Depending on how you implement this pattern, deployment can become an issue, particularly for larger applica‐ tionsapplications. One small change to a component can require a redeployment of the entire application (or a large portion of the application), resulting in deployments that need to be planned, scheduled, and executed during off-hours or on weekends. As such, this pattern does not easily lend itself toward a contin‐ uous continuous delivery pipeline, further reducing the overall rating for deployment.
...
Scalability Rating: Low Analysis: Because of the trend toward tightly coupled and mon‐ olithic monolithic implementations of this pattern, applications build using this architecture pattern are generally difficult to scale. You can scale a layered architecture by splitting the layers into separate physical deployments or replicating the entire application into multiple nodes, but overall the granularity is too broad, making it expensive to scale.
...
The microkernel architecture pattern allows you to add additional application features as plug-ins to the core application, providing extensibility as well as feature sep‐ aration separation and isolation.
The core system needs to know about which plug-in modules are available and how to get to them. One common way of implementing this is through some sort of plug-in registry. This registry contains information about each plug-in module, including things like its name, data contract, and remote access protocol details (depending on how the plug-in is connected to the core system).
...
Scalability Rating: Low Analysis: Because most microkernel architecture implementa‐ tions implementations are product based and are generally smaller in size, they are implemented as single units and hence not highly scalable. Depending on how you implement the plug-in modules, you can sometimes provide scalability at the plug-in feature level, but overall this pattern is not known for producing highly scala‐ ble applications.
...
Another common approach within the microservices architecture pattern is the centralized messaging topology. This topology (illus‐ trated in Figure 4-4) is similar to the previous application RESTbased REST based topology except that instead of using REST for remote access, this topology uses a lightweight centralized message broker (e.g., ActiveMQ, HornetQ, etc.). It is vitally important when looking at this topology not to confuse it with the service-oriented architecture pattern or consider it “SOA-Lite." The lightweight message broker found in this topology does not perform any orchestration, transfor‐ mationtransformation, or complex routing; rather, it is just a lightweight transport to access remote service components.
...