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.  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.  Cloud-native infrastructure for messaging and events 3.3.2 Introducing messaging and event streams concepts Primary asynchronous interaction patterns 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.  Let’s clearly define these high-level asynchronous interaction patterns before we delve into  each of the two technologies and compare their usage: 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.  Figure 3-18 Fire and forget pattern 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. Chapter 3. Agile integration: Capability perspectives  69 3 U R G X F H U & R Q V X P H U