Plan A: Reduce Complexity in your Cloud Native Environment (there is no Plan B)

Okay, thanks for the introduction. I'll tell you the Genesis of this session. Two years ago, I did a, a document research document on dynamic access management. And back in January, Martin asked me to update it and we've just released the policy based access management document.

And it's, I was absolutely amazed at what has happened in two years. So what we're gonna talk about today is cloud native and what that means in terms of complexity in how we reduce.

I dunno, whether you heard Martin talk yesterday about complexity, we are gonna be looking at how can we reduce the complexity in this space? Now we are few in number, so I'd like to make this interactive, okay. There's people in the audience said that no more about this than I do. So stick your hand up because when we leave, I want everybody to say that was worth it. Okay. So stick up your hand. If you've got any comment or questions as we go along in terms of the structure, I like to do things structured.

We have initially, we're gonna talk about the problem, you know, what is it then we're gonna look at what does that mean? Okay. There's some imperatives that we've gotta recognize. And then finally, what sort of response can we put together? So the problem is we are accelerating at war factor one to catastrophe when we adopt cloud native, unless we do some certain things. Okay. So what's happened in the past is our initial foray into the cloud was a Lifton shift, right? We would take a app from our on-prem. We put it on a VM in the cloud and we would say there we're done.

The problem with that is in many cases, we got a shock because we got a big bill from the cloud supplier because we'd had autoscaling and for some reason or another, our apps scaled up and, and cost us a lot of money. I did a project for university Griffith university in Australia and I, their particular admin system has a, an enrollment component. The enrollment component is used twice a year. It's used in February and in July. Other than that, it's very, very little usage, but February and July, it just Schutze up.

So they were in a situation where they had to spend a lot of money in February and July. So what they did is they containerized their application. So that's where we've gone now into the container part of it, where we are saying, now we just have this enrollment function that it can scale all it likes, cuz it's only a little, a little application. Then what we've, we've now got to the point where the support for our containers is, is a multitudinous.

So another example, if you've got an authorization function, that's supporting a particular requirement that probably you need to do for multiple containers. So rather than have a, a multiple authorization services, we have a microservice that does that for what whichever container needs, that it gets worse. We then have moved into a situation where rather than just this, this application we're supporting now, we've got another application over here and it might be on another cloud service provider. How do we handle all of that?

So organizations now are moving into the, into the area where we've got a, a services mesh, those support. So any application, regardless of which cloud suppliers on, if it needs authorization can get to this particular authorization function through some sort of API. Now we need a tool to handle that for us. Just take a minute. Talk about why cloud native there's some imperatives for this one is the scaling that I've already mentioned. The second is agile. Okay?

The, the, if we've containerized our code, we are much more agile. So for Griffith university, if they decide they need a change to the enrollment form, that's all they have to change is that function, the enrollment function, right? They don't need to go through, you know, a dev test prod release of the complete application. So that means they can pivot quickly. And if there's any need that I see coming as being needing to pivot quickly, things are changing so rapidly.

Now, if you're in a manufacturing or supply chain issues, your supply chain is changing big time fast right now. What difference does that make to you? I wish we had more time to spend on this. Okay. It allows us to, to, to leverage our, our platforms. And this is one thing that we, if you're going into cloud native, you need to start choosing your platforms properly and, and efficiently and not be pulled 10 ways to Sunday bid by different devs that want to do it a different way, gives us faster development and, and accelerating our deployment. You need C it pipeline support.

So you can't possibly expect a dev person now to understand all of the places that his or her code is going. You need a tool. That's gonna do that for you. Okay. The problem with this move into that we've seen happen over the last two years in my experience is the complexity that, that, that generates. And there's some things then that we need to be aware of. One is we're in an agile environment, right? I I'm a project manager that loves waterfall from way back. I've done project management that doesn't hack it anymore. You've gotta have the project wall.

You've gotta have the, the, the, all of the tasks that you have to do. And they've gotta go from, to be done in train and, and completed. And you gotta have your periodic standups where we all get together and decide, what are we doing? Who's doing what, what problems we've got, you know, you, you need to have that agile project management approach. We've gotta manage our APIs. Okay. And more about that later, you we're gonna have to make sure that we've got our, our development staff processes in place. Okay. Some organizations are taking on deaf people just going through the roof.

