Azure for Executives

Building and selling Software-as-a-Service (SaaS) solutions with Ercenk Keresteci

Episode Summary

Moving solutions to the cloud, or building a cloud-native solution, requires rethinking how we sell and distribute our software. Cloud-first sales models can be very different than traditional sales pipelines. Today we are focusing on Software-as-a-Service applications as a vehicle for selling cloud-based solutions. Our guest, Ercenk Keresteci explains that SaaS applications are the de-facto model for companies licensing their software.

Episode Notes

Most organizations producing software are moving their workloads to the cloud. In doing so they are typically choosing between 3 modes of cloud service, especially regarding their product architecture. The 3 main models for cloud offerings are IaaS, PaaS, and SaaS.

Moving solutions to the cloud, or building a cloud-native solution, requires rethinking how we sell and distribute our software. Cloud-first sales models can be very different than traditional sales pipelines. Today we are focusing on Software-as-a-Service applications as a vehicle for selling cloud-based solutions. Our guest, Ercenk Keresteci explains that SaaS applications are the de-facto model for companies licensing their software.

Episode Links:

Episode Transcript

What is SaaS?

Publish solutions on the Azure Marketplace

Clients for different programming languages and samples

Guest:

Ercenk Keresteci is a Microsoft Principal Architect with a focus on manufacturing and the Internet of Things. He has a specific focus on these industries while helping partners onboard their solutions onto the Microsoft Commercial Marketplace.

Follow him on LinkedIn and Twitter.

Host:

David Starr is a Principal Azure Solutions Architect in the Marketplace Onboarding, Enablement, and Growth team at Microsoft. 

Follow him on LinkedIn and Twitter.

Episode Transcription

DAVID: Welcome to the Azure for Executives podcast, the show for technology leaders. This podcast covers trends and technologies in industries and how Microsoft Azure is enabling them. Here you'll hear from thought leaders in various industries and technologies on topics important to you. You'll also learn how to partner with Microsoft to enable your organization and your customers with Microsoft Azure.

Hello, listeners. Most organizations producing software are moving their workloads to the cloud and in moving workloads to the cloud or building cloud-native solutions, this requires rethinking how we sell and distribute our software. For example, cloud-first sales models can be very different from traditional sales pipelines, and we'll get into that a bit deeper in just a bit. Today we're talking about Software-as-a-Service applications as a vehicle for selling cloud-based solutions. SaaS is getting our attention on this show because SaaS applications are the de facto model for companies licensing their software today. And to join us in this conversation, Ercenk Keresteci is a Microsoft Principal Architect with a focus on manufacturing and the Internet of Things. He has a specific focus on these industries while helping partners onboard their solutions onto the Microsoft Commercial Marketplace. Ercenk, welcome to the show.

ERCENK: Oh, thank you. It's a pleasure to meet with the listeners. I really appreciate you inviting me over.

DAVID: Absolutely. We'll start at the beginning and look at what SaaS is and how it differs from alternative distribution models. So Ercenk, what does it mean for software to be a SaaS solution?

ERCENK: So if you break down the whole SaaS acronym, it's Software-as-a-Service. We can double-click on the word service here, and we can think a little bit more about what does service means in this context? The way I describe SaaS solutions is that if a solution is developed, maintained, and administered by an independent software vendor and the customers are basically getting this as a service, I call it a Software-as-a-Service solution. And I'd like to also point out the fact that there is a misconception about the deployment piece so deployment in the sense that where it is deployed, how it is deployed. Is the deployment a delineation of Software-as-a-Service? And I tend to argue that the boundary of a solution being Software-as-a-Service is at the administrative level or it's at the maintenance level. If the same vendor or same party is maintaining or doing the upkeep of the software that's serving that solution and the underlying frameworks and the operating system, and the hardware, et cetera are all hidden from the end customer and its users, then I call it a SaaS solution. 

DAVID: Okay. That's a great starting point. And what I heard is essentially, regardless of the type of software, you're removing maintenance off of the customer putting it onto the publisher of the software. And along with that, there are several models for delivering Software-as-a-Service. And I wonder if you could share some examples of SaaS solutions, Ercenk? 

