TelemetryHub is Easier to Set Up Than Stripe

TelemetryHub is observability tooling that your team needs: with powerful analytics and insights that help you measure and manage your applications’ performance. It is a telemetry platform that helps developers and DevOps engineers easily collect, store, and analyze data. It is cost-effective, secure, and easy to use.

But one of the main barriers to using any observability tool is the time it takes to get deployed. Not only was it mentioned in DZone’s trend report on observability, but it’s also one of the most-mentioned reasons when you ask people why they’re switching Observability tools.

Time is of the essence.

The speed of deployment is a massive differentiator for modern DevOps tools, and you need to consider deployment times whenever you’re doing cost estimates. The length of time it takes to deploy changes can vary significantly based on the toolchain you are using. The more advanced a given DevOps toolset is, and the more environment complexity is involved in your applications, the longer the deployment times will typically be. Many popular deployment solutions have options to optimize delivery time, like gradual or feature flag deployments that enable faster adjustments and updates to your systems while minimizing potential downtime.

Monitoring, especially full-stack monitoring, matters.

But ask yourself: how critical is observability to your platform? I’d say it’s up in the top 10 priorities for your engineering team, which is why I’m confident that TelemetryHub is worth a look since it’s faster and easier to set up than another key requirement: getting paid.

If you’ve built a tool that charges customers, chances are you’re familiar with Stripe. The payment processor is everywhere, and with good reason. Among their other benefits, Stripe is easy to set up for a payments provider. But one look at their quick start guide will show you that Stripe will take a few weeks to get working on a production-scale application. There’s server-side config, authentication details, front-end integration, data layer integration, and more. Let’s talk through a standard Stripe adoption:

First, your operations team will need to work on setting up authentication and key exchange with Stripe (all of this leaves out any assessment or Proof of Concept time). From there, someone on the back-end team of developers will code the first few successful Stripe requests while either setting up a dummy charge account for the Test and Dev environments OR mocking out the Stripe portion of a transaction for any non-prod requests. Next, you’ll either need to get your front-end developers to send their Stripe requests, or the back-end team successfully will want to set up a Stripe microservice to handle requests. Either way, the Operations, Back end, and Front end teams will need to coordinate.

Here’s the thing: you can get TelemetryHub, with its OpenTelemetry endpoint, working in a couple of days.

Take an example setup, a Java application with thousands of users. 

Step 1. Install the OpenTelemetry Java instrumentation

You’ll be using the amazing opentelemetry-java-instrumentation: Built on top of opentelemetry-java and provides a Java agent JAR that can be attached to any Java 8+ application and dynamically injects bytecode to capture telemetry from a number of popular libraries and frameworks. 

The dependency injection for Java installations is all in the TelemetryHub quickstart.

As you shouldn’t have to alter or add to your actual code, this is significantly faster than adding the hooks for Stripe integration to your codebase.

Step 2. Configure your data endpoint

While more advanced setups might use the OpenTelemetry collector, for a first deploy, you can just send data directly to TelemetryHub’s OpenTelemetry endpoint. All you’ll need is the URL for our endpoint and your TelemetryHub ingest key:

“`java

SpanExporter exporter = OtlpHttpSpanExporter.builder()

    .setEndpoint(“https://otlp.telemetryhub.com”)

    .addHeader(“x-telemetryhub-key”, “$YOUR_INGEST_KEY”)

    .build();

“`

Of course, this is where the comparison to Stripe is a little stark, though you could accuse me of comparing apples to oranges: Authentication with a payments provider is much more complex. While you can rely on TelemetryHub data to be strictly encrypted, preventing anyone from listening in on your data, it’s still quite a bit simpler than setting up Stripe.

Step 3. (optional) integrate logs.

While the OpenTelemetry standard is still working on logs, our quickstart does set up a basic logs exporter with just a few lines of code!

Again, we have a much easier process than Stripe, where logs must be requested via an API. Developers are often left wondering why a process failed, having to interpret whatever error code they received.

Step 4. Set up your dashboards

Okay, I’ll level with you, folks; this fight has been rigged. In all the previous steps, TelemetryHub had massive advantages over Stripe. For this last round, though, we’ve given our contestants an even chance. But it is an opportunity for TelemetryHub to outshine the other observability tools.

Because just like Stripe, TelemetryHub comes with all the dashboards you need up and running right from the start.

You’d expect that Stripe could give you a dashboard with everything you need; the real surprise is that TelemetryHub also makes it easy to see the data you’re sending right away.

It’s just that simple.

Am I beating up on Stripe because Stripe is so hard to get running? Absolutely not. Stripe, again, is easy to set up for a payment processor. It’s just that Observability, with the benefit of the OpenTelemetry project, can be a whole lot easier. And at TelemetryHub, we’ve kept things super simple, and you can see the difference in our deployment process.

If you’re interested in trying TelemetryHub, get in touch to discuss early access pricing.