content_image/1008504.jpg
To enable teams to self-provision without deep knowledge of the technologies, we must introduce simplified mechanisms that are based on using templates and patterns for the provisioning tasks, which ensures consistency of implementation and a governable and maintainable landscape. 

## Cloud-native infrastructure for messaging and events 

A key opportunity to simplify the deployment of messaging and event topologies is the introduction of container platforms, which you can use package the software and its configuration so that it can be deployed in a standardized way for a container orchestration platform such as K8s. As K8s skills become more ubiquitous, this approach will simplify the way that messaging and events technologies are deployed and maintained. 

Because messaging and events implicitly involve the storage of state, their deployment in containers is more subtle than that of stateless components. Therefore, we must use more complex deployment types such as the StatefulSet, and elastic scalability becomes a slightly more challenging proposition. There are still many benefits to be gained by exploring containers in this context, for example, in terms of operational consistency, portability, and more. 

## 3.3.2 Introducing messaging and event streams concepts 

At a high level, messaging and event streaming technology appear to have overlapping capabilities because they both can be used for the same core asynchronous interaction patterns. However, on a deeper review of the capabilities of each technology, it becomes clear that they achieve these patterns in different ways to serve different purposes, and it is critical to select the correct technology for the job. 

## Primary asynchronous interaction patterns 

Let’s clearly define these high-level asynchronous interaction patterns before we delve into each of the two technologies and compare their usage: 

GLYPH<SM590000> Fire and forget: A requesting application sends a message or event for processing to another application. The requesting application wants to ensure that the message or event that was sent might in the future submit another request to determine the status of the original request, but this is a separate interaction that might not be done by using messaging or events. 

By using this pattern, requesting applications can submit messages and events to be stored by the message and event server and then continue with other processing. The target application processes the message or event when it is ready to do so. 

Figure 3-18 shows the fire and forget pattern. 

<img src='content_image/1008504.jpg'>

