My name is Martin Kuppinger I'm principle. I Analyst Analyst at KuppingerCole. And I'll talk about cloud first and now operations integration, security identity. So all the considerations for successfully rolling out and executing your cloud first strategy. And by the way, back to the app, Jenny already mentioned our events app and linked to my keynote. There's the market for cloud backup and disaster recovery comparison of solutions in the space for, for cloud backup and recovery, which you can download by using the app.
So install the app, use the app, click on my session, and then you will find the option to download this market report for one of the areas which are related to getting cloud done. Right? So this as the, so to speak first introduction, and let's directly right now dive into the topic and as titles as cloud first and now.
So, so one of the things we, we very commonly service companies have a cloud first strategy defined.
So someone is going out and says, we do a cloud first strategy, and I've been at a couple of organizations and sometimes then reality, different quite a lot from the sort of this password thing where it's cloud first. But what is it really about? And if you define a cloud first, rich, there are a couple of things which need to be understood. So the first thing apparently is defining what is cloud or what is perceived as cloud in the definition of your organization.
So is it only public multitenant or probably not? Or is it everything which doesn't run in your own data center? You need to define it. You need to have a definition for that. You need to have criteria for exceptions. So when not to use something you define as a cloud, what are the alternatives and when to use them, otherwise, you'll always have this discussion about, oh, but we can't shift this service for whichever reason.
Many of these reasons are not very relevant, but anyway, you will have these discussions, define it from the beginning, define the migration strategies.
So how to shift from where you are today, which still might frequently be on premises to where you want to be. And last, but least you need to, how to measure the cloud risk and to how to compare it with the state. One of the things which are frequently done wrong with cloud risk is that companies look at what is the risk of the cloud. And they say, oh, this is a big risk, but they don't compare it with what they're doing today. And so it's a very unfair thing, which is very frequently still done.
So you need to compare the state to the cloud risk, to understand where the risks are, to understand your mitigations, to mitigate risks. And then very frequently will look quite different because one of the simple things is large cloud providers, large service providers usually have far bigger teams for security than you in your organization ever will be able to afford.
So they have this strong specialized teams, and this is really a difference thing here. So when you start looking at this, then as I've said, one of the first things is to understand what is from your perspective with cloud.
So cloud or new cloud, and let's look at for criteria for your definition. When you look at the operating environment, one criteria, which defines from my perspective, whether this should be perceived from as a cloud or not is the number of tenants. So how much is it individualized or standardized, and the other aspect, which is not only the number of tenants, but which is also the decree of standardization. So is it an environment which is really running for your organization only very, very customized to your needs, your specific applications, etc.
Or is it something which is highly standardized, such as office 365 or Google apps or, or others where, where every tenant at least builds at a highly standardized environment.
So you could create a picture and I love these metrics and scattergrams where you say the number of tenants could be between one and infin it. And the letter of standardization could be between individual and fully standardized. And then when we look at various ways for operating it, apparently our traditional on premises, it would be in the lower left edge as well.
But also if you do outsourcing trust, so having someone who runs it, it is still individual and very much for one to another and also the private cloud, if it's self managed. So if you say, okay, I trust, build my own private cloud. It still is something which is pretty much in the lower left edge. Some parts of that, apparently. So the infrastructure are, but most of it is so a managed service provider model model goes a little bit more to the goes up a little more and more, a little bit, little bit more to the right.
So managed service providers usually serve a couple of customers with some degree of standardization, but very frequently also it's still really pretty individual. And not that many tenants. If you look at public or private, single tenant clouds with multiple customers, and if you look at many of the SaaS services today and also the past service platform as a service services, many of these are factually single tenant deployments. So I just take my history is an identity access management. So if I look at many of the identity access management tools, they are factually single tenant.
So per tenant, there's an installed there's some in the cloud, which is operated done, right. That's okay. And I'll touch this in a minute. So then we, we are far more to the upper right edge. And so the traditional public multitenant cloud, such as office 365, etcetera, this is where we have more or less potentially UNFI, not really unfit, but very, very many customers and it's full standard.
And what you need to do is to understand what is from your perspective cloud or no cloud.
You can shift this line, you can shift it far more to do the lower left touch, but define it define also maybe levels of cloud where you say, okay, this is would be my ideal target. Save not necessarily it's for everything, it's a public multitenant cloud. So it also might depend on the use cases on the types of applications where you say, this is, this is where I want to end up, but define it, understand it, make it clear from the beginning. So set the rules. The other aspect here to look at is tendency apparently. So is it fully multitenant is a single tenant.
And it's absolutely okay to have applications which are run in some way as a single tenant application, if they are well managed, which means microservices container based are deployments apparently.
And the ability that all your customizations and configurations are well segregated so that the provider of that solution can update all the tenants in an automated manner, which works quite well for even hundreds and thousands and maybe tens of thousands of tenants, if done, right? So it can be done, but you need to understand it. And sometimes it might be, you might feel better.
It might be even better effectively to be more on the single tenant side and last least there's elasticity. So one of the things I expect from everything which was called cloud, even in the own, maybe more broad definition, taking into account more traditional models. That is a licensing model. The paper use model. That must be something we have, but the very first step is start with the definition of where do you want to end up and start with the definition of the exceptions when not to shift an application to it.
And these exceptions should be very constrained.
So when we look at the key success factors for cloud first strategies, the first one it's management and strategy, so this must be a strategic move and there must be management commitment. So as I've said, which services to move, how, when and whatnot, your organization must change. It must follow the strategy. If you say, we go cloud first, then apparently you have less own data center. Things are changing and also services will be operated sometimes in different ways.
It's a great opportunity by the way, to get rid of some of the silos you have, because you will not need some things you won't need anymore. Other things you will need more than before operations, you need to have adequate operating models. And these models differ from the type of cloud, from the type of service, there's always a tenant and a provider responsibility.
You need to understand that for every single service, what is your responsibility as the tenant? What is their responsibility as the provider?
And you need to, to have your operation in place for everything, which is your responsibility, but also potentially some audit for what is the provider doing? You need to select the vendors. And basically it's the same, like selecting auto vendors. It do it. So roughly understand the cloud risk. This is part of it in the risk assessment, vendor selection here go very much hand in hand and due it in standardized manner. It's a very, it's not a complicated thing to do.
And we have, for instance, a standard approach for this cloud risk assessment, which can be very, which can be very, very quick, depending on what you want to do, but it allows you to understand the risks, the mitigations and act accordingly security is an important aspect for sure.
The cloud itself is not insecure if it's done right, but the way you do security is changing. And when you say cloud first, that is the thing we just done more to security. You implicitly say and inevitable, say zero trust. Because then the logic is that you have devices which access your services.
You don't build on the internal network anymore. So you don't build on the parameter. So you need to change the way you do security beyond just the cloud security. You need to manage your identity as well, which is complex, but you need to have one view of identities across all the cloud services, across all the users and across all the operating models. You need something, we call it identity fabric. And there are a lot of recordings from a previous virtual event. You can look at, so understand what it means, integration.
So these cloud services are cool, ready to use.
Perfect, but you still need to integrate within. So you need to integrate cloud services with other cloud services and on premise services and premise applications. So understand the integration need, understand how to do it again. Elasticity and scalability are key as well as pricing and licensing. If you look at these factors and if you take these into your account, your shift to the cloud and your execution of a cloud first strategy. So making this big password reality will become successful. What is your roadmap to, to the all cloud it done?
So it's not done by using the credit card for purchasing a SaaS service. You need to do a little bit more and you will end up with more agility, but agility always requires frame in which it happens and defined environments. You need to have your definitions of what to do, which services to shift, which type of cloud, what is allowed, what is not allowed cetera.
So define start with your definitions, what you mean by it. Cetera. I touched this already. Also understand your limitations. If you're a manufacturing business, you have a factory floor on premises.
So not everything will be cloud organized, adapt your organization. I, again, already touched this point.
Architect, understand the architecture. So does, how does your future it environment at a higher level look like it looks different than all the data centers to or really have in place today, then build that sounds simple, but it isn't because it's about management hybrid, cloud management, management of different types of cloud services, security, identity integration, all that stuff you need to prepare for that. You need to test the overall framework work, and then you go into the various services. So you select the service again.
Then you test that service, you build it, you customize and integrate you do the migration, follow a standard growth feature for that for selecting your cloud service for checking the risk for create your own standard methodologies, your own standard ways to do things.
And then finally you run it. And apparently you should go into a continuous improvement of these services. And in some way, we have a waterfall of very traditional part, which is setting the frame. So this is something you do, you should do it quickly. You should do it well sold out to start.
And you have an agile part which is done where you do small steps in your migration shift, that service shift, the next service, maybe only shift parts of services relies that service by a new cloud service or by set of SaaS services. So that is then the agile part of it, where you step by step, make your shift into cloud to really execute on the cloud first strategy. There's some specifics to considering to take into account. When we go with this overall plug first strategy, and as I've mentioned, there are some things you can't that easily migrate.
So depending on which type of business you are, some parts of your, it will remain hybrid for at least long, maybe forever. So, as I said, manufacturing is a very common example, but also if you look at some of the traditional parts of, for instance, finance industries, like take insurance companies, which very commonly have still a mainframe running with some very legacy code, which they still need because this code is the foundation for maybe certain types of life, insurance contracts, or adult long running contracts. And it'll remain active for quite a while.
So at some point maybe everything has shifted, but it will take its time. So don't ignore the reality when you go for a cloud first strategy. And that is again what I've said at the beginning, you need to understand what are the exceptions, keep them small, but understand where you might need these exceptions.
So sometimes you then still, so some services might not be easy to use. So there's a term edge computing I'll touch on a second, but apparently lift and shift is an option for certain types of services.
You just run a virtual machine instead of running in your own data center, you run it on infrastructure, service platform, okay? But not everything will work that well. And apparently then your own talent responsibility for lift and shift is far bigger. And you will not have all the advantages of cloud. So understand what you do, what it means and where to make the shift for on premise and where to remain on premises. So where do you end up hybrid?
And there's then the option of edge computing, which is the idea of bringing computing resources closer to the location where it's needed to reduce latency and increase availability.
So cloud services in services in some way are moved to the edge of terminal network or internal services are moved to the edge of the network for better access from the outer space for, for mobile access.
For, I use cases, etcetera. This is helps in, in certain complex hybrid scenarios to get, get things done better. So look at these concepts as well, and to close it some key takeaways, cloud first logic paradigm, it's more than just public multitenant, cloud defined types of clouds you use when you are allowed to use when, for which use cases, etcetera, you need clear guidance, you need an it reorganization and you need a strong backbone and management security. That's not just using your credit card to procure SaaS service.
It needs a plan to go at trial and edge computing will become important. That's it for my side. Thank you.
