Customer Story:
Observability Hero: Jason Huling from Blooma

Observability Hero Jason Blooma Banner
We interviewed Jason Huling, Director of Technical Operations at Blooma, to talk about how Observe has become their "single source of truth" for observability.

What is important for Blooma when it comes to Observability?

When I joined Blooma I was a one-person DevOps shop, so I knew I needed to find some balance with whatever tool I chose. The idea of having some other tool I would need to support and manage, on top of making sure the application is available, was not something that appealed to me. About that time I saw that Observe had just come out of stealth and thought, “Wow, this is perfect!”

Besides consolidating tools, I thought that having tracing visibility in our application would be important to see how requests were being made throughout the system. It turned out that the tracing data wasn’t as useful as anticipated for our current stage of development, especially since the application is evolving a lot at the time. What we did find was that information coming from our logs was really valuable, we just needed a better way to fully take advantage of them.

What are the biggest advantages of using Observe?

One of the biggest advantages, in general, is just getting all of our data into Observe — literately everything. Once I saw the power of being able to connect all of these different datasets, modify them to whatever fits our needs, and how simple it is to get data into Observe, I started thinking, “Why not put ALL of our observability data into Observe, regardless if we think we need it?” That way if we ever needed it for an operational or even compliance reason down the road we’ll have it. After all, storing data is dirt-cheap in Observe.

In terms of use cases, when I first started ingesting our AWS data I noticed we had various log datasets, like VPC Flow logs, that didn’t have a consistent way to view them. So being able to get those logs into Observe with other things like CloudTrail has been extremely valuable when we need to investigate a potential issue – or when you need to prove to auditors you meet certain compliance standards.

We also use IAM roles that Terraform uses to build infrastructure, and we expect how and when those roles should be used. We know that outside of these events we shouldn’t see any activity for that role, which makes it much easier to spot anomalous behavior should it occur because all of these different systems are now connected.

What can you do with Observe that you can’t do with other tools?

The ability to tie everything together is unmatched. In our infrastructure pipeline alone, we can connect everything from a git commit to the Terraform cloud workspace, and then to Cloud Trail logs.

In terms of costs, if we had to spend a ton of money to store all of our observability data I probably wouldn’t send as much data to Observe. It’s a lot easier to not worry about the cost and shoot it over to Observe – if we don’t get any value from it we’ll stop sending it. Not having to worry about spending X number of dollars per Gig for some service is extremely helpful, unless you have an unlimited budget, which I don’t think anyone has.

The other thing that’s on my mind has to do with tool management. It’s much easier to focus all your efforts on one tool, rather than three or four solutions to manage all of your observability data like logs, metrics, traces, etc.

Have you been able to use Observe in a security-related context?

We recently went through a network penetration test before our SOC 2 compliance, but there was a miscommunication on exactly when this would happen.

So, one day I started getting alerts from GuardDuty, and I wasn’t sure if I should freak out or not. I looked closer at the VPC Flow logs and then connected them to our Kubernetes pods to see where the traffic was coming from. Turns out, it was one of the VMs I’d provisioned for the pen tests.

Luckily, everything was okay, the pen-testers just didn’t communicate as clearly as we would have liked. I don’t see how we could have triaged that incident nearly as quickly without having all of that data together in Observe.

Since adopting Observe, how has the usage of your other tools changed?

Observe is our single source of truth for everything that happens in our systems from GitHub commits, to terraform actions, AWS resources, application logs, metrics, and traces, to everything. Observe has everything and has it all connected for us.

This allows us to quickly and effectively triage anything that happens in our environment. From the management side, having that single platform, and not having to manage a handful of tools that I have to figure out how to cobble together, adds a ton of value.