If that's not managed, it's an accident waiting for happen. Threat detection. One of the things I was very impressed with is in solutions that we had, that we've featured in, in the document, some of them have actually got threat detection built in. So if a dev is putting together something and he's gonna take this particular policy, the package will actually tell him that there's a vulnerability associated with what they're doing before they even get into testing it. Right.

And, and it's so taking advantage of what's happening in threat detection now is a major requirement, but up hand to interrupt me any point, okay. And then there's the automated development tools like I've, we've already said, unless we have, those are our devs, got the hands tied behind their back. And we really do need to support them and provide them the tools that are gonna make them do their efficient, their, their activity more efficiently. Okay. This imperative, I called it plan or perish, cuz quite frankly, I think we, there are some companies that are that heading for a train wreck.

The, there is a plethora and it is increasing of platforms in cloud native environments. Okay. So dollars to donuts. If you've got any sort of cloud environment right now, cloud native environment, you've got ENVO okay. So you need to know, well, is that what we want probably is, but you need to make that decision, not just do it because some dev has used that in the past. Okay. Dog Kubernetes. Everybody's into Kubernetes now is that the solution that you want?

Yes, it probably is. But then what does that mean? How are we gonna have this, the authorization done for a Kubernetes container? What about or Terraform? Terraform is used widely now is that the tool you want?

You know, you need to choose these rather than having the dev come along and say, well, I've used this before and it's great. And before we're gonna use it, you know, you need to have some structure around that. Okay. Okay. Some predictions cloud native will, will, will be the future. Okay. If you're going into the cloud doing cloud deployments, you're gonna be doing it in the cloud native function because that's the one, the one it's gonna give you so many benefits.

So, so many benefits in terms of the cost, in terms of the agility that that provides, we do need to be adopting a cloud native approach, but we need to be doing it intelligently. Okay. So Kubernetes is, is used widely. The problem that that provides you is APIs. Okay. APIs are used for the containers to talk to the services that they need and to talk between containers, you need to make sure that you've decided what can an API do? Okay.

So from, from a management point of view, what are you gonna allow it to do? Can, you know, it might be, if you're using, using HGTP might be a get, okay, but maybe a HGTP put no, not so much. You need to set those rules so that the dev person got the guidelines that they need in terms of this is the corporate solution that we are appearing to. And then there's the, there's the encryption. Are you going to encrypt your, your communication between containers? Are you going to, do you want, do you want a digitally signed you?

These are the sort of decisions that are going to be made outside of, of, you know, what the devs want to do. This is the corporate requirements that you need to put in place. You might have heard this term terms, software supply chain, I've just recently come across it. What that's referring to is all of the things that now happen in that dev environment to get something from concept through to deployment. Okay. And looking at all the things that can go wrong on, on that chain.

So it's worthwhile taking some time to, to make sure you understand the supply chain of what's happening and the EBF. Okay. This is something that recently been identified to me. And I've yet to know whether this is really where we, the things that we need to be worried about. It stands for the Berkeley filter, Berkeley filter. Come to me, look up. If you into cloud native, Google E B P F. Cause it seems to me that what we're going to have as a number of vendors, releasing solutions that have these built things built into the Kubernetes environment, okay.

You can either do it in an API or you could build it in. And if you build it in, it's a lot faster, but there's some issues with how that's done controls on how that's done. And you need to make sure that the vendor's doing it in the right way. So just to put that in the back of your head.

So, you know, six months from now where this comes up, you remember, oh, a I 2022. This is where we heard about it.

So, so make sure that you're aware of what's happening in, in the software supply chain. Just gonna take a bit of an aside. You don't have to do this. You don't have to know all of this, right? You just need to get the people that do know how to do it, need to coordinate them. Okay. So your job is to stand in front of the white board with the right people in the room and say, what can go wrong? And they'll tell you, if you don't ask them, they won't rise to the CTOs. That was the last one. There rise to the CSS.

Now there, there's a couple of people that will disagree with me on this one. But what the issue here is my experience is the CIOs and devs don't get along well. Okay. CIOs typically are looked after the infrastructure in the, in the, in, in, you know, in your it environment.

But the, the deaf people want to do things and get things done. And they don't like the constraints that that might be put on, but they do. They do trust the CSO cuz the CSOs responsible for the security issues and typically talks the same language as the deaf people.

