Following the example of Envoy / Service Mesh

Taking a deeper look at the sidecar pattern and how Envoy enables the k8's ecosystem to provide cross-cutting concerns like tracing and security, the question is then : Can this pattern be used for other cross-cutting concerns?

I think the answer is yes.   The Envoy / Sidecar pattern clearly shows that by extracting cross cutting concerns out of the application you can achieve greater flexibility and power.  To me, this is one of the main takeaways from the Service Mesh.

The sidecar pattern enables your apps to focus on business logic while the infrastructure sidecar components provide the cross cutting concerns.

It seems clear that the operator framework is in the perfect position to allow developers to exploit this pattern.  Cross cutting concerns like service replication (scaling at aggregate level) and data locality can now be addressed by simpler solutions.   You don't need to bake crosscutting concerns into your application

It seems like history repeats itself.  What made the Spring Framework so successful was that it was built on 3 cores principles.

Kubernetes is providing similar capabilities at a lower level. 

Dependency injection:  Operators can assemble graphs of objects in K8's, similar to how the applicationContext is built in Spring

AOP:  Cross cutting concerns can be abstracted into Sidecars

Portable Service Abstractions:  Just like Spring has many canned features like the JDBCTemplate that standardize the flow of operations.  Similar structures can be created in K8's ecosystem that standardize data flow.

In K8's instead of having beans that live in a single JVM.  You now have containers that live in a distributed mesh.

Possibilities for delivering Service Abstractions and Cross Cutting concerns in K8's:

1. Creation of a Routing DSL that enables partitioning grids of compute resources into mirror images (replication at the aggregate level)

2. Creation of a Data DSL that abstracts data from business logic and can work to achieve data locality. (this is a different problem than the business logic).  Sidecar databases could deliver the implementation of this cross-cutting concern.

3. Creation of an Execution DSL that would enable flows of operations to be orchestrated inside the mesh.

4. Creation of a Resource DSL that would enable creation of templated resource graphs.

The 4 possibilities above are at the very lowest level, but there could be more application specific layers that sit on top of this layer.   Business logic itself could possibly be organized to benefit from the sidecar approach.  Take an application that needed to provide low level debug operations at times, but this debug info was costly to create.  It might be possible to "tack on" the debug generation by using sidecar containers that either replicated the process or interactively worked with partial results without affecting the speed of the original calculation.   This is the power of this design pattern... the base logic stays clean and the logic that implements the detailed tracing is in another container.

Update 7/7/2020:

There is work being done in this area in the OpenKruise project:

https://openkruise.io/en-us/docs/sidecarset.html

Something similar could be accomplished via an Operator.  The point is that the pattern can be reused and cross-cutting concerns can be standardized.