Martin Kuppinger - Microservices Architectures: Making IAM Hybrid

We had, we have a small switch in the speaker list for today, which means that the bland speaker number two from the printed agenda had to cancel for Nial little. So chef Jonas will talk after me and I'll do another presentation right now as announced, which will be a little bit different from what original was planned. But I think it's a super hot topic. These days. It came up in a couple of advisories. I had over the past weeks, it came up in a couple of vendor briefings I had over the past week. So it seems to be something very trending here. What I wanna talk is about the impact of what we see emerging in microservices, architectures on the field of IM so making IM hybrid. And so what do I, what is the point behind that? So the one thing is, yes, we see a trend towards the cloud.
No doubt about it. And that might also go somewhat faster right now than some people still expect. So we see see more, more open as even over here in, in the sort of more cloud reluctant countries. On the other hand, we also have to, to, to understand that the reality of most businesses or of many business, not most but many businesses is a hybrid reality. So if you look at banking insurance course, if you look at it, manufacturing your factory floor by design by default will remain on premises. So at the end, despite all the strategic things hybrid is reality. That's one part, and there's also hybrid reality of identity management. So where we have a couple of things we are, which are more focused on the employees on the, on premise side, et cetera. And so this is basically sort of more, more my starting point here.
We have a hybrid reality. We need to deal with it reality. And for most organizations today for their identity management, it means they are somewhere in between. So they think about when I do something new, when I add something, when I renovate something, should I do it in cloud? Or do I better do it on premises? If I do it on premises, what does it mean? Can I move to the sort of gradually migrate to other deployment models? And there's something in between purely on premises and purely public cloud. There's, it's more a continuum. So how can you deal with that continuum? And this is from what we see, this is a major challenge for organizations these days. On the other hand, we also observe is that more and more things are moving to microservices. I trust copied a little bit out of the Wikipedia regarding the definition of microservices.
So as, as always, it's nothing fundamentally new. So service oriented architectures, that's not, not that new anymore. And before that we had core buy and some other stuff. So if you're long enough in industry, you might have seen other things before, but in fact, it's going to smaller services, well as isolated, loosely, coupled lightweight protocols and all that stuff. And so I think there's a lot of logic behind going down that path. And so what we observe here is in our emerging trend. So when we look at the left hand side of the slide, it's sort of this traditional monolithic IM architecture running on premises. So it might be less monolithic or more monolithic, but at the end of the day, it's sort of, you buy one big product and you run it on premises and that's it. And then on the other hand, we have all this IDAs or cloud identity management stuff.
So all this stuff, which then runs somewhere in the cloud, which sometimes is more microservice, sometimes is more monolithic. So they're a little bit different ways to do it, but that's the other thing. So the middle thing is also something we see and what we currently see merging. I think this is the interesting part where the entire storyline starts more or less. We see right now vendors picking up the microservice approach and say, oh, we are modernizing our traditional applications towards a microservice approach, which potentially allow us to place microservices in different deployment models to be more flexible on that. So this is something we see. And I had a interestingly, you know, as an Analyst, you sometimes have these phases where in a short period of time, a couple of vendors call you and say, oh, we have invented something fundamentally new. And in that case, it's microservices a couple of years ago, it was, oh, we have identified that we, if we do access governance, we might provide information about all the required changes about whatever revocation of entitlements.
We need to provide it back to the provisioning. So there are always these faces and then some things apparently become a trend and this appears to become a trend. And there's a need for that. There's a clear need in the business, from what we hear from our, from our organizations out there. So what does it need for sort of a microservice IM first of all, we need a good architecture. So really understanding these are microservices, small services. So not I had one vendor telling me or answering my questions on how many microservices do you have currently? He said one, no, that's not microservices. I don't UN Wiel the name of that vendor here.
It's about really having microservices. A lot of them, small ones. That is the idea behind us. And it's about a clear functional segregation of these services. So you need an architecture. You need to understand which services do you have. You need to have a consistent out of light with APIs, but you then also need to clue this back together to make it manageable, to make it secure. So this is in a nutshell, what we really need here. So how could we do that? I have three slides right now showing sort of the options and a little bit also the evolutionary path we are seeing here. So the one approach might be, and that's what probably a lot of organizations will at the end have. At least at the beginning is sort of microservices in a box, which means we have, in fact, that one tool we purchase from a vendor, which internally is microservices, but which we still look at as being one.
So usually which exposes API. So as a customer, we don't look at the individual microservices, but our focus is more on, okay. We have a solution from that vendor. We know it's microservice, but at the end we treat it like a standard thing. So it's, they deploy the same way as a standard mono monolithic application, let the vendor care about security and all that stuff. And we might integrate it with the outer space from there. So that's basically what we do here from that on that's where things really be started, become interesting. We might say, okay, we have an option to start running some of the microservices in different deployment models. So we might say, okay, the access governance part is run more on our own premises side because most of the target applications are there for now, or we have other reasons to do so while some of the things which go more into consumer identity or which go into trust the entire Federation space, run more on the cloud side because if people come in from outside and go out to cloud services, it doesn't make sense to route them through our enterprise.
In that case, we get more flexibility. And that's where things really start to become interesting because it opens us a migration powers between the various deployment models, but it might then start requiring some extra API security, some extra management capabilities, but from an API perspective, it's still rather monolithic. And then we might say, we, we go more consequently towards what the potential of microservices is by saying, okay, we, we have that. It's a set of microservices. It might be even different applications. So, so we might have, so the, the, the blue boxes that are other types of applications that might be whatever your service now, which has some services, which you integrate with the identity management services, using lightweight APIs, it might be whatever other type of applications. So you really treat this as a set of microservices and you decide on which microservices do I need to fulfill my specific requirements. So flexible deployment, define capabilities, integrations with other services. You have to think more about it, which service delivers, which capabilities, what do you need, how to secure that. But it also adds flexibility that new capabilities here. Obviously we need them to think about API security and management, because we need to secure that new world.
I don't want to go too much in detail. I, I'm pretty convinced that we have some other sessions around API security during the conference. What we need clearly is we need a way to protect this, to protect the communication, to protect the APIs you used to communicate between the microservices within our future IM and the outer space. So there's an important role of that. And we need to look at it. It's a separate capability, so to speak, we need in our environment. And we need to start thinking about what, which services are provided by which so, which sort of use cases are supported by which at the end microservice and technical building blocks. So in that case, the microservice would be down more on what I call building block here, and there are specific service and we need to understand what do we need? Who does the, who, which of the services provides it and figure it out.
And that also means to, in, in a nutshell that we, today, when we look at the, the traditional way of, of identity management, we, when we look at it, then we identify that a lot of the capabilities potentially are delivered by different, big tools. We, we might buy a consumer identity management tool, which overlaps to some extent with an identity as a service or overlaps with our standard on premise provisioning, access governance, et cetera. So we have a lot of overlaps potentially with microservices. We might start thinking about how can we reduce these overlaps by saying, okay, that microservice is used for that type of capability so we can reduce the complexity and the overlaps we have in our, in today's environment. This is from my perspective, a great potential, but we also need to be aware that we have to put in a lot of thinking regarding which use cases do we have, which services do we need, which capabilities are required by our technical building blocks and which building blocks.
So which microservices and which combination do we need. So obviously there's more architectural thinking in it's a little bit. It requires more thinking ahead than trust saying, oh, I by that tool from that vendor, and it will potentially do what I expect. It'll be probably more, a mix. Things are becoming a little bit more granular, but also adding more flexibility and reducing overlap. So what are things we need to consider here? And I think there are a couple of aspects which are of high importance. We need a good enough, at least enterprise architecture and IM architecture. So architecture becomes more important when we move to approaches like a microservices world. So there's a good reason that a predecessor of microservices, which was so are service oriented architecture has the a, and the architecture and its name, because it's about an architectural approach. So we need to understand these relationships.
So which services, which capabilities are provided from wealth, et cetera. We need also to look at, if we have various vendors in there, if we have various integration points, how do we isolate proprietary APIs? So if we start integrating, we are IPAs, we always need a way back. We need a way to switch the vendors to switch to microservices. So we need to think about clear segregation of layers, isolation of I APIs, things like that, which is by the way, a standard practice or should be a standard practice, maybe better said, we need to have architectural gates for all these things we build around that we build based on top of this, we shouldn't end up in programming, but we should focus on orchestration. And we clearly need very well sort out and well defined guidelines for all the people who are working around it.
So it's something we, where we need to understand what it means. So we shouldn't trust go out and say, okay, we do that because it's cool on this hype. So we need to understand the impact and what it really needs to make this a success, but there's a big potential to get more flexible. Basically, when we look at this, the fundamental underlying question around microservices is this so microservice and the containerization, which is related to that immediate innovatively, is this the strategic architecture for entity management, a lot of text on the slide, but I think it's good enough to read also from the back of the room. So potentially we can move away from the monolithic architectures. We get more flexibility for hybrid deployment models. And I think there's a big, big potential in that. And there's a good reason that we see this as an emerging trend also from the vendor side and an emerging request from the customer side.
Currently we are a little bit in a problematic situation because there are few products in the market, which really are where they hopefully are in a, in the future. So it's not really that most products are well sort of microservice ever really microservice architecture. It's, it's a migration starting. The challenge is if you today want to sort of renovate your identity management, it means in fact that you usually will not be able to say, okay, I immediately make this switch to, to brave new microservices world, but there might be an interim step where you say, okay, I choose that product. I know the vendor has a clear strategy. And then at some point, a major migration will come where there's more microservice in, so to speak. And that might be at the end the past. So what, what, what I would say as a recommendation to you is look at that concept, ask your vendors about their strategies, work on your, on the architecture side, and look at this as a very promising model for your future identity management, because it gives you more flexibility.
It reduces overlaps. It allows you to better integrate within identity management from also from various vendors and with other types of services. So it's, I would say it's a very interesting evolution we are facing here, and it's really worth spending time on that. And yes, it's architecture, it's there some part of orchestration development coming in, but it's really worth to spend time on this topic. And I'm very convinced that we will see far more and hear far more about it within the next one or two years. Keep it in mind when you are starting to run away to review your current identity management. Thank you. So maybe let's look at, at whether we already have some questions no, too early in the morning. No, of right. There is an app it's equipping a coal app, and then you can launch the EIC app. The reason for first needing cooking a coal app and then EIC app is that some vendors like
Apple don't allow to have too many different sort of relatively similar apps. So we had to go for that approach Cola lab, and then you can launch EIC app, and there's an area per session where you can ask questions. So for the next sessions, please ask the questions with that. I want to directly hand over.