Here we go. There we go. Okay, everybody nice to see you all again, some familiar faces. So today we're gonna talk about applying microservices patterns and best practices to identity management and how that applies. This is just kind of a diversion. So this is me looking at the tweets about the ID pro meetup in the Augustiner last night and thinking, oh man, I'm early missed out. So how many of you saw this headline recently? Very recent headline, very eye catching, especially I'm a previously an evolutionary biologist. So I thought, wow, extinct species of bird comes back from the dead. Anybody see that one? So I thought immediately, I thought, you know, scientific wheels go in motion. And I thought there had to be only one, one logical explanation for it. I think we all know what that is, but so not obviously not that. So what, what happened was that there was a, a species of bird colonizing, an island from Madagascar, and eventually it would evolve flightless because in that ecosystem, in that landscape, the one of the optimal selection models was for a bird.
It could succeed better if it were flightless didn't need to, didn't need to fly, didn't have predators. So what happened was when the sea levels would rise, the birds would go extinct. The sea levels would fall. Eventually the same bird from Madagascar would colonize the island as flight birds that flew, but the optimal niche or the optimal model for them to pursue in that environment was sightlessness. So it's not the same bird that came back from extinction, but the same, same generation. So what does this point to something in, in, in biology, we call the vacant niche hypothesis that within a landscape, within an ecosystem, that it's not a random role of the dice that there are. If you imagine these niches, where there are optimal sets of traits for performance to succeed in an environment, those niches exist. And then eventually whatever type of animal comes in, whether it's a lizard, a frog, a mammal that they will all evolve within that landscape into those optimal inches.
So if you look at north America and the Wolf at top predator and its ecosystem, if you look at Australia, the, the Tylaine, the, the, the Tasmanian Wolf or tiger, it, it, it evolved from a completely different stock, a hundred million years separated by genetic distance into something that was almost the same because in an ecosystem that was one of the optimal niches. Same thing goes, if you look at a mole very, very different than, than a top predator like Wolf, but there is a niche clearly in an environment where a, an organism, an organism can succeed. If it models itself and fits into those adaptive traits in that environment. So what does this have to do with security, with the digital landscape? Well, if you imagine the digital environment that we're we're walking into right now that we're entering, we companies are scrambling to transform themselves from brick and mortar into this new digital landscape.
Imagine it as a, a new island chain forming a whole new land formation within that environment, there will be optimal niches for a business to occupy. So the question is, how can your organization or your business find those niches faster than your competitors? Because again, if a lizard could take the same niche as a mammal, so you need to be into that niche before your competition and find out how to conquer this new digital landscape. So digital transformation is a huge topic right now. If you look at the stats, almost all every organization we talk to, even if they're in a commercial industry, if they're in a non-profit industry or governmental organization, they're all going through digital transformation, how can they get closer to their customers? How can they be more consumer focused? How can they use the digital platform to engage with their end users?
A T study found that organizations that underwent digital transformation on average, we're 28% more profitable. They had longer customer lifetime retention values and more sales per customer. So it's, it is exceedingly important right now to get into those optimal digital spaces before your competition. If you look at the McKinsey model, McKinsey, doesn't call it digital transformation. They call it basically a perpetual evolution, which is kind of like the, the previous gentleman said, it's really something that even if you're already transformed at the digital company, you have to continually reinvent yourself. You have to continually reinvest and, and get creative to get closer to your customers. So if you look at, they looked at McKinzie, looked at the it landscape, and what, what are the implications on your infrastructure? The way your organization manages software services from an it perspective to handle this perpetual innovation or digital transformation.
And some of the key things is that you need to emphasis on decoupling applications. So instead of having app applications that this one has to talk to this one, and it's very tightly bound that if this changes, this application instantly breaks that you need to, decou one have these looser relationships, more standard API interactions at a distance. So that as long as I present you, this data in the format that you expect, my application can change on its own. It's ni tightly bound to your application. Also lightweight connections. So an emphasis, not on the traditional SOA model with enterprise service, bus and heavy, heavy integration, but more just on loose restful API interactions. Also a focus on DevOps that you need the, all of the team to focus on not only developing the software and then throwing it over the wall for testing, and then they throw it over the wall for deployment and management, but a DevOps model where you're continuously developing, operating, deploying to put software out there faster, and fewer handouts mean better quality, and then looking at your it infrastructure.
And this is definitely the trend of the cloud, is that treated as a complete commodity, do not get heavily invested that you're gonna, you care so much about the it infrastructure and that there, they even say to separate out that team so that it doesn't basically contaminate your, your software group, which is focused on the, the consumer journey, the consumer lifecycle and rapidly deploying software on commodity infrastructure. So some of the buzzwords out there as you're moving towards a more microservice model, it's all about containerization. So making your applications that are, can be deployed across Docker, Kubernetes infrastructures, which allow you to scale them very rapidly and elastically with less hardware orchestration, which manages the software, scaling it out as needed. And then of course, microservices, which we're here to talk about. So microservices, you might have heard the term probably many, many times since you've been here.
It's definitely a, a buzzword this year. You see, if you look at the news, you'll see it everywhere. Now, last year, when I was talking about microservices, we had a panel on serverless computer computing, microservices, and I said, basically, it's here. It's now it's happening. We have to react. A lot of the stairs I got were kind of like I, I said that next year we'd be eating tide pods. And that, that would be a normal thing. But if you look at the statistics, adoption of container based, microservices has gone through the roof in, in a very short time, it's become the norm and all the vendors are deploying software quicker, faster across any infrastructure across any cloud.
Microservices is one of those things that basically once you get it, once you, your brain clicks and you see the difference, it's you can't unsee it anymore. Once you see it, you can't unsee it. You realize that there there's just, there's no going back. And my microservices gestalt moment was basically when I fired up on my windows, 10 laptop, I ran a few commands and all of a sudden I'm running SQL server 2017 on Linux, on my windows machine. It's like at that moment, it clicks that now the infrastructure doesn't matter. It's portable. It could be deployed anywhere very quickly, even by somebody like me, of course, instantly. Well, not instantly, probably a little while later, the alarm bells kind of went off and said, okay, if I'm a user and I'm a local admin and I'm on the network and I have IP access to other machines, I can basically launch almost anything on my machine. I could be launched my SQL server, a web server. I could be launching something from a, a repo out there that is running malware scans on the network. So definitely very dangerous thing, a very different, different mindset, but it's a change that's here and it's, it's not going back.
So what, what is a microservice? How, how many people are using microservices in their enterprise today? So at least half, so looks like it's matching the statistics. That's good. So basically in the, the old world, the monolithic world, which is what the bulk of our applications are. I mean, we all wanna live in a microservice world, but, but we're not there yet. You still have legacy. You still have your, your line of business applications in a monolithic world, the application you had the traditional application stack, you had the user interface. That was the same application or same code base that talked to your business logic layer that talked to your data access layer. And typically you had one big monster database. And when you needed to deploy a new version, it all had to go together. You couldn't modify them independently. So when you deployed it, it was slower.
It was riskier. You're more likely to break something and you have to do a lot more testing. So it's like a big beast. That's very difficult to move forward because it's a risky step every time you do in a microservices world. If you imagine that, you know, each application function is independent. So it's broken down to where a microservice does. One thing does one thing. Well, and then it can be communicated with, from other user interfaces or other microservices via just standard, lightweight rest APIs. And it, it can have its own release cycle. It can have its own team, its technology agnostic. This team can use a different technology than this team. It doesn't matter because the, the generic interfaces of how they talk to each other, kind of normalize that. And also it can have typically have its own database or its own data store that way it's as, as few dependencies on other systems as possible.
So you can move a lot quicker. So some of the characteristics, I borrowed the little picture on the right from Microsoft, nice reference application, but it shows a typical microservice infrastructure. So your identity component, your, your authentication might be a microservice. Your authorization engine might be a microservice. And if you're looking at a shopping cart app, the search would be a microservice. The basket would be a microservice. The, the marketing would be a microservice that way. Let's say that the search is something that leads to more consumer transactions, finding the product, allows them to buy the product. So you want a different team that has the flexibility to use whichever technology they want to iterate very, very quickly, because that's gonna be a key differentiator part of your value proposition. And you don't want that search team to always be bogged down to where they can't deploy until the basket team deploys.
And they have to wait on the order team. And then everybody's in this big database where you're checking in changes, and then you have to retest everything which takes two to three months. You want that search team to be able to deploy every 10 minutes if they had to. I mean, you know, that's, that's really the model. So the characteristics of a microservice decentralized, definitely everything is loosely coupled, decentralized, nothing really decentralized or put together. If it's not necessary, independent, each can be changed independently, do one thing. Well at polyglots basically the idea that you can use any type of technology you want. Polyglot persistence means that this microservice, if it's better to use a no SQL database, it can use it. This one can use a sequel database. So you don't really have to have to care about that. Black box means that nobody needs to see really what's in the microservice.
It's just gonna expose some functionality. And then the whole DevOps mindset that you build it, you run it now. An important thing here on the microservices is not just the technology. It's not just the tooling, it's really a cultural change. So, and, and I would say that, you know, even without the microservices, the cultural change is needed in order to achieve digital transformation. Conway's law says that the software and organization builds is directly a mirror of their organizational structure and communication style. So if you have a big top down organization, you're gonna build big top down software. So really you have to restructure into small teams in order to have build software that is faster, lighter, quicker, your team and your organization and communication has to match that. Bezos at Amazon has a rule called the two pizza rule that nodes software teams should be larger than the number of people that could be fed by two pizzas.
If you, if you need more than two pizzas, then your team's too big, it's gonna be slow and you're gonna be tainting the, the design. So do micro our microservices required. It's a quick story. Spend a summer in Zurich. Everybody goes swimming in the evening. If you could, in, in the limb mat. And it has a pretty fast current. So if you're going downstream, you can just jump in float downstream. You have a great time. Some people were brave souls, they could swim upstream. And they were like endurance athletes. I would watch them go by and you, some people can do it so you can do it, but it's definitely the hard way to go. And it's it's for only a few. So common microservices patterns that we can look at. One that we all know very well, federated identity, the idea that the identity is external, that your microservice consumes the identity, that you're not replicating identity management in each of your microservices gateway routing.
You really can't do microservices without gateway routing. Cuz imagine that you have hundreds of these microservices, you're not gonna have your web applications or your mobile applications making direct connections to hundreds of applications. So naturally you're gonna be routing through a central point and that allows you to implement gatekeepers. Gatekeepers, allow you to implement some security, some filtering, and some other logic anti-corruption layer. We're gonna talk about and then sidecar. So sidecar is probably the most important concept and I'll come back to that one in microservices. And it's the idea that if a microservice is gonna be slim and do one thing, well, then you don't want to build into your application, your microservice logging, anything that you don't need. So, and the idea of a sidecar is that in your microservice environment, they're almost as if each microservice is running on the same physical system, like their processes in, in a window server.
So you can say my microservice is just gonna log out to the file system and another side car will swoop it up and send it off to my log server. So the idea that you can decouple functionality and have specific side cars that run in any technology you want that add on filtering or add on ingress control. So the idea that it, your microservices, there's some sidecar controlling access in applying security policies, authentication authorization. It lends itself immediately to a zero trust because in a zero trust model, all access is proxy. There's no direct access and a microservice deployment. Basically you have your ingress controller, which is controlling everything that comes in. They can talk to them to each other internally and nothing else gets in. So it's naturally a zero trust model as a side benefit. I'll speed up a little bit. So identity and access management really represents in the microservices model.
One of the concepts, an anti-corruption layer. So it's the anti-corruption layer is designed that you have other systems, legacy applications, or external systems that have their own models, and you don't want to corrupt your internal model by ma modifying it to fit those systems. So it's a layer in between that translates. So how does that apply to identity and access management, basically that you can have your own business processes, your own logic, your own joiner mover, lever, your own permissions or authorization model, and the identity management system should be that corrupt anti-corruption layer, that it translates your model into the external systems model that they can consume, or they know that way you can manage your security in one spot, you can manage your permissions in one spot and you're not building in, let's say this sales force permissions model into your identity management system and this other model or changing how you would do your business processes.
So I'm gonna skip some of these just because we are out of time. Just one important thing in the authorization cloud, native authorization model, we have all these microservices. You can centralize authorization like at the ID there, where at the ingress control, you're performing your authorization decisions, but in a microservices model, it's typically more distributed to where each one can independently talk to its own sidecar to perform authorization decisions for scalability and, and for decoupling. So recommendations, it is a do or die proposition. I'd say focus more on the cultural transformation. One thing that's painful is that type of there, but you need to, you may not be able to use all of your existing team. You might need to get some new blood and then sprinkle your existing team into these new teams kind of diluting. The, the previous model was people who are more used to working in this model. That way, if you're gonna transform the organization, you really need to have some fresh blood typically. And of course, think about the, the inside out model that I didn't access management. You can't count that you're gonna be able to push and talk to every system they're they're in these little bubbles with ingress control. So you really need to think about how can I run things inside that will reach out, pull the information necessary, or, or submit the information necessary and then perform central decentralized local enforcement, local local actions.
And that's it.
