As engineering organizations transitioned from monolith to microservices architectures, they sought to make their development efforts more scalable and manageable. The microservices paradigm promised to increase development speed, reduce MTTR and improve quality while cutting down on maintenance costs. However, in real life, there are inherent quality caveats when it comes to developing microservices.
As an engineer building a distributed application, every now and then I need to look for and analyze bottlenecks in our system. There can be several triggers for conducting a bottleneck analysis, for example: In this blog post I’ll share how I’ve been using our own product, Helios, and the power of distributed tracing, to help pinpoint bottlenecks in our system and resolve them fast.
As businesses are planning for 2023, many are adopting a more conservative mindset when it comes to their resources. In light of the recent market fluctuations and the uncertainty of if and how a recession will affect them, they are looking for ways to cut costs and increase their efficiency. But despite the spending slowdown, development velocity can’t slow down.
OpenTelemetry (OTel), the emerging industry standard for application observability and distributed tracing across cloud-native and distributed architectures, is becoming an essential tool for Go developers. However, implementing OTel with Go to send data to observability platforms is hardly a straightforward process. At Helios, we’re on a mission to help as many teams as possible adopt distributed tracing.
In November 2022, our team here at Helios attended and sponsored KubeCon North America. Our motivations for being there were related to getting out the word about what Helios is doing to accelerate development velocity through microservices troubleshooting. Here we are at our booth: While there we also caught up with a number of the other folks attending the event. Here are a few of the key takeaways and trends we noticed.
Traditional software application infrastructure generally followed a monolithic pattern; one application connected to one database. Understanding what was going on inside the application itself was a simple proposition, with relevant logs and metrics all originating from the same source. When it came time to scale, the answer was to get a bigger server or to get more servers.
Third-party integrations are inevitable in development. Some functionality is outsourced as there is no need to develop something in-house that’s already working, while some integrations are performed to connect with the customer’s ecosystem to help them get their job done better.
It’s common in our everyday language to conflate seeing and understanding when the two are actually very different things. For example, if every day for the last few years we spoke briefly and wrote down the total number of Covid cases in the world, it would be easy to see some trends in the data—you would see the data. But if we present the same data drawn as a chart, it’s easy to understand where the spikes and dips are and when the situation got really bad.
OpenTelemetry (OTel), the emerging industry standard for collecting observability data, recently announced the GA of its demo application – and this is good news for distributed tracing fans.
OpenTelemetry (OTel), is an open source, CNCF (Cloud Native Computing Foundation) project that provides tools, APIs and SDKs for observability data collection (i.e, logs, metrics and traces) from cloud-native applications. Developers can use the data collected from OTel to monitor and analyze application health and performance. To leverage the data and its insights, you can export the data to external solutions, like APMs, open source Jaeger and Zipkin, Helios, and others.