ERCENK: Oh, Sure. So that's actually a great starting point or actually [inaudible 3:40] to my comment about the deployment. One very typical example everybody can think about is a pure web solution. So it's a web solution, the end-users don't install anything on their boxes. And in terms of the deployment, there's not really a deployment that's being made by the customer and the customers’ end-users. So all they do is that they sign up for a service and they access that service through their web browsers, and they interact with the UI of the solution through their web browsers, and they can access it anywhere. However, there are also other solutions like API-based solutions. You can expose an API with no UI attached to it, and now you can expect your customers and customers’ end-users using their own user interface and methods. And the customer might be developing the user interface, but you can still be providing the service behind that API as a SaaS solution.

Another example is our own Office 365. So Office 365 is exposed as a SaaS solution because you as a customer don't really need to take care of let's say backing up your emails on the mail server. All you need to do is access the emails through a client, and the client can be a solution, an application that you install on your desktop, on your phone, or any other device, and that device talks to the service that's behind the covers that's serving up your emails, for instance.

DAVID: Okay. So we've got several different models of what it could mean to be a SaaS solution or different types of SaaS solutions I should say. So why then is SaaS so popular with companies that are selling their software today?

ERCENK: We can look at it from two different perspectives so one perspective is of course from the customer's point of view. All the customer wants is to run their business so, for instance, if you take Office 365 as an example, you are let's say a t-shirt printing shop and all you care about is printing t-shirts and fulfilling your customers’ needs. But you also need to correspond with your customers, your business partners, et cetera, and you want to use an email solution for it. So your business primarily being t-shirt printing, do you really want to get into the business of running your email servers? So you probably don't want to do that because your resources are limited, so you want to get that as a service. So it's very appealing to the customer so that the customers can focus on their own business capabilities and get the related services from another party, another vendor that's specialized for delivering that service.

The other perspective is from the software vendors. So software vendors by just using this method can start looking at standardizing their offering and start standardizing the packages. They start working on probably fewer places that they deploy their software to as opposed to deploying their software to the endpoints or the customers' direct access points. They can also take advantage of decentralized management for better managing diversions, delivering bug fixes, basically maintaining the overall solution.

DAVID: Based on what you're saying there, it sounds like an advantage might be that publishers or software vendors are able to roll out features across their entire customer base without having to have people do on-premise installs of things.

ERCENK: Yeah, exactly. And the customers will also magically see the improvements and be delighted for the new capabilities they can use on the solution.

DAVID: So this all comes down to selling my SaaS solution. So when doing so, I presume based on what you've said, this can even cause us to rethink our business strategy a bit. So what are the implications to the business-side of an organization when selling SaaS solutions? 

ERCENK: The most obvious implication is that now you have a new sales channel that can be primarily online. Providing access to your solution online can also bring some interesting side effects. You can start looking at the packaging of your solution in different ways so you can standardize on that. Standardizing your packages will of course create more efficiency which will translate into standardized price structures. So your customers will start understanding what they're buying and what capabilities there they should be expecting for that price that they're paying even more. And plus providing it online, will naturally translate into providing it in different geographies, so your reach is going to be more.

So just to give an example to that effect, while I was visiting my other country, Turkey, last year before COVID times, of course, I was chatting with a friend of mine at a local Microsoft subsidiary. And he was talking about a Microsoft partner that is upgrading in the middle of Anatolia in a really small town, a very capable partner putting together amazing solutions. And just because he was providing his software online and the solution online is a SaaS solution, he had customers in Singapore where he has actually no presence whatsoever, physically of course. So that's an amazing thing in the current world, the reach a software can have online and providing that service online will open lots of different frontiers for the vendors.

DAVID: Yeah. I guess the internet is your oyster right at that point.

And now, let’s take a moment to hear a very important message.

Commercial:

The Azure Marketplace and AppSource Marketplace provide opportunities to sell your Office 365 or Azure-based solutions to customers in over 140 countries giving you a new distribution channel for your products. Selling your products in the marketplaces brings benefits in terms of partnerships and collaboration with Microsoft as well as go-to-market benefits to help you be successful. To learn more, visit the following URL, aka.ms/marketplace, and discover how to be successful selling through the commercial marketplaces while generating hundreds of new leads.

DAVID: So Ercenk, going just a little bit more technical for a moment, are there different SaaS architectures, or is there really a single pattern to follow? How do we implement SaaS solutions 

