Expert Chat: Interview with Invited Expert

So we, we we've seen a lot of things in the previous, in, in the previous talks, but what do you think Chris matters? What is needed to change? People's mindsets about how they operate in the cloud? Think that was ended up going to both of us there, Mike, and, and I, I we'll go in and, and say, I, Chris, I like your talk there.

I, I only got to see the end there to get you on here. I had to go off, put you on mute. So I don't the last, but Oh right. Hopefully I'll Watch again, the, the, the, from the question point of view, it's all about what people need to do is, is get that collaboration going. I really look into saying, well, you know, we are all pulling in the same direction in an organization where we should be. And so saying, right, what is it that we need to, we need to do in order to get people talking. So whether that's about saying security needs to see risk drop over time, that's fantastic.

Whether it's a DevOps team, actually, as much as risk is important, that's not their day to day job. They want to see performance go up. And so they want to see less time being spent dealing with security teams and less time doing that through that automation. And that is something I did catch from Chris' talk was, was going through that. Great. Great. So have you any comments on that, Chris? Yeah.

Mean completely agree with Ashley, but to, to add to that, I guess I'd say the one thing from my experience of, of doing some of this, doing some of this work as well is to encourage people, to spend time with people you don't normally spend time to. I think the idea of DevOps and dev sec ops isn't that you have one person that's skilled in all these different things. It's building cross-functional teams. Now for me, a great way to establish that cross-functional team is just to start, spend time with other people.

If you are, if you come from DevOps world or you come from a developer world, go and sit with security for a day, if you're an incident response, you work in the instrument response team, go and sit with the application developers for a day, or, or go sit with the infrastructure and cloud operations for a day. You learn a whole lot. And the other side of that is it's really great way of, I mean, I'm a big fan of empathy, and I know we throw that around quite a lot in the industry, but actually having empathy with what other people are going through.

You can, you can start to understand why when you put a request in, why does it take three weeks? It's only just pressing a button. Why does it take three weeks to do that?

Or, you know, on the opposite side of things, it's just security. How difficult is it to apply these security rules and actually spending time with people, you start to understand why it can actually be genuinely be a struggle and, and maybe it's as simple as they just haven't got the education. They haven't got a mentor to help them guide them through what the security is. Sometimes it could just be that they're, you know, that they're push so hard to deliver to such aggressive timelines, that security isn't on their radar and security isn't prioritized effectively.

Yeah, that, that that's interesting. But I mean, that, that ki I think this notion of bringing teams together and communication is really quite critical. And I can say that to someone who tried to run a development organization that stretched through America, France, Israel, and Australia, where each with their own cultural mindsets. So getting people to work together is, is an absolutely critical part of, of a successful development program. And unfortunately, sometimes organizations tend to kick a ball out into some third party and say, just develop it.

What, what do you think of that as a, an approach? So, well, I didn't know if was talking over you there, Chris I'll, I'll, I'll take a stab at that one.

So, I mean, it's very appealing. I mean, we've got think that, you know, it has been going on for a while now. We're transitioning from that back office function to now seeing new ways of working and, and people having a new appreciation of what technology can do for the business as an enabler.

Again, we throw these words about don't we, but actually what technology can do. And so kind of touching on the two points there.

First, what mentioned before, which is, well, you know, a lot of the time people are scared to admit that they've, they've tried to do things better in the past and the organization wasn't ready for it and is, is, you know, shot that down. So sometimes people are resistant to change. Not because they personally are, but because they've been, they've been brow beaten too many times, and then a similar thing for that kicking the ball out and saying, well, we'll develop something elsewhere. It it's all trends in business management.

Isn't, it's that trend of saying, well, that's not our core business function, so we should get somebody else to do that. Who does do that? And that makes a lot of sense. I think the thing that I would say is that if, if what's being developed is going to be your differentiator for your business, then you do need to think of, okay, we're maybe not a software development house, but we need to make sure that we're on top of all of that. You're not gonna outsource that accountability, for example. So that's where I would say, Chris, what are your thoughts?

Yeah, I totally agree. Again. Totally agree. But I would, so I'm a big fan of, of Jack Good Simon Wardley and he does Wardly mapping. And the great thing about doing award mapping exercise is you break down a value chain. And so you work out to, to Ash Ashley's point, there you work out what the, the value the business value is.

And, and if is it, does it make sense for this thing to be a, what they call a commodity, what you end up calling a commodity, which would be effectively shipping an app. Now, for me, it makes no sense for me to design a word processor. So I have a subscription to office 365 and I, you run word and PowerPoint and stuff. It's not core to my business, but it is core to my productivity without it. I would be useless if I can't write something in, in Excel.

And, but then there's the other side of it, which is, you know, court assisting and developing the value and stuff. And absolutely I can't outsource that to anyone. So I think it depends on the use case now, in context to things like outsourcing development of stuff, there is, I think you need to be clear on the, the, the, the contractual relationship there in terms of what is it that we're trying to do in terms of building there from security standards, from scaling standards, from accessibility and so on.

