shardingsphere-elasticjob-ui VS opentelemetry-tracing

ShardingSphere claims to offer an ecosystem able to transform any database into a distributed database system. It acts as a proxy between your code and your database(s). It comes in two flavors:

The application uses Apache Shardingsphre to route again depending on the data. If the value computed by the API Gateway is correct, the flow stays "in its lane"; if not, it's routed to the correct database, but with a performance penalty as it's outside its lane.

Apache ShardingSphere

Apache ShardingSphere supports data encryption. By parsing users’ SQL input and rewriting the SQL according to the users’ encryption rules, the original data is encrypted and stored with ciphertext data in the underlying database at the same time.

Apache ShardingSphere is a distributed database ecosystem that can transform any database into a distributed database system, and enhance it with sharding, elastic scaling, encryption features & more.

ShardingSphere supports a database gateway, but its heterogeneous capability is limited to the logical database in previous versions. This means that all the data sources under a logical database must be of the same database type.

ShardingSphere Official Website

ElasticJob UI is the visual admin console of ElasticJob, whose target users are developers and DevOps teams rather than users. Generally, it is deployed only in the internal environment and thus its R&D focus more on its features.

I flew from Geneva the day before my talk and crashed into my hotel bed. Of course, I woke up very early in the morning and decided to check the demo of a talk planned for the end of the tour. It didn't work, so I tried to remove the stopped containers. Tired as I was, I deleted all my Docker images, including the ones I'd need a few hours later for my talk on OpenTelemetry!

Last year, I wrote a post on Open Telemetry Tracing to understand more about the subject. I also created a demo around it, which featured the following components:

I decided to give it a try. I'll use the root commit of my OpenTelemetry tracing demo. Let's execute the proposed command:

The OpenTelemetry Collector sits at the center of the OpenTelemetry architecture but is unrelated to the W3C Trace Context. In my tracing demo, I use Jaeger instead of the Collector. Yet, it's ubiquitous, as in every OpenTelemetry-related post. I wanted to explore it further.

One of the components of my OpenTelemetry demo is a Rust application built with the Axum web framework. In its description, axum mentions:

It's always a good idea to check that the design behaves as expected. We can use OpenTelemetry for this. For more information on how to set up OpenTelemetry in such an architecture, please refer to End-to-end tracing with OpenTelemetry.