ERCENK: Great question, David. Thanks for asking. The first thing that comes to people's minds when you talk about SaaS is oh it has to be multi-tenant, but I have a single-tenant solution, et cetera. The fact of the matter is that looking at my past experience -- And I should admit sometimes I'm not really proud that I've been working on SaaS solutions for 10 plus years because it clearly shows my age. But the SaaS solutions can actually come in different shapes and forms. I haven't seen a single way of doing this because there are different teams; you have different cultures within the teams; the teams use different technologies. The technologies have their own ways for dictating how the solution should be put together. So there's not one single pattern.

However, we can talk about areas that we should pay attention to things like yes, there are going to be multiple customers using your software and that will bring in the discussion of tenant boundary. So you need to consider where the tenant boundaries should be probably based on the components, looking at the components you might be using on things like let's say the most obvious thing is the data stores. So if you look at your data stores, you can decide to have one single data store utilized by all of your customers, or you can think about dividing data stores across different customers. So each customer can get one data store, or you can think about having a polyglot solution depending on your customer's situation. Customers may have different or might be storing their data in different shapes thus supporting different data models. Again, it really depends. An example of the underlying technologies you might be using Kubernetes, for instance. For isolating your solutions, you might be using namespaces as an available technology on Kubernetes for isolating your customer deployments 

DAVID: I'll just jump in there real quick. I almost mentioned this because I recently worked with a customer who did exactly what you're saying. They used Kubernetes and segmenting their customers across different clusters. So they were able to deliver a SaaS solution without necessarily having multi-tenancy. So they were able to take their existing single-tenant solution but offer it in a multi-tenant way by segmenting on AKS.

ERCENK: Great point, because that actually brings in the discussion of does that matter if you're multi-tenant or single-tenant? Because the tenant boundary may be in a different place on your component based on your existing code base, technology use, and the team culture, so it doesn't have to be the full multi-tenant way. I also dispute what multi-tenancy is. I don't believe that there's only one single way to make a solution multi-tenant; you can take different approaches.

So speaking of different areas of concern, the other areas of concern are things like auditing, for instance, and also logging your features. So logging the usage of your features is a very interesting and often overlooked aspect. Consider the fact that there is one single solution with multiple feature sets and many customers are using this across the globe with probably different patterns. Over time, you may discover that some of the feature sets are more used and more popular versus the other feature set. And it's quite possible that your initial idea of what would be popular could be quite wrong. So that being said, given the fact that we are trying to optimize on the resources that we are utilizing for providing a service, you would like to really pay close attention to what is being used more often and what is bringing in more value so that you can optimize on your resources and redirect your resources for the areas that are used quite often. So again, areas of concern are important things like using available services instead of writing your own solutions. One good example is identity providers, for instance. If you look at the historical way of doing this, is that oftentimes in the past the teams were rolling on their own identity provider solutions, but lately we have some very strong players in the field one example is Microsoft’s Azure Active Directory. So you can use Azure Active Directory B2C deployment or B2C solution for solving your identity provider needs. You can take advantage of Microsoft's Commercial Marketplace for instance, for presenting your solution to different customers or a new set of potential customers.

DAVID: So drilling down just a little bit on that Azure Active Directory point you made, with regard to Azure, presumably we can think about integration with AAD for users to log into my application. They can actually use their Microsoft identities to log into my application, yeah?

ERCENK: Correct.

DAVID: Is that required of a SaaS solution that's sold to the marketplace?

ERCENK: Good question. So this is one area that we often get some additional questions. And in this context, we're talking about SaaS offers published on Microsoft Commercial Marketplace. And one of the requirements of a SaaS offer to be integrated to the commercial marketplace is to support Azure AD single sign-on on the landing page. So the requirement here is only for the buying user. So in this case, the offer is going to be available on either Azure Marketplace as the storefront or AppSource as the storefront. So when your customer comes over and tries to buy your solution, the first thing that they will do is find the solution on the relevant storefront. They'll subscribe to that solution. Once they subscribe to your solution, the customer will come to your site as we affectionately call as the landing page component. So the landing page component on your site needs to authenticate the incoming buying user. I'd like to underline the word buying here because the customer may have different end-users, and the buying user may be one of those end-users or maybe someone completely different. Once the customer buys your solution and identifies himself or herself, then you kick off the onboarding process. After the onboarding process is kicked off, you can provision new users, and provisioning those users may mean adding them to the identity provider of your choice. So this is a long-winded answer to your question. If I switch the question a little bit, does a vendor need to implement only Azure Active Directory for identifying all of the end-users of a customer? The answer is no. And if the question is what do they have to do then? What is the requirement? The answer to that question is the requirement is to have the buying user only sign-on using Azure AD.

