Even if certain technologies for implementing the demands on microservices are rigidly defined, it will still be possible to integrate other technologies. Therefore, the concept of a sidecar can be very useful. This is a process that integrates into the microservices-based architecture via standard technologies and offers an interface that enables another process to use these features. This process can be implemented in an entirely different technology so that the technology freedom is preserved. Figure 7.12 illustrates this concept: The sidecar uses standard technologies and renders them accessible for another microservice in an optional technology. The sidecar is an independent process and therefore can be called for instance via REST so that microservices in arbitrary technologies can use the sidecar. Section 13.12 shows a concrete example for a sidecar.
Figure 7.12 A Sidecar Renders All Standard Technologies Accessible via a Simple Interface
Also, with this approach such microservices can be integrated into the architecture whose technological approach otherwise would exclude the use of the general technical basis for configuration, Service Discovery and security, as the client component is not available for the entire technology.
In some regards the definition of the technology stack also affects other fields. The definition of technologies across all microservices also affects the organization or can be the product of a certain organization (see Chapter 12, “Organizational Effects of a Microservices-Based Architecture”).
Try and Experiment
- • A microservices-based architecture is supposed to be defined.
- • Which technical aspects could it comprise?
- • Which aspects would you prescribe to the teams? Why?
- • Which aspects should the teams decide on their own? Why?
In the end, the question is how much freedom you allow the teams to have. There are numerous possibilities, ranging from complete freedom up to the prescription of practically all aspects. However, some areas can only be centrally defined—the communication protocols, for example. Section 12.3 discusses in more detail who should make which decisions in a microservice-based project.