Understand online marketplaces, SLOs for providers

Dave Sobel is host of the podcast The Business of Tech and co-host of the podcast Killing IT. In addition, he wrote Virtualization: Defined. Sobel is regarded as a leading expert in the delivery of technology services, with broad experience in both technology and business.

In this video, Sobel spoke with Marcin Kurc, CEO of Nobl9, an SLO platform provider, about how services are presented to customers in marketplaces and the difference between service-level objectives (SLOs) and service-level agreements (SLAs). They discussed how SLOs work and how customers are pushing transparency for SLOs and SLAs.

Transcript follows below. Minor edits have been made for brevity and clarity.

Dave Sobel: Particularly for some of my listeners who may not even be familiar with the way online marketplaces bring together services and software and such, can you give me your definition of marketplaces?

Marcin Kurc: That's a very interesting question because probably there are as many people [as there are] definitions of marketplaces. When you take it from the bottom up, of course, there's the marketplace that is focused on infrastructure -- anything you would see from cloud services to applications running on top of the cloud service, plus any type of managed service, for example, on top of that. That's very popular. You're talking about AWS Marketplace or Google Cloud Marketplace. Oracle's got one as well. So that's very, very specific.

Then we have a lot of aggregators that fit under the marketplace definition that focus mainly on SaaS and optimizing, contracting for SaaS. And then all kinds of different add-on marketplaces that many companies out there provide. Google Workspaces, for example, provides you a bunch of plugins for Gmail. To me, every single one of them fits in a category. We'll see a lot of convergence right now where infrastructure marketplaces also provide SaaS, but it all stays in the category where it's simplifying the transaction with the customer, basically.

Sobel: Let's put ourselves in the mind of the customer. How does a customer approach this? Are they looking at it as just a software-buying platform? Are they looking at a complete solution? Are they viewing it as walking into the mall and perusing? What's the mindset of a customer who's trying to leverage a marketplace?

Kurc: I started marketplaces when people were still thinking that Amazon is selling books. It's been a while ago. Back in that day, I would say the customers were mainly looking for a [proof of concept], kicking tires, finding those few solutions that would make sense without really picking up the phone or finding someone on the web. With time over the past few years, I think that behavior has changed a lot. We see organizations, even large enterprises, consuming from cloud marketplaces for a number of reasons. Simplification of their billing makes it easier for their internal teams to consume software. A lot of those organizations now allow separate teams to pick the best tools for their job, for example. There are a lot of different reasons. I think there's a lot of room for growth and improvement of spaces. And you see a lot of that innovation happening -- either on AWS Marketplace, [Google Cloud Platform] marketplace -- figuring out how to really play with the channel, bring the other entities on the platform and really bring the full experience for the end customer.

Sobel: I come from the services world, so I always like to think about it from that perspective. I always quip the Salesforce line of, 'There's $4 to $5 worth of services for every dollar of, say, Salesforce software that's sold.' If I'm thinking about it that way, when I enter a marketplace as a customer or the marketplace is selling these solutions as a product, are they thinking about this... If I make it a combo meal, is the Big Mac the software and then the plus fries is the services? Or is it really presented as the services are the lead, where the product is dragged? How is that presented?

Kurc: It's going to differ across different types of those marketplaces that we started with. If you go with infrastructure, right from the bottom, I would say that the focus is on consumption. When you look at AWS or GCP, the goal for those organizations is to really spin up the usage of their services. So bring those customers on their platform, spin it up, and that's really where they make money.

When we go higher, then we see more of a traditional, classic approach where service companies aren't in quite a similar situation -- help [with] implementation, managed services solutions that are basically stitched together with the solutions offered by those marketplaces. We're coming more to the traditional way of consuming software and enterprise, while we remove the difficulty of configuration, setup and operation on the cloud platform.

Sobel: Now I'm going to ask what might be a simplistic question, but I think it's useful for definitions. Is the use of a marketplace [considered] 'e-commerce' in your mind?

Kurc: It would probably fit under e-commerce definition. I don't see why not.

Sobel: OK. When we're thinking about digital acquisition, some of the strategies of e-commerce might actually work for many service providers. Now, I want to actually pivot a little bit because your experience went from that, but now you've moved on to thinking more about service-level objectives and stuff. Tell me a little bit about what you're doing now at Nobl9.

Kurc: Nobl9 is basically a dedicated platform for management of service-level objectives. Service-level objectives come from Google, from [site reliability engineering] concepts, that basically allow organizations to understand the behavior of their applications and proactively see the impact on the customer satisfaction. The reasons why companies are adopting this today is basically [proliferation] of microservices, APIs and just the sprawl of different services that need to be incorporated into applications.

That makes it even more difficult to understand what other teams are doing. Even more so, very basic things. You might have 20 different teams, 20 different applications or 20 different components of an application in your organization. And everybody's got a different reference point. Even finding this, what 99.9% means to one team might not mean the same thing to another team. For us, it's about standardizations, being able to truly understand the full impact of the application or any type of issue of the application on end customer revenue, so it's more appealing to execs.

Sobel: For any of us that have come from traditional infrastructure management, we're very familiar with the idea of a service-level agreement or an SLA. What's the difference then between an SLA and an SLO?

Kurc: SLA is basically a legal contract between the customer and the provider. And again, those will differ not only across different organizations, different companies, but different teams technically. You have those examples where someone will exclude, for example, downtime that was planned or looks at a certain event in a different way. In many cases, what we find out, what we hear from our customers, a lot of those things are not necessarily very accurate. It's really something to make it easier for the customer to understand what's being provided and provide those customers with credits or whatever it might be in an event of an issue, which happens, right.