The next question may be what happens if the buying user doesn't have access to Azure AD or they don't have an account on Azure AD? They actually do because if they're an Azure customer, then that means that Azure customers should have an associated Azure Active Directory tenant with the Azure subscription they have. If the customer is coming through AppSource, AppSource requires an AD tenant to exist for a customer to log on. So a customer coming through AppSource by definition is going to be having an account on Azure AD tenant. Does that make sense?

DAVID: Yeah, I got it. I think what you're saying, if I could give it back to you a little bit, is that in order to make a purchase of a SaaS application, I have to have an Azure Active Directory account, which makes sense. I'm not going to be able to buy something unless I'm logged in

ERCENK: Yeah

DAVID: Next thing though is that I don't have to manage all of my users through AAD. I can, I could manage all of my users through AAD in which they would come in and they would log in with a Microsoft account, but I don't have to do that. I can still use my own home-rolled identity services.

ERCENK: Correct.

DAVID: So we touched on the marketplace already just a little bit. And little-known fact for people out there is that most of the applications that are sold through the Azure Marketplace are actually SaaS applications. So what do partners have to do, Ercenk, to sell applications as SaaS solutions in the marketplace?

ERCENK: The most obvious requirement, or maybe not so, the solution needs to be running on Azure, right? [Chuckles]

DAVID: Yeah.

ERCENK: But on top of that, if you look at the need for the integration, what do I need to do? At the highest level, an application should be available on two different channels, one is a channel that is involving the buying user directly, so we call it the landing page. So when you're registering your solution or publishing your offer if we use the right terminology in the context of the commercial marketplace, what you're supposed to do is that you provide the landing page URL as a software vendor for the offer you're publishing. So with that, using a very loose terminology here, the engine on the marketplace side will transfer the customer over to your landing page so that's channel one.

The other channel is the channel where the user is not directly involved or not involved at all. So that channel you need to set it up so that you can respond to events such as the customer's desire to upgrade the solution, for instance, to a different plan or the customer’s desire to cancel the subscription, or the customer's inability to pay. So in all of those cases, you will need to receive a notification and process it accordingly. So when you're processing it accordingly, you will need to be calling APIs on the marketplace site. So you need to have clients so those APIs are REST APIs. So you need to have clients on your site so that you can consistently call those APIs.

DAVID: Okay so API integration. And that landing page you mentioned sounds like it really is somebody is going to go through the process of buying my solution, and they go through the buy and then they get to a configure point where they want to configure the application. That takes me to the landing page that I provide as a solution provider, and they are able to input anything I want to ask them about into that page so that I can then do provisioning. Is that right?

ERCENK: Correct. So we see the landing page as the starting point of the onboarding process, and the onboarding process may include different provisioning steps. So an example is that you may ask your customer about the region the customer wants to use the solution at, the number of users, the number of devices they want to connect so all of these may mean different things. All of these may mean that you need to provision users on your identity provider. It may mean you need to provision new resources for that customer. It may mean your data retention policies are different based on the location, et cetera.

And I'd like to be very specific in the terminology I'm using here. I encompass this whole set of processes as the onboarding. I'm onboarding a customer and as the process is on onboarding, I may have different provisioning steps. But of course, the reverse is true as well. So we are talking about intake through the landing page when the customer first subscribes to your offer, but there's also the offboarding process that you need to pay attention to. So this is when you receive that notification on the other channel which is the webhook. So a customer may unsubscribe or a customer may stop paying. In that case, you'll need to roll back all of those provisioning steps. You probably will keep the data, adhering to a retention policy. You will probably wind down the resources that you spun up for your customer, et cetera.

DAVID: Okay, that makes every bit of sense. So stepping back from the tech side just a little bit, what are some of the benefits that partners get when they're selling their SaaS solutions through the Microsoft Commercial Marketplace?

