Podcast: Brian Singer Gets Into The Meat and Potatoes of Nobl9

Podcast: Brian Singer Gets Into The Meat and Potatoes of Nobl9

More by Nobl9:

Meat and Potatoes podcast sat down with Brian Singer, CPO and co-founder of Nobl9 to find out what even is Nobl9?

What is Nobl9 and your role in it?

The Nobl9 platform helps companies achieve the right level of reliability for their digital services. The question you should always be asking is how much can you break things? What is too broken? Nobl9 employs concepts called Service Level Objectives and Error Budgets to make sure customers are hitting the right marks for what their customers are expecting.

Can you give us an example?

Let’s say you’re using Gmail and it takes an extra 5 seconds to load the home page about once a month – not such a big deal, right? But if it takes an extra 15 seconds to load several times per week, well, that might make you annoyed and you might even start to look for another service.

SLOs help us find that right amount of reliability. Whether it’s response time or availability or something else in the user’s journey. 

On the flip side, if you’re using Gmail and your emails actually get dropped, the level of reliability needed is much higher. Some services have to have very high reliability (i.e. a pacemaker or cell service) and that’s expensive which is okay if that makes sense for the service.

Like, if you’re pinned under a tractor on the family farm with your phone in your hand? That call cannot drop under any circumstance.

Yes, exactly. You wouldn’t want to have to move your arm around trying to find a couple bars of service. 

What led you to Nobl9?

I got my start in enterprise software. Eventually, I realized I wanted to start a company. Cloud was in vogue at the time and I found an opportunity with Orbitera. Then we were acquired by Google – we were a part of Google cloud for 3 years.

Taking a product we had built and applying Google production practices was the first exposure I had to the practice of reliability engineering and the way Google performed it. As an entrepreneur, you take out the concepts you think might be applicable to the broader market. Within the context of bringing that platform into Google, we did employ these SLOs and Error Budgets (using Google tooling). We thought “wow, these concepts are really powerful. Everybody will be measuring how reliable our services are.” This led us to believe there could be a platform that’s focused on solving this particular problem.

I’m a big believer in getting a lot of customer feedback early on. So we started that journey by talking to the companies we thought would be the most likely users of the product. Our process was taking that feedback and using it to prioritize features relevant to those customers and from there we moved into Beta. Our goal was to prove this was a commercially viable product and that we had built it with features we could start on the go-to market.

I’m a big believer in getting a lot of customer feedback early on.

What is the acquisition process like from the tech side?

The engineers are responsible for technical integration. For us, that meant running it on GCP. Since we had built this product on AWS it made sense for us to run it on GCP rather than move it to Borg [Google’s internal container orchestration system]. I’d say we were one of the early adopters for Kubernetes for production use cases. And what was interesting was bringing the SRE and Google production practices to the product (Nobl9) in Google Cloud. 

At some point, the Google folks were looking at what you built – did they have a problem with it?

Not really. Any product you look at as an engineer can ask “why would you build it that way?” Software is always being rewritten. New tech, changes in customer requirements, etc. You usually have pretty good reasons why it’s rewritten, In an acquisition you have a chance to reassess. It’s part of the overall process.

Was it collaborative?

Yes. Google is a very bottoms-up culture. In other words, the best ideas tend to bubble up. It’s an academic environment. You’re making arguments and decisions over written work. It’s about collaborative decision-making and what’s right for the business.

You got series B funding recently. What’s that process like? Do you enjoy it and what did you use the funds for?

For us, fundraising is tied to milestones that tell you something about the market and the company. With our series A we wanted to demonstrate the commercial viability of our product. Once we had that locked we wanted to raise more capital so we could go to market and build the distribution we need. The distribution/gtm side of it is just as important as the product. If you can’t get it in the hands of the customers your company won’t be that successful. In order to do that you have to make investments in the product and of course hire more folks to work with customers. Sales, engineering, customer success.

From a fundraising standpoint, we were lucky to have an engaged set of investors for series A looking that were ready to back . My co-founder and I wanted to build a market around the company. It’s similar to being a free agent in the NFL. Even if you’re going back to the same team you want to go out and see what’s happening in the market. And it’s up to the market to see what kind of valuations you’re going to get. We went out and pitched to a bunch of VCs but ultimately came back to our series A people.

How do you manage your day?

A lot of it is tied to being a distributed team. We have a development team in Poland and we use a lot of Zoom and Slack like everyone. We’re heavy users of Google docs. And maybe some of the Google culture wore off on us because we’re invested a lot into the written word. Communication is key. For instance, if other people weren’t there for a conversation they can always come back and see it.

And we’re heavy Jira users. But the tool can’t solve everything. You have to be invested. We’re lucky to work with talented program managers.

Trying to determine how reliable a product should be takes a product manager who knows how a customer is using it, that a business executive wants to know the impact to the bottom line and the engineer’s needs.

Then you announced the availability of the Nobl9 SLO platform. Can you explain the product?

The product allows companies to measure the reliability of systems and make decisions based on that data.

Customers care about reliability and security so you’re investing in the features and capabilities but you’re also investing in the platform itself. A lot of companies have made some homegrown solutions but couldn’t quite get it where they wanted it to be. Nobl9 can do that for you. You don’t have to put a team of engineers on building something from scratch. We do it for you.

People do like it when you can see the ROI and make it simple.

Twilio and pagerduty took a fairly simple idea (send a text alert) and both turned it into platforms. If you do something really well for a company it’s one less service they have to carry a pager for internally. If you don’t have to support a service that’s a great cognitive load off your team.

May 17th is SLOCONF! Tell us a little about that.

This is the first conference focused on people who are early on in their SLO journey. Our goal is to make that knowledge more accessible so people can uplevel themselves and bring that new knowledge back to their teams.

And SRE as a practice is one of the fastest-growing areas in tech – I think it’s the number 2 job in tech on LinkedIn (but don’t quote me on that). 

Register to attend SLOconf and follow SLOconf on Twitter!


Image credit: Petri R on Unsplash

SLOs in Minutes, Not Months

Get Started with Nobl9 Reliability Center Free Edition

Start Now

Do you want to add something? Leave a comment