What I see is the need to take our deaf people and stand them up and saying, these are the guys that are gonna make my company successful and make sure that the, that, that the environment around them, number one, supports them with all of these things like automated deployment tools and, and tools that look at threat problems during the dev process, all of these tools that are available, you know, use those, but also recognize them and, and have the CSO be the, the conduit into the sea level discussions to support them. Cuz your devs are important. Okay. How are we going to tame this beast?

I'm not getting any questions yet. I dunno, either it's going under your feet or over your head or let me know, you know, if presenters need to need questions cuz then they know whether they're connecting or not. So think of a question. Okay. So what sort of a controlled response might we might we have? And that's what we're looking for in terms of, in terms of reducing complexity, we want to control response. Okay. So I've just come up with five things. I mean there's more, but in terms of them, I would say take a unified services approach. Okay.

In the past we've worried more about the functions that we are doing and what where's that piece of code sitting and who's doing what well, that's not really important. What's important is we take a services approach. And what this means is your user is king. So whatever the user wants in terms of the services that are being provided, you provide it for them. So they couldn't care less. What infrastructure is running on. They want to know that when they get their screen up there, that it makes sense and does what they want.

And if one thing works one way in the finance admin system, please make it work the same way in the E R P okay. Try and have a unified service approach, particularly moving into multicloud because if we have, oh well SAP, we've got on AWS and we've got our finance system, that's on Google. Very often. Those are totally different. And the operation is totally different. Avoid that as much as you can with the unified services approach, give the developers the tools they need. Okay.

You, you, you are going to be you, you regret not doing that. Number one, it's going to reduce your cost. Number two, it's going to reduce the potential problems that are, that, that, that arise.

And, you know, in terms of an efficiency, you're gonna have to use those tools, choose your platform. We, we just looked at some platforms as multitudeness and they're coming online weekly, control that and, and make sure there's a choice. You don't choose. You stand in front of the whiteboard and say, what can go wrong?

Therefore, what do we need? Okay.

The, the platform approach, if you're going to a multi-cloud environment, moving into a services, mesh approach is probably a good idea. Okay? An and services, mess approach.

You don't, you don't need to know where things reside. The tool is going to look at how it's gonna deploy that across multi-cloud environments set the rules. Okay. Particularly when it comes to security, you know, what are the rules? Do we need to encrypt things, we need to encrypt things. We're gonna have to provide some key management capabilities or whatever it is. If you've already got a PKI.

Well, you decide, are you going to use that publicly infrastructure for your cloud native environment and or, I mean, most of the tools that we looked at in that research document do have their own capabilities of encrypting and digitally signing communications and, and lastly prioritize the, the solutions. Okay? So the DevOps need to be recognized for what they do, cuz they're very important to you. Particularly as we move into this agility, the agile environment, we're doing a presentation on, on, on Friday that looks as supply chain, supply chain issues.

It it's, it's significant. And we're finding organizations now are changing their business processes because of number one, the cost now of supply chains is going outta sight. Number two, the resources that just aren't there. So how does your organization cope, cope with that? And the last part there is yeah, empowering a C corporatizing your development environment is part of that. Recognize it as a corporate function, not something that happens in the shadows out there, which I've seen in many organizations. So empowering the CISO. If that's the person that's gonna be doing that for you.

Okay. Last slide here. So the whole key is number one. We want to deal with this increasing complexity. And when I say deal with it, it's not difficult. This isn't rocket science. We've just gotta choose our tools wisely. We do not want to get into the, into the situation where, oh, can't possibly cope with this. It's just too difficult. Okay. Don't have to get there in cloud native. Although it's a complex requirement, complex environment, we need the, the platform platforms are gonna help a mandating that is going to make your job a lot easier need for tools.

We, we we've done that. Talked about that twice now. So forget that focus on purpose. I just wanna say, I wish we had more time. We're rapidly running outta time.

What, what we we've talking about here is cloud native is likely to move you away from the org chart that you know and love. Okay. You've got various stove pipes that no one does IAM one does the rules management one does the entitlements. One does. Okay. What we need to do now is come together and focus on a purpose. So if we are now gonna deploy something on a cloud native environment, we need to say, okay, we need, we need Joe from the IM group. We need Tom from the entitlement group.

And we need somebody maybe from HR, you know, and pull 'em together in a community of purpose that focused on one thing. They can stand in their functions. They've got other things to do, but for your specific native environment, they need to fulfill the requirements you need for that application deployment. Okay. I don't have any more slides.