ERCENK: I was actually very excited that we were getting into the technology more and then you just cut me off right then.

DAVID: [Laughs]

ERCENK: But this is still an exciting topic because at the end of the day, why are we doing this? I would love to find a world where I'm doing technology for technology's sake. But at the end of the day, we are all working in businesses, and the sole reason for a business is actually to create more value. So great question. So what is in it? What is in the store, the proverbial store here for a vendor to be on Microsoft Commercial Marketplace? Well, I would like to go back to that first example that I gave from my other home country. So that partner really does not have any presence in Singapore. So how does it happen? How does he end up selling to large corporations in Singapore most probably corporations requiring a vendor to be on an approved vendor list? Or how does a customer in such a far geographic location discover that solution? So all of this is possible through that offer being available on Microsoft Commercial Marketplace. A customer finds the solution on Microsoft's property which is either AppSource or Azure Marketplace. A customer buys the solution through Microsoft, so Microsoft is already an approved vendor. A customer sees the prices in the local currency; the customer uses the local tax policies and all of the other rules and regulations specific to that country because Microsoft has a presence. So that actually brings a lot of interesting opportunities for software vendors and especially for the startups. If you look at the definition of a startup, it's all about limited resources I must say. So startups' limited resources dictate that they need to spend in an optimized way, however, go big as possible. So Microsoft's Commercial Marketplace provides that opportunity for going big and creates those possibilities in different markets.

DAVID: Okay. That is a great breakdown of why I might want to sell there. But let's talk a little bit about the things that we might be able to do to make it a little more seamless and palatable for people to bring their SaaS solutions into the marketplace. So once we’ve made that decision to integrate our SaaS application, there's some work to be done at a very technical level at the get it done level if you will. And so we'll go there for just a couple of minutes. Can you tell us about some of the developer-focused tools that our team has put together to make onboarding a seamless experience?

ERCENK: Sure. So, in this case, our team is in a very advantageous place because we get to see a lot of different teams coming up with different business models, different team cultures, different programming languages of choices, et cetera. During the time we work with different software vendors, we start to distill some patterns, emerging patterns we saw, and we try to use those patterns to provide some samples. We also talked about the presence of an API, a REST API. REST API is delightful as much as you like to send REST calls using Curl or your programming language but after a while, it becomes tedious. So if you want to make calls, four different calls, you will need to -- if you just roll your own clients, then you will need to hand-code the same way that you put together an authorization token, the same way you serialized the request and the same way you deserialized the response, et cetera. So for making that easier for our partners, we put together a number of clients for those APIs in different programming languages. So currently, we have clients available for three different programming languages: .NET, Java, and Python. We also have a number of different samples showing how you can solve that problem of integration for the particular scenario. So we publish those clients and samples on a very simple URL; It's aka.ms/marketplacesamples.

DAVID: Perfect. I really appreciate you taking us on a quick tour of SaaS applications and how people can onboard with them. That is something that I know a lot of people are really interested in doing. And we work, you and I both, with customers every day who are changing not only their distribution mechanism but also their business models for selling in a world of SaaS.

ERCENK: Oh wait, David. So are you telling me that now we are over, and we're not going to have some coding fest, and we cannot really geek out on the actual code? This is disappointing. [Laughter] I'm just kidding. Thank you for your time. I really appreciate it, David.

DAVID: Absolutely. It's been great. And one thing I'll mention before we go is that we will of course link up Ercenk’s social here in the show notes and several of the Microsoft initiatives around SaaS. There's actually a SaaS home within Azure, and we'll get that linked up, also links to how you can publish your solution in the Azure Marketplace. And lastly, we'll definitely include the Marketplace Samples that Ercenk told us about so that we can get access for different programming languages and sample applications, all that good stuff. So with that, Ercenk, I just want to thank you for being on the show. It's been an absolute pleasure.

ERCENK: Likewise. Thank you.

DAVID: Thank you for joining us for this episode of the Azure for Executives podcast. We love hearing from you, and if you have suggestions for topics, questions about issues discussed on the show, or other feedback, contact the show host David Starr or Paul Maher through the social media links included in the show notes for each episode. We look forward to hearing from you.