The position of Spiderwiz in the spectrum of service-mesh technologies and why it is still needed

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:

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.