And that's core to managing, I think, outsourcing stuff to a third party, whether that's, you know, buying an off the shelf application or going to, you know, offshoring or nears, reassuring development, I think that can work really, really well, but you need to go into that eyes wide open. A lot of people just say, right, we're outsourcing, let's go Chuck it all over there.

And, and they will deal with it. And they don't manage that. They don't set expectations and stuff. There's a reason why the system integrators are some of the largest earning companies in the world. And that's, cuz it's very high value when they set the contractual terms out. Anything's a change and everything's the cost of change. So if you go into their eyes wide open understanding, okay, what is it that we want to change? What flexibility do we want? What deliverables do we want? Then it could be absolutely that's the right idea to do.

But if you're not sure how to do that, I would recommend having a look at worldly mapping, cuz I think it's a great kind of exercise to go through to understand your own value and the process of doing it with getting to where, whether that can be an outsource commodity or not. Yeah, that, that's all very interesting because I think there's another dimension to what we've been talking about, which is that many organizations have really important legacy applications and they would like to exploit the crowd.

And what, what, what I see is there is this tension, should we move it or try to move it as it is the so-called lift and shift. And some organizations are trying to promote doing that by offering those kinds of services. And then you've got another group of, of experts who say, well, you should just tear it all up and build it using modern technology and, and, and containers and everything. And so how, how, how does an organization stare through that kind of problem? Is it the same answer or is it something different?

I, if don't mind actually I'll jump in. I it's a SIM it's a similar, you know, ticking my consultant hat on. You need to look at these things in, in what, what makes sense. Some of those traditional applications, it makes no sense then going anywhere near the cloud.

But, but then it depends on what you're gonna do, what your aspirations are. If you need to, if you need to get the, the inherent benefits of cloud, you know, flexibility, scalability, accessibility, all those abilities, then maybe you do need to look at, can I, can I do a lift and shift? And does that make sense or do I need to do a replatforming, which would give me much more flexibility, but would take a lot longer.

You know, I worked for a, for a before joining Systa, I worked for a payment provider looking at changing that, that payments network into a microservices application, actually funny Ash, Ashley. And I share that share a similar history there. And that's, that's a beast.

These, these applications are still, they, they power the payment platform and none of us around this, none of us attending today would be happy if that payment platform fell over at any point, cuz that's how we get our paychecks. That's how we buy our, our groceries and things like that. So that's really important, but it also needs flexibility and it needs scalability as we move more. I mean COVID has, has pushed us very much more into digital payments, more than we've ever been.

The effect on the payments network has been huge the past the past 12 months, which is something that, that potentially the old legacy systems couldn't have held up to. But you have to, I've gone, I've gone down a bit rabbit hole there, but you, I think you have to look at the different, the, the, the different use cases that you are approaching and how to, how to look into this. Some things absolutely.

They, they, they require a traditional approach to I'll. I'll use my analogy of, I I'm a fan of classic cars and I've got a classic car in my garage and I'm not gonna change that for something modern, cuz it's, it's, it's irreplaceable as a car as a, as the, the, the, the use I get out of that as a classic car, but then I've also got a modern car, which has its use for something completely different.

You know, it's much more functional for that different use case. So looking at applications, understand the use cases and where the benefits, the benefits are inherent in modernizing something is important. Don't modernize for modernizing sake. Okay. Do you have any comments, Ashley?

I, I, I wanted to say I disagree just in order to be different, but no, I, I agree very much. So the, the, the important thing there as Chris mentioned is that we toss around terms like legacy and, and I always, and I noticed that Chris deliberately said traditional as well, which, which I really like, because it's that whole thing of going, okay, well, if we're gonna say that this chunk of compute that still brings in the large amount of money for our organization is now legacy and, and not worth as much as this new shiny stuff.

We're not, not just in danger of making a big mistake and then treating the, the legacy equipment. That's still the revenue earner badly, but also there's that whole notion of the people in the organization as well. So now you're saying that actually, we're gonna categorize these, the, the, these operational people who are looking after this legacy compute that they're now, you know, a two tier workforce, we've got the cool kids and the not so cool kids.

And I, and I think that's a really, really dangerous thing. And we've seen today already about how left called about having that idea of, you know, a center of excellence that ties into the other traditional, if you like it areas. And so we're not then denigrating those areas, but in fact, saying that it's all value towards that cloud compute the, a really good point there that I'm going to, that Chris made, I'm gonna reiterate, there can still be value to do lift and shift if your goal is to then modernize that application at later date.

So if your lifting shifting not to save money, but you're lifting, shifting to get that experience of operating something that, you know, in an environment that might be more new to you with the view to then replatform it later, that's perfectly valid. But otherwise, just as Chris said, you know, do you need to, do you need to replace that classic car? No.

