IGA + SaaS = Cloud Your Way

[MUSIC PLAYING] Welcome, everybody. Welcome to the IGA and SaaS session. I'm Bruce Esposito. I'm the strategist here at One Identity. My colleague here is Will Mitchell. He's the brains behind the scene who is the lead on our on-demand SaaS products. And so we're going to talk a little bit about-- [INAUDIBLE] first one. This is what we're going to talk about. First we'll talk about why the move to SaaS, why One Identity is shifting our focus to SaaS with our product lines because of the customers, what's motivating that change. We'll spend a little bit of time in comparing what are the differences in general between SaaS and on-premise, and then as it relates to our products as well-- a couple terms that relate to SaaS, specifically as it applies to our Identity Manager on Demand product. And then we'll spend a little bit of time to dive into what Identity Manager on Demand is. How is it different than on-premise version? What are some specific things related to it based on SaaS? So give you an overview of this product. And we're open to questions. That's what Will's job here is-- because he'll know the answer to any question. So that's what we're going to do. So let's get started. So, first of all, the high level-- why the move to SaaS? Well, obviously, there's been a shift in strategy for most organizations over the past decade or so, this idea of platform as service, infrastructure as service, software as a service. More and more companies are looking to go cloud for all their environments. In fact, many companies regularly tell us they have a cloud-first initiative right. Anything moving forward, they look first to deploy the solution in the cloud if possible and it fits their needs. So that's what we're hearing for our customers. That's why we're looking to make sure we're fitting in with that. The reality is, while most organizations say we want to go cloud or we're cloud first, few are there. The vast majority of the ones that we've talked to, and maybe it's about 70% of them, are in a hybrid environment where they have a significant growing number of SaaS-based, cloud-based applications, but they also have a number of on-premise, often dwindling base of applications, and a lot of stuff in between that sits up in private cloud or part components in cloud, part whatever. So that's a big part of it too. When we develop a strategy, it is not just to be a-- well, let's just move everything from on-prem into a SaaS environment, but to be able to support customers that are somewhere in between that whole process. And you'll see that in our options that are available. So SaaS versus on-prem. Let's talk about what are the differences. Now, this is the first one here, the consumption model. So this is what we as a goal have with our product lines. And it's a little bit different than some of our competitors and the way we approach our product and SaaS. So our goal is to have our product support across the gambit of on-premise to SaaS. So, obviously, on-premise-- everything's deployed in your own environment, your own data center, with your own hardware. SaaS being the complete opposite-- it's us the vendor deploys it up in a cloud-based environment. We take care of the infrastructure behind the scenes. The reality is a lot of customers want something in between. They want to have hybrid. They want part in the cloud, part on-prem. Or they want a private cloud environment. They want to push all their stuff in the private cloud. But they don't want necessarily us to manage it. They want to be able to support it inside of their own AWS or Azure tenants or even Google. So our products support anything across this gambit as we go across. Now, when we start talking about SaaS, it's interesting. Sometimes it depends on how new cloud initiative or SaaS are to customers. Some customers are very experienced with it. And when they come talk to us about our SaaS version of Identity Manager on Demand versus on-prem, they get it. They know right off the bat what the differences are. Some customers don't. They could look at the price tag initially, and they're like-- what? Why is this? Why are you trying to rip us off? It's so much more expensive for SaaS. Because isn't SaaS always cheaper? The realities are-- there's a big difference between when you buy something as SaaS, when you buy something on-premise. And it's not always taken into consideration when people look at comparing the two products. Looking at on-prem and SaaS, if you just look it from a licensing perspective, it looks like, well, SaaS is-- it's just too expensive. But you've got to consider the hidden cost. And there's a lot of hidden costs when you deploy things on-premise, one being, obviously, you have to take care of all the hard work gets done. You're responsible for all the staff to maintain it, to do all of the management of the environment itself. There's the ongoing maintenance. Obviously, there's a training of staff to handle that processes. The ongoing patches, fixes, upgrades-- that's usually a big piece. That becomes your responsibility as a customer when you license it on-premise. There's dealing with the down times. You're responsible for tuning it, make sure it's meeting your performance requirements that you have. And then there's the ever process of maintenance and upgrades to the hardware itself, to the network infrastructure that supports it, to the security and the security systems that are also involved around it, to the database that may be required by the application. All these different components become things that you're responsible for managing and overseeing. Again, this is easily overlooked, but, behind the scenes, it all does carry a soft cost as well as an overhead to doing it. So while on-premise, having your own environment, looks cheaper from a licensing perspective, it often is more expensive when you start looking at the whole soft cost of the infrastructure and what you have to provide to maintain that. In SaaS, what you realistically look at initially are two main things. There's the cost of the subscription. So you're paying an annual fee for the product based on the number of users. And there's the implementation. That's not included with it to the environment. So while-- when you license Identity Manager on Demand, you're going to be given a working environment that's ready to go, it's not all configured for you. You still have to create your connectors and set up your users and provide all the different things that you want to do for [INAUDIBLE] request or whatever. You've got to still configure it. So it typically is an implementation cost, depending on your skill level, but some level, whether it's our services or our partners, to help you go through that process to do implementation. So there still is that cost associated with it outside of that. But all the other stuff behind the scenes, you don't have to worry about. Now, we talk about-- there's couple of key things to understand as it relates to SaaS. One is the term an Azure tenant. That's just important to know, not that you really need to worry about it because we take that worry for you, being the vendor. But this is how we deploy Identity Manager on Demand today. It is deployed inside of a dedicated Microsoft Azure tenant for you, the customer. So it's an instance in Azure with all the different components that we deploy and manage for you. SLA is a service-level agreement right. That refers to the guaranteed uptime that we provide. If you're familiar with SLAs, SLAs don't promise that it will always be up at that time. What they promise is, if it doesn't meet that requirement, you will be compensated financially through some mechanism to do that. But in reality, at the end of the day, our SLAs are related to Microsoft SLA, because Microsoft is our provider. We take the environment. We put it in there. And Microsoft provides us an SLA that they guarantee Azure has a certain amount. And then we provide an SLA on top of that saying, well, to you, the customer, we promise that our software will work up to a certain amount. Multi-tenant versus single tenant. This is important to explain because some of our competitors like to make a big deal, when it comes to SaaS, on multi-tenant versus single tenant, and so to understand what we choose and why and does it make a difference to you as a customer. So multi-tenant, you may be well aware, is where you have an instance of the software and its infrastructure typically deployed through a microservice that supports multiple customers. So hundreds, thousands of customers are all leveraging the same services deployed up in the cloud. They're sharing the environment in a sense. They still have their own dedicated portion for their data, which is just for them or whatever. But they're all sharing the same microservices, whether it be the joiner, mover, leaver processes, whatever the other access request processes and the different things that are running around in the background. It's all shared environments, multi-tenant. Single tenant is what we use at One Identity to deploy Identity Manager on Demand. A single tenant means we create an environment just for you in Azure, and it's only your services that are running in there. In fact, it is a full environment of Identity Manager. Similar if you deployed it on-premise. We have the same servers deployed in an Azure environment for you. It's dedicated. Nobody else is sharing your environment. Nobody else is sharing your resources. All of your data and everything is within your own containerized environment up inside of Azure. Now, why does it make a difference? Well, as a vendor, the reality is multi-tenant is a benefit to the vendor. As a vendor, deploying a multi-tenant makes it cheaper for us. We can support more customers on less money. So the reality of-- as a vendor, I would much rather have you on multi-tenant than single tenancy because I can obviously create a greater margin for me. That's the real benefit of multi-tenancy is there. Now, there are some-- an organization that sells multi-tenancy. What the other advantage they will tell you is-- everybody's on the same version. We constantly update it. Every day, every week, we're applying patches and fixes or whatever. And everybody has all the same stuff at the same time. Well, that might be advantageous. You might like that, the fact that every day you're getting new updates in your environment and everybody has the same update. I find-- many customers, when I talk to them about that, they're nervous about that. It's like-- I don't even-- I can't even keep track of the updates that are being deployed [INAUDIBLE]. I'm constantly having to look at what's being done. And I don't necessarily want-- I want to know in advance of what's coming down the road. I don't want to necessarily have what everybody else has at that exact moment when everybody else gets it. In our environment-- obviously, in a single-tenant environment, you get updates specific to you. But it also means you would be notified in advance any time there's a patch, a fix, or an update. And you'll be able to prepare for it. You'll be able to test with it and play with it in advance before it's rolled into production. In a multi-tenant environment, that's not really the case. In a multi-tenant environment, there's only production. Not that you can't create your own little test bed and play with it or whatever. But the reality of it is-- it's rolled out in an environment all the same at the same time. So that's the big difference. So what does it make a difference for you? At the end of the day, for most customers, what difference does it make whether it's multi-tenant or single tenant? What they care about is performance and security and ease of management. Do you really care if it's multi-tenant or single tenant? As a vendor, we care because it can make it easier for us to manage an infrastructure. But that's the big difference between those two. Again, we're single tenant. SaaS advantages versus on-premise-- and I'm going to flip this around, too, on the other side. So on-premise has a lower cost of entry. Traditionally, you may already have hardware and stuff ready to go. You're just going to license the software And deploy it on your environment that you have on there and to do that. Versus SaaS-- typically, the licensing cost is higher on the front end. So from a licensing perspective, it's more expensive. But overall, generally when you look at it, SaaS will have a lower Toad cost of ownership over time, which is what's driving this whole move and push towards most organizations looking to be cloud first. They recognize that, while it may be expensive up front, long term, it's actually cheaper for us to manage an environment in the SaaS environment where the vendor is taking care of a lot of the overhead and we don't have to in that environment. The other advantage we have often done in a SaaS environment can be the way it's sold. It's sold as a subscription, so it's financed differently. For some organizations, the way they handle the financing versus OpEx versus CapEx can make a difference on whether you can get budget easily for this project or not. The other obvious big issues of why SaaS is better over on-prem-- easily deployable. So deployment time is relatively fast because we deploy for you. We've gotten really good at having automated systems that, once you sign on board, in a relatively short period of time, we are able to have your environment up and running to be able to do that. So we're building and having it all kind of fine tuned just for you in your own dedicated tenant. Scalability is another big advantage of SaaS because a lot of the components are-- some are auto scaling, so they will automatically adjust their resources based on the demand given to them. Other ones can be monitored and easily scaled to provide you different requirements to that. And so, typically, what we do is-- we provide a license to you based on the number of users, and we'll consider [INAUDIBLE]. That's what your cost is. But then we take the responsibility to scale it. So we may have you on this level here today. And as we see your performance begin to have increased needs, we'll automatically scale it up for you. We don't come back to you and say, hey, by the way, last month, we scaled you up. We needed another 100k this month. That's not the way it works. We've set you at a set price. And then we take care of the responsibility to make sure to meet your scalability needs. And we oversee that monitoring and doing that. Upgrades and downtime-- this was another area. Again, we take the responsibility for doing this, the responsibility of making sure that it's done in a way that doesn't impact or impacts you very little to do that. We provide-- often asked about this when we get in there is how we handle that. You're provided two environments in on-demand. You have a pre-production and a production environment. So the process typically is-- when there's going to be an upgrade or a patch, we'll notify you in advance. We apply it initially to the pre-production side, allow you a period of time to test it to make sure it's going to work for you, for us to validate that it's going to work in your environment. There's no outstanding issues. And then if everybody's happy with it, then we schedule a time to roll it out into production based on your schedule and your needs too. So, again, the nice part is you have our team of ops handling this whole process, but working with you to do that. SaaS disadvantages-- there are some reasons why you won't want to go to SaaS. These are few and far between, but sometimes it just doesn't fit well. One is the fact it's internet dependent. Most organizations-- everything's internet dependent, so they have in that area. But if you're in an environment-- and there are some customers that have environments in which their internet connections-- the speeds are not reliable. So having this sitting up inside of a cloud trying to connect to an Azure data center for them may not be an ideal environment. Maybe you're in a remote location that doesn't have great internet service. That could preclude even trying to deploy a SaaS deployment. There's less control. And [INAUDIBLE]-- that's the reason why people want to go to SaaS, because they don't want to have all the control. They don't want to deal with all the headaches of managing the infrastructure. But for some organizations, they want full control, and you don't have the same level of control. You will have control over configuration and the day-to-day operations of a lot of the way you deploy the environment. But a lot of the operations behind it are controlled by operations teams. So you don't necessarily have immediate access to be able to do whatever you want whenever you want. So if your team is used to having complete access to every server and every level of access on that server, they won't have that when you go to a SaaS environment. There's less customization. And I'll talk about this a little bit later about what customization means and whether it's done or not. The reality of it is, because it's in a SaaS environment, you can't just do whatever you want to the environment whenever you want without possible repercussions. If it's on-premise and you own it, that's on you. When it's up there and our team is responsible for supporting it, well, we have to make sure that when you make changes to it, it's an environment that we can still support, that it doesn't go beyond that. So there may be limitations of what you can customize in a SaaS environment to do that. But there are actually very few. We don't find that a big issue. But I'll define that later, what that means and things to be careful of. And the confidentiality-- this really has to deal with whatever your requirements are for confidentiality. The reality of it is your data is being stored up in an Azure tenant. So how does that affect where you're at? Where is the data center? For some countries, they have to require the data center to be in their country. So you have to make sure can we deploy Identity Manager in a data center for your country if that's a requirement. And so we don't deploy in every country. I'll show you later on where we do have the data centers we support for Azure for deploying it. But that could be an issue that you have to look at is where the data is being stored. Generally in Identity Manager, you're not storing a lot of data. You're storing basic identity data or whatever. But you're not storing full employee information or records like that. So a lot of times, the confidentiality requirements don't necessarily apply to Identity Manager because you're not necessarily storing the confidential type of data in Identity Manager. At least you don't have to. So let's talk about-- so that's high level. You're warming up for Identity Manager on Demand. So this has been out for, what, three years now? Yeah, three years now we've had the product out. So we're going talk about what is Identity Manager on Demand. And it's actually now called Identity Manager on Demand Starling Edition. That just is the latest version of it. We made some infrastructure changes to it in the latest version we called Starling Edition. But the reality is-- it's the same product it was two years ago. It's just been updated with some infrastructure changes on our side. So, first of all, what is Identity Manager on Demand Starling Edition? In short, it is Identity Manager on Demand, but deployed in the cloud for you and supported as a SaaS vendor. So it's the exact same product. It is not a different version of the product. It is not a different component of the product. It is the same product. And that could be important as a customer. So as a customer, if you decide or you're already currently on Identity Manager on the premise version or you look to go that route and you're looking at the cloud down the road, you can have the confidence that the version you're using on-premise and the version of the cloud is going to be the same version with the same capabilities and all the same feature set between the two. It is the same product that we deploy in the cloud. Yeah. Architecture-wise, in short, it's the same Identity Manager architecture, but it's deployed up in the SaaS environment. A couple of things to note about it-- not everything is up in the cloud. There is a component that's stored on-premise. Basically, there's two component sides that are done on-premise. There's the Job Server, and that's there to be able to connect any on-premise applications you have. So we have to have an on-premise job server to connect your other on-premise applications. And then there's also an Administration Workstation, which allows you to access some of the tools that you may want to use for configuration to be able to do that. So that's the on-premise. Everything else-- all the other servers and components are all deployed up in the cloud. And we leverage Azure's database in the cloud with it too. And that really is an advantage by doing that, by using the Azure databases in the cloud, because they offer really a lot of unique performance features, security features, scaling features that we leverage and do that, which makes this really a high-performing deployment of our product. The reality of it is-- you will likely have a much higher performing version of Identity Manager if you deploy our SaaS version versus anything you may try to deploy on your own, unless you build it out yourself inside of Azure, which some customers may do, to do that. It still works with the other environment. So if you want to connect to all the other SaaS-based applications, then you would use a Starling connector to connect to Starling, which has all the Starling SaaS connectors. That becomes an add-on for this that you can leverage off of this as you deploy this. But in short, the architecture is the same architecture you're used to on-premise, with the majority of it sitting inside of an Azure tenant. What's new? We did come out with-- again, it's been out for three years. A few months back, we came out with Starling Edition. These are some of the new features. What was different about it? Well, it uses the latest version of Identity Manager. But the big thing was with some of the things related to the way we manage it internally. One, our deployment times were simplified because we improved the process we use on automation-- or the process we use for deploying it. So now when we go to deploy it, it's quicker. The other requirement was-- we eliminated the need for a Jump Server. So there was a requirement-- for you to be able to interact with the configuration of the system, you had to go through a middle Jump Server to do that. We still have that capability, but in generality, it's not needed. Instead, we provide the ability to have direct access to the environment from your internal environment. We just use whitelisted IP addresses to provide that access to do that. The other big-- actually, this is the big version of it with the latest version-- is it no longer includes the legacy Web Server in Web Designer. As you know, we've gone everything towards a new Angular environment. You've seen a lot of the new UI. You're probably used to it now with some of the latest releases as you go with that. So what that means is our standard deployment Starling Edition does not include the old legacy Web Server. The only reason-- that's a good thing because, long term, we're moving away from that right. So we're getting away from that type of environment, moving to a more modern web-based environment for UI. So that's a good thing. The only thing why that may be a concern is if you already currently have an implementation that's on-premise that uses that legacy Web Server, and you want to preserve that when you move to the cloud. That's when we have to talk because, by default, you're not going to be able to take stuff that you're used to in the old Web Server environment, the legacy one, and expect to see that up there. You're going to see the new UI and new environment in the thing. So for something you need to preserve-- it's not that we can't do it. It's not done by default. It would be a one-off discussion to you to understand what it is you may want to preserve, is it worthwhile to do that, and, if needed, we could deploy the legacy Web Server in that environment. At least that's what I'm committing Will to right now. Customizations-- so this is a big one. Here's the legal technical stuff right out of our documentation. I'll let you read it, and you can digest it all you want. But I'll just give you the basics on customizations. The way we handle customizations and our environment is the way most other vendors in SaaS handle customizations. If you use ServiceNow or any other SaaS vendor, they allow customizations with a caveat. And the basic caveat is-- should you pursue a customization in your environment and configure it yourself and that customization prevents us from patching or upgrading it, then guess who's responsible to solve that before it gets patched or upgraded? You. So we don't take responsibility. So because of that, we discourage heavily doing customizations. Now, if you're familiar with Identity Manager, which I'm sure most of you probably are, that's why you're in here in the first place, is-- one of the advantages of our product versus competitors-- and I've worked for several of the other competitors over the years, and I've found-- is the vast majority of Identity Manager is not customization. In reality, it's configuration. Configuration is designed is defined as using one of the tools we provide to change the behavior or feature of the product. And a lot of what we do is really centered around configuring our tool. We do heavy configuration, often through our database to do it. All the configuration stuff is fully supported. So when you get outside of that-- and they mention some of the things in there-- importing a compiled DLL, some of the old-- again, we've got rid of the old Web Designer, the legacy Web Portal. But some of that old legacy Web Portal stuff would not be able to come over and be supported through a customization, doing that kind of thing. So in the short of it is-- if you're looking to do that and you think you're going to have customizations, you'll want to talk to us to make sure we understand what you're trying to do or expect to be able to do to make sure would this be supported by us. And then if you're thinking about doing something down the road, to make sure-- is this something that's going to be supported by us? Because at the end of the day, we will not do anything to prevent you from hurting yourself and doing the customization. We provide you pretty much full access to the environment. But at the end of the day, if you customize it and you break it, then it's your responsibility or you with your partner to figure how to fix it before we can continue to support it. So that's the one caveat with customizations. The good news is-- this really hasn't been an issue for the customers that we've deployed so far. Some of them had requirement we've had to work through and help them figure out or whatever. But this has not been a big issue where we've got customer after customer breaking things or having problems because they want to customize stuff and they can't. It really has not been an issue. Availability-- so pretty much, we support deploying it where there are Azure data centers. And these are the big major areas-- North America, most of the EU, the United Kingdom, Australia, and India. We have selections of Singapore coming soon, but that's the most of it. So that's the big thing. I think the big glaring area that might be of concern to maybe someone in this room-- parts of Latin America. We currently don't have Latin America supported inside of the Azure data centers. But those are the main areas we support. Last thing is how you can get started. There actually is the ability to do a limited trial mode, like, hey, I'd like to try this out-- a couple ways you can do it. The one thing is we actually have now-- this is part of one of the enhancements we made when we came out with Starling Edition-- is to provide the ability to do a deployment through our Starling Portal. Starling is where we have all of our web stuff. Starling Connect, Safeguard on Demand-- all these different Starling SaaS products are done through the Starling portal. So you can go up there as a customer and request a test version, if you will. The important part is-- if you wanted to be able to set up a test version of the product to be able to play around with it, we can help you out with that. The first step in reality starts with your sales organization. It's not an automatic I'm just going to click on it. It's going to be-- in 15 minutes, I'm going to have something to play with. It's not quite that easy. We do have stuff that you can do like that, but this isn't it. But you work through your sales organization to let them know you want that. And then what basically happens is, is you go create an account inside of the Starling Portal. And then we will deploy a test version of it, a small version of the software, or a full deployment of it, and assign it to that new account. And then you can go in, finish the sign-up process, and you'll have a full working version like the end product would look like once you decide to deploy it. So there is the ability if you decide, hey, we're really looking at this. We want to start playing with it and look to deploy it. We can work with you to help get you a test version up there in the cloud to play with it to see what it's done. And that's it. That's the highlights over there. We wanted to leave some time for questions because I'm sure there are maybe a few questions. Thank you. I appreciate your time. [MUSIC PLAYING]