When it comes to service-mesh development, there is a plethora of technologies that address many of the involved aspects. An obvious question that may be asked is why do we need yet another technology. To answer the question, let’s look at the following illustration:
The illustration is based on a figure that was presented in a 2018 report by Gartner Inc., which described the spectrum of service mesh technologies based on code coupling. The spectrum is divided to three groups:
- Mesh-Native Code: Technologies, mainly programming models and runtime engines, that are used for building service mesh systems. In this group the report includes the Service Fabric part of Microsoft Azure, Lagom, Go-Micro, Axon Framework and Seneca.
- Mesh-Aware Code: Technologies, including framework libraries, APIs and sidecar processes, that are designed to support service mesh systems. In this group the report includes Spring Cloud, Netflix OSS, Hydra, Steeltoe and Finagle.
- Mesh-Agnostic Code: Cloud based technologies that do not specifically address service mesh systems but can be used by them as sidecar proxies. In this group the report includes Istio, Envoy, Linkerd, AVI Networks, Aspen Mesh, Consul and ContainerPilot.
Of these three groups, Spiderwiz, as a programming model and runtime engine, is clearly in the first. It may have a small overlap with some of the technologies mentioned in that group, but it is substantially different. In some cases programmers can benefit from using them in parallel. The only technology that has a remarkable similarity to Spiderwiz is Seneca, whose programming model follows a similar concept, but its runtime engine and many features are thoroughly different.
The technologies of the other groups are mostly orthogonal to Spiderwiz. Although there is a certain degree of overlap in some features, other major cloud computing features – load balancing, redundancy, short circuit management, containers, security and authentication to name a few – are neither in the scope of the core functionality of Spiderwiz nor do they conflict it, and therefore should be handled by existing technologies when needed.
Having said that, you may notice in the figure above that Spiderwiz sends “cobwebs” across the entire spectrum. This is because it is expected that the proliferation of Spiderwiz will make it tangent to many other technologies relating somehow to service mesh. This can happen with the emergence of Spiderwiz plugins that alleviate the use of some tools, or with the evolution of extensions to prominent tools that facilitate tighter integration with Spiderwiz.