Then, then you'd be quite happy with your Car. That's a very astute thing.

I, I think a final question. One of the things about the modernization of applications is that the network is becoming much more important because as you containerize and microservice it, the interactions which were previously sub-routine calls inside the server have now become network operations. How is this altering the, the security and the performance and the management of these containerized operations, perhaps we'll start with you actually.

So, you know, I want to be a bit GLI and say that it was sun Microsystems that said that the network is the computer and, and came out with the fallacies of distributed computing, which actually is worthwhile going back and having a look at, because just as you said, it's kind of now something that we're doing more and more as we break into those microservices. Yeah.

I mean, the, the, the network is, yes, it's still something. I, I wouldn't say it's entirely new. We're still doing a lot of the same things that we always did. We're now just treating them in slightly different ways. And so you do now need to have that appreciation and knowledge about how those microservices are going to talk to each other, as opposed to maybe you could have gotten away just saying, well, things happen inside the computer to make those, those processes work. So you do need to have that appreciation, but I think that then becomes all about the abstraction that's going on.

Doesn't it. So that's where you're then saying, well, if we're, if we can treat containers as an operations guy can treat a container and, and not care about what's in it, then in a similar way, I'd suggest you can start looking and saying, we can treat each of these interactions between microservices with some form of commonality.

And so, so that way you still need to know about that networking, but we're not trying to bog our application developers down into it, probably dived into that a little bit too far, Chris, what's your take? I mean, so I do think the network has, has brought, brought in kind of new, new frontier that, that people haven't had to consider before by, by converting applications into microservices.

We, we do a couple of things. First of all, we involve different teams in a develop you've got single application that could be developed by five, 10 different teams. They should talk to each other. But as we talked about earlier, they may or may not actually talk to each other.

So you, you get into the world of where we start talking about things like zero trust. So actually each of these applications, each of these components within an application could come from an untrusted resource. So we absolutely do need to lock this down.

And then, and then we get to the, get to the idea that in the traditional world, I had a, had my data center. I had a firewalls around my data center. That was my perimeter. That was an untrusted zone. This is a trusted zone. We're now getting to the world where everything is, the perimeter. Nothing is nothing is in the trusted zone. The challenge with that is that not everyone knows actually.

I mean, I've had had interesting conversations with folks in the past and not everyone actually knows how, what their application does. The bizarre as that sounds, it's like, well, I know that my Java module does this. I don't know actually how it talks to that thing over there, but I know it does talk to that thing over there. So you almost need a way of automatically mapping what's going on in the network, automatically understanding what's there. And then coming back to them and saying, right, here's a diagram of your application and they'll go, oh, I didn't know I did that.

And then we can say, we can have a discussion about, okay, should we put the security controls around this? Is this how we should model things. But I think we need to, we need to kind of, it's almost like get over a pride thing where we, where we assume everyone knows what their apps are doing, because that, that, that is a view of ignorance. I think we need to understand that because of the distributed architectures that we're doing, I can't remember what the phrase was for this, but the idea that your application architecture defines your business the way your business is.

So in microservices, you end up having lots of different teams is just an artifact of doing things. And so back to that communication thing, we started this talk with, you need to make sure those teams are talking to each other. And that then comes through on the network side of things, adding the network, adding security of the network.

As, as we push things into the cloud, we could be multi-cloud. It could be in different components to different places. That security becomes more and more important because that perimeters all over the place now. Yeah. Yeah. Okay.

Well, so I think we're coming to the end. So perhaps I could ask you both to say, if somebody asked you for your piece of advice, what would it be?

So, Ashley, what, what, what advice would you give to someone in this cloud hybrid container world? I, I would say, be humble and think about that.

We all, we all in performance culture, we're all trying to show how smart we are and how good we are at doing things. But actually you, you need to know what those other teams are, are doing and the way to do that, to be humble and to talk to them and understand that, you know, we are all trying to do the right thing.

So yeah, I wanted to say communication, but I think I'll be humble about things. Thank you. And Chris. Yeah. Kind of extending on that really, you know, also have empathy. So I think spending time with other people, like I said earlier, go out, I mean, do it, do it today at the end of this, at the end of this today's session, find some time in your diary over the next couple of weeks and go spend some time with someone you don't normally spend time with go, go sit in their, sit in their shoes, work out what they do, get some empathy for, for what challenges they've got.

They've got, I think that's a really powerful thing is just if you're a manager, encourage your team to do it, just spending time with other people to understand exactly what role they have, exactly what they're doing. I think that will make your job and your life a lot easier going forward. Okay.

Well, thank you guys for that. Great talk and panel, and I wish both of you all the best for the future. And thank you very much for your participation, Ashley Ward and Chris Kratz. Thank you very much. Thank You. Thanks Mike.