All developers know that moment when, after we’ve reviewed everything and completed our sanity tests, our code somehow doesn’t work in production. The question is, how quickly and easily can we discover the problem so that we can continue delivering features faster and more confidently to our users?
OpenTelemetry (OTel) is an open source selection of tools, SDKs and APIs, that allows developers to collect and export traces, metrics and logs. It’s the second-most active project in the CNCF, and is emerging as the industry standard for system observability and distributed tracing across cloud-native and distributed architectures. OTel supports multiple languages, like JavaScript, Java, Python, Go, Ruby and C++.
In our line of work, it’s not uncommon to encounter customers that have custom workflows or architectures that may not always support distributed tracing mechanisms. In development in general, we often have our beliefs on what should happen in theory and we rely on Hello-World examples, only to be surprised by what happens in reality. Our customers too sometimes have to build creative solutions to deal with unique situations – which then motivates us to build creative solutions as well.
One Friday afternoon we got a Slack message from one of our early customers, letting us know that there was an issue with updating our SDK. Apparently, our SDK introduced a new dependency to the code that their team wasn’t able to meet: graphql@16.0.1. This made it impossible for the customer to upgrade to a newer version of our SDK and became a blocker for them.
One of our core values at Helios is to eat our own dog food (or for those of you who want to keep it classy, “drink our own champagne”). While this is a known best practice among many product development teams, it’s even more important when working on tools meant to be used on an ongoing basis by developers.
We’re proud to announce Helios has achieved SOC 2 compliance! This means our security policies and procedures have been externally audited to ensure they protect and secure our customers’ data. In a world where mishandled data could have severe consequences for organizations, it was important for us to assure our customers that their data is protected and that we continuously work to improve our posture.
OpenTelemetry (OTel) is emerging as the industry standard for system observability and distributed tracing across cloud-native and distributed architectures. But where do developers fit in? With OTel’s main use case focusing on production monitoring and observability, I find that many developers are still not fully familiar with OTel. Others believe it is more of a tool for DevOps/SRE.
Microservices are powerful architectures. Yet, they are complicated ones as well. Microservices enable engineering departments to scale faster than ever, but this speed comes at the price of developer confidence. When developing microservices, it is hard for developers to understand how different services interact with each other and why a certain event occurred when and where it did.
They say that co-founding a startup is like marriage. In our case, it’s probably a long overdue one, since we’ve already been collaborating together for 18 years. Ever since we first shared a bunk bed in the army, our joint journey has included a number of milestones, like military service, living as flatmates, university, and working together. Just over a year ago we knew it was the right time.