SLO is a little different. Also, with SLAs, you really calculate SLAs after the fact. Something happens, you look at the downtime, you figure out according to your legal contract what it means and how you present it to the customer. SLOs are very much proactive. They're designed for you to understand if something is degraded or something is going down, something is about to happen. And it lets you really figure out if you should be taking any actions. A good example is, if you're running in a cloud in one region and you have a failover opportunity for application. If you see that it's degrading, you might have time to make this decision if you want it to fail over or not. Failover is great on slides, but we all know it's a very costly operation. Instead of doing this, SLOs might tell you that the issue that you're experiencing is not necessarily impacting all the customers, not necessarily impacting the revenue for those customers, and you might not need to do those things.

Sobel: If I'm thinking then about the relationship and the differences between an SLA and an SLO, is your vision of this -- I'll use the Boolean references -- is this an 'and' or an 'or'? Are they complimentary or are they competitive? Is it 'and' or an 'or,' and why?

Kurc: It's a combination of both. Yes, both are important. The question is how much you really want to expose to the customer. For now, the focus on SLO is very much internally. It's a relationship between two different teams. Let's say you build a service that's performing some function. I'm using that service in my application. If I take a dependency on your application, your application is only three-nines [availability] and I'm exposing it to my customers as five-nine availability, then I have an issue to start with. So understanding that relationship is important for me internally. Now, for the external calculation, from the SLA perspective, that still might be five-nines because you're excluding certain events, you're doing certain things. And that is fine.

We see more and more of our customers that are actually pushing that information very transparently and exposing SLOs. SLOs basically become their SLAs at the end of the day. It's very similar to a few years ago, maybe more than a few years ago, when we were buying something online, we just went there. There was some logo that is super secure, and [we] don't worry about a credit card; we just put it in and everybody's happy. And with years, we start looking at security frameworks that organizations start to implement. Nobody would really use that solution if it wasn't built to certain specs.

We believe that we are heading in the same direction with availability. Right now, we can tell the customers, 'Yeah, we're doing everything right and everything is good. Trust us. It's going to be performing.' We already see customers requesting that information: How are things implemented? Can you assure us that what we are going to see is going to be truly coming from your systems? It's pushing beyond that SLA in a transparency that really helps us understand how your application is behaving, what are the controls that you put in place to really deliver that level of availability.

Sobel: Now, the way you're talking about this… You're using all the cloud words, right? Which I would expect, because it's very cloud-forward and it's coming from a DevOps world. But I want to check, is the vision of the way you're thinking about this cloud-only or simply everything and it's just because you're leading with cloud? What's the relationship then with SLOs and the cloud?

Kurc: Well, some people say that everything is going in the cloud. If that happens, that's fine. Our solution is definitely not built just for cloud. We work with on-premises systems, hybrid solutions. Our focus from the beginning, from the architecture of the system, has been the ability to run it in the hybrid environment and include on-premises systems. Because there still might be applications where certain things are running, let's say in a banking branch, just to process things. And we see a lot of those. So for us it is the ability to service all of those use cases.

Sobel: How do I link SLOs to a customer's business outcome? How do I make that connection between the two from a business delivery perspective?

Kurc: It's collaboration. There's no silver bullet at this point. Understanding your business and understanding of components of the application that impact that revenue is still important to understand. There is no way around it. From that, you can really derive SLOs that are very specific to your use case. Think, for example, you're selling tickets for events. Everything's going fine because there are middle-of-the-road artists or whatever it might be. You don't have this load yet. You might not notice any degradation. However, one time you have this big artist, big name, and all of a sudden, the system is not down, but it's also not processing a certain transaction. If it's checkout or maybe picking a seat or whatever it might be, at that point, from a business perspective, you have a full understanding that you take a hit on revenue and you can translate it to a very specific piece of that application or a very specific service that is part of that application.

And then you can specify SLOs that define, the time from picking a seat to selling the ticket, or that credit card transaction. That gives you a very good understanding of what's going on. When you think about when you have the spike, you start to see when things are degrading or going down. And you might choose an action that's going to fix that problem, or you might figure out how to address it. All of those things are still very important to understand. You can't just say 'SLO, solve my problem; I don't have to understand my business.' To the contrary, you really have to understand your business to derive SLOs that help you understand the impact on the customer and your revenue for that matter.

Sobel: We both know that tools aren't necessarily the solution. They just enable it. If somebody's listening and saying, 'OK, this makes some sense to me. I want to start applying this,' how do they get started if they haven't been thinking this way or working with SLOs? Where's the beginning?

Kurc: Understanding your applications first, no question.

About the author

Dave Sobel is host of the podcast The Business of Tech, co-host of the podcast Killing IT and authored the book Virtualization: Defined. Sobel is regarded as a leading expert in the delivery of technology services, with broad experience in both technology and business. He owned and operated an IT solution provider and MSP for more than a decade and has worked for vendors such as Level Platforms, GFI, LOGICnow and SolarWinds, leading community, event, marketing and product strategies, as well as M&A activities. Sobel has received multiple industry recognitions, including CRN Channel Chief, CRN UK A-List, Channel Futures Circle of Excellence winner, Channel Pro's 20/20 Visionaries and MSPmentor 250.