Why Shipping Apps in the Cloud is So Hard

The evolution of Cloud services in the past few years has brought tremendous benefits, but also new challenges. These new complexities in cloud services make it difficult to ship applications.From tooling, to principles, to lack of standardized metrics, Jon and Jay lay out the current challenges in DevOps and why delivering cloud applications can be so arduous.

To keep the conversation going, join our Slack community and follow along on Twitter

Transcript

Jon Shanks:

 0:00

If you look at how it’s delivered, which is where our space is, and it’s not evolved as fast as the tech itself, it seems slightly lagging is like the industry is gone really quick in many directions, but their way of delivering it and recognizing the value of those things is way more arduous. Cool. So welcome back to cloud unplugged. We’ve got it back off the ground, eventually a little bit of a big hiatus there. But we’re coming back kicking and screaming and getting it off the ground. Again. I am here today with Jake Fisher. I don’t if you want to introduce yourself, Jay a little bit about who you are.Unknown:

 0:38

Yeah, sure. Thanks for having me on, John. So I’m Jake Shaw. I am one of the cofounders of Appvia. I come from a technical background, you can’t see the air quotes that I’m I’m doing right now. But essentially, I’ve come from this sort of configuration management and, and DevOps background and how that sort of evolved over time. Yeah, that’s me.Jon Shanks:

 1:02

Cool. So I know, we were just chatting earlier about topics and subjects. And I think we were just agreeing about discussing today, just a high level overview on the problem space, kind of delivering applications in the cloud space. What we’re going to be doing with this podcast is obviously picking it different problems bit like we did in the previous season. And then just kind of talking a bit more freely. Could be could be 10 minutes could be an hour. We don’t know how long we’re speaking for.Unknown:

 1:34

I mean, it’s probably going to be like an hour, two hours. Exactly. cut this down.Jon Shanks:

 1:39

Exactly. So you may want to go and get yourself drinks,Unknown:

 1:43

as well. But play this on at least 1.5 times.Jon Shanks:

 1:47

Yeah, don’t yeah, maybe not. Because it’s too high pitched. Voice is already reasonably high pitched. I want to be like sound like a chipmunk. But yeah. So I know. We’re just talking about just the problems of the cloud. I guess that high level constraint what’s stopping people delivering successfully in businesses? The changes in the industry? I don’t know if you want to like, pick it up a bit first. I’ll obviously chip in. Yeah, Shawn, I thought so. Yeah, it’sUnknown:

 2:16

I mean, obviously, the industry has evolved so much over the last, how long is this? AWS been out now? What, 13 years, 14 years? Yeah, probably about that. And what in its infancy, it was just like, easy to and things like that. But now you’ve you can see from, you know, just the cloud services and how they’ve sort of evolved, I think it’s over 200 services just in AWS, which obviously means that just in a single cloud provider, you now have 10s of different ways of achieving the same outcome, right. So that just start, you start to kind of understand how complex this space is, and how many choices there are. But it’s not always been that way. You know, we’re, it’s almost like a, where we’re almost in a privileged position because of the innovation that’s happened in the industry. But that doesn’t make it easy for someone to just ship or ship an application, which is what they want to do. So I mean, if you if you take it right back to, you know, how businesses used to work, the concept of you know, having sort of centralized build servers and things like that was quite novel, right? Like people used to just, you know, write some code, put it on a file share, or like SVN or, you know, subversion or something like that. If they’re if they were doing sort of configuration, source, source control and management properly, then they’ll have like a central server. I’ve actually used to use the thing that came just before subversion, which was CVS, do you remember that? Yeah. Yeah. superfos Yeah, exactly. So my, my kind of history of this scope goes back a fair bit. But yeah, so they’d check some code out. You’d have like locks on files, you know, you’d have to speak to someone to unlock that thing. Work on it, put a new version of it out. And then someone would just compile it, compile it locally, build it, maybe they’d have tests, maybe they wouldn’t have tests. They potentially put it into an environment before it hit production, or they’d live by the skin of their teeth and just go straight to prod. have loads of approaches. Yeah, yeah, totally me. So. So that’s that that’s kind of where the industry used to be. That was the kind of norm what like 1515 20 years ago, too. to certain degree for certain companies. Now it’s on the absolute flip side of that, where you are automating as much of the sort of quality and the gates as as possible. So that you don’t have the Cowboys that are putting things straight to prod. So, so yeah, it’s it’s a, it’s definitely come a long way. There’s loads of bits in between that, that have that that we can talk about. Where did you start? What was your What was your first foray into this space?Jon Shanks:

 5:36

Very similar, I think, yeah, I worked for an ISP was different because it was like managed hosting to kind of providing hosting back to other companies. And it was quite a lot of all kinds of different things because of that LDAP involved for like user management that was kind of driving the DNS, all these kinds of things, but still very manual people going into data centers, people racking up kit. You know, network teams, obviously, inside the business, sorting all that out the Pops and all the other stuff, because it does DSL as well back then. So it was kind of slightly different in that sense, because I wasn’t working for a specific company solving specific company’s problems. We’re just kind of solving lots of company’s problems by hosting and working with them. But so we were cloud like, but not really, as it is today and then worked for other companies at that point, large companies that would be kind of internal cloud teams, I guess that sense. So then they’re kind of offering the services back internally to the teams. But I think it’s become like you were saying, the growth of it all. Obviously, on one hand, it’s made it way more accessible, like you’re saying, it’s like, now you can program against the cloud do automation, it’s there’s API’s, there’s all these other standards that have come out, make it easier. But because of the landscape of the tech, it’s now more complex, in the different way, some more accessible, but more complicated. Exactly.Unknown:

 7:14

Because the problem just, it just iterates, right, like people get smarter and smarter about the problem, people have more and more opinions about it. And is it Murphy’s Law, you know, things are just getting better every 18 months, or whatever. So that is like the hardware has getting better, which means that the software can also get better. Which means that it can do more things, which means that it can be configured to in different ways to do more things. So it just evolves. For sure.Jon Shanks:

 7:45

Yeah, it’s funny because that child loads of things altered. Yeah, I mean, it wasn’t just the tech like ways of working have altered agile methodologies. That was like the buzzword for a while a little bit of occultismUnknown:

 7:57

Extreme Programming, right? Yeah. All the way back from back then it’s like extreme programming, lean ways of working Agile Scrum, it’s DevOpsJon Shanks:

 8:06

sprouted up, didn’t it, and then that became a thing. All these like weird little colts, I would call it like, a bad way. But, you know, they get a lot of belief systems around it, and then it goes, everyone goes really hard in one direction. And then you kind of like, everyone sticks it for a really long time. But then things evolve, but no one really talks about but it’s evolved from when, originally, it started into, like a different way. And it takes a really long time, a bit like, it’ll really they’re just I know, it’s not as bad. But they’ve kind of shown exactly nine, at some point, another version of agile, I imagine, as things have evolved, because everything’s changing that you kind of have to reassess.Unknown:

 8:50

Yeah, that’s, that’s interesting. I mean, um, it’ll be interesting to see whether whether there will be like a version of agile because you’ve got loads of frameworks, right? You’ve got safe as a thing you’ve got, like Team topologies, and how these different organizations like chapters, chapters, squads, tribes, whatever you want to call it. There’s loads of kind of organizational ways of managing people and outcomes. That’s evolving. And agile, obviously, touches on that space, but it isn’t so prescriptive. Yeah, exactly. So it will. Yeah, I’m definitely curious to see where the market leads us.Jon Shanks:

 9:32

Yeah, I think the space I mean, our space has been very scripty historically, right loads of scripting, not very tool and product centric, and like stringing bits and bobs together. Massive release processes in spreadsheets to have like network teams involved haveUnknown:

 9:49

a story about this. Yeah.Jon Shanks:

 9:53

Loads of people involved like some release manager going through the spreadsheet bit by bit and coordinating every bit De. And then into then tools, like more conflict management tools kind of arrived, you know, ways of bootstrapping machines, and then cloud and then kind of them more DSL because that was the first stage of the DSL chefs and Puppet, sensibles, etc.Unknown:

 10:18

Ansible came way later, but yeah, puppet chef chef SaltStack.Jon Shanks:

 10:22

So, remember that, yeah,Unknown:

 10:24

I actually wrote, that was that was part of my story. So before puppet, I wrote my own, I’m sure pretty much every single person did this, in some to some degree. So just before puppet, I wrote my own, like, configurator, it was called classic classic name could have started really early before Kubernetes was okay, no. But that basically did the, you know, you were shipping configuration files and had to obviously templatized them, cuz everything was custom to an environment that you would deploy into whatever. So trying to wrap and handle that logic, you know, you had to do something to you had to create something to address that problem. And I had a version of it, you know, colleague, well, a friend in like a different organization, like started, once I told him about the problem, also tried to solve the same thing. So I’m sure a lot of people in the industry are like, try to solve the problem in different ways at the same sort of time. And then obviously, a company like puppet comes along. It’s like, oh, yeah, your your little problem that you’re trying to solve that? Well, we’re going to productize it and, you know, try to solve that problem for the industry. And that was, that was great when it happened, right? It really kind of took that conceptualize the problem in a different way. You know, you had like, agents that were constantly running and trying to trying to almost be a bit more declarative, on, on how on what to expect on a machine. Obviously, it wasn’t it’s imperative. And everything was, was done in that in that kind of procedural sort of way. But the concepts were there, and how it’s evolved to where we are now where you’ve got immutable declarative infrastructure and how that’s evolved. As you can see, you could you could trace back the steps. Yeah. So yeah, it’s,Jon Shanks:

 12:34

but I think what’s interesting now all those because there’s a, I mean, I’ve talked about this a fair few times outside of obviously, the podcast, but there’s a bit of a confusion, I think, on like principles. And then tooling around the principles, and then actually a defined way of working. And I think that’s when, you know, DevOps is principles, agile is a way of working in some ways, right? Because you’ve got a framework to work within. Yeah. But you didn’t really have a way of working when it came to kind of DevOps, it was more like principles, you know, about the quality of what’s been produced. And then these principles, still, you kind of have these, I guess, industry terms, that creating a bit of an illusion that people are actually working well. So it’s like, oh, if I do these things, right, so infrastructures code, well, let’s rebrand. Let’s call it get ops, whatever, okay, fine. Call that get it working and get right tick. I do that. Right. So is that oh, you need to do Polish policies, code, every policy written down, make sure it’s code as well, kind of similar guys. Infrastructure is code policies, code, whatever you want to call it, is code. Just everything is code. Stop it, stop it. Now, we do copy this code, please. But the prints the principles, which are healthy principles, get audit trail visibility, go back to apple butter, so I get I get those things. But for business, trying to deliver, trying to marry up these kinds of principles to an outcome, it’s very detached. It’s not about the outcome. It’s about how that person is decided to work within their own peers, right. So you have like peer to peer. These are some best practices, almost, this is what we advise you to go and do great. And that doesn’t mean that it was successful in the outcome. And I think that’s what I find a bit bizarre sometimes in the industry is you have people working, but they’re not really there’s no measurements. So if you look at our industry, especially like the DevOps and cloud delivery industry, there’s no real measurements. Just an agile is measuring the story. So you could you could say, arguably, if you were following that methodology, you could maybe you could do it there. But it’s unusual nowadays, that that’s part of it because you have central platform teams that may be detached from the delivery team, so you’re not you may or may not be using agile, which then means what’s the measurement of success exactly for that team? Where is that? How do you know you’ve improved? You know, you’ve got better? How do you know these principles worked well. So there is this kind of very strange. I’m not saying it’s a bad thing, but I’m just saying it’s confusing. I imagine because you don’t know. You could be under the illusion that if you did those things, you’re doing a really good job. Yeah. Right. Like, well, yeah, of course, definitely. I do. She has code and get ups do stuff, you know, I’m doing an amazing job of praise myself in line with what else is said I’m supposed to be doing.Unknown:

 15:36

I mean, I guess it’s down to, to a certain degree, it’s, it’s down to the culture that you’re trying to cultivate. Right? So if that culture is based on a, you know, risk reduction or risk mitigation, then doing things as infrastructure is good. Like, that’s, that’s one way to try and reduce that risk. But if you’re kind of more forward looking and opportunistic, then there are metrics then that are sort of industry standard nowadays, like the door and metrics and things like that, that that, to a certain degree, the industry has now settled, as argued many times, there’s things that have come in and out of that, but you know, they’ve beenJon Shanks:

 16:19

by them straight, I think, because I was thinking about these dollar metrics. And some of them make a lot of sense. But there’s very, there’s just four. And you just picked, I think they’re important to be more though, right? There were those Meantime, to recovery, to please change frequency, which is like code to release those deployment frequency. Yeah. And then there’s one more isn’t. It is and have to look it up off the top of my head, but it’s like it’s a laptop out, you could have a little look, just look it up. That’s quite bad that I’ve forgotten. Exactly. I mean, to be fair, we did start very early this morning.Unknown:

 17:01

Just to come contextualize this for everyone it is we got up to start this at 630. fiddle around with the mics for about half an hour. And and now it’s eight o’clock. So we’re a coffee down. So it’s deployment frequency, lead time for changes mean time to recovery and change failure rateJon Shanks:

 17:24

that’s changed. failure rates are basically the quality of what’s produced. Yeah, from a code perspective, anytime you have to, but nothing about security, which I find strange. Exactly. Which is the quality bar. Right. So you know, how secure is it that you deliver just a few things that I kind of find a bit detached? Because you could have increased the deployment frequency, but you could have done it in a very insecure way. You know, your mean, time to recovery? Doesn’t tell you necessarily whether you engineered well, like did it recover because of a failure of the app? Right. So it was the app that did well, Dyno depends on the context, but it might have had zero scale. So it’s not it doesn’t contextualize very much for you to know. It’s just side of it. If you see what I mean,Unknown:

 18:11

it, I mean, it is just software delivery performance. I don’t know totally very specific, you know, thing that it’s measuring your raceJon Shanks:

 18:20

helpful. It’s not like it’s not a problem solver follow you and it’s in its own right. But it’s a really good way of knowing, like, just having somethings better than nothing.Unknown:

 18:30

But you know, if you’re if you’re talking about security, and how to measure that, like, that’s a big topic, right? Like, how, how do you measure whether something is secure? How do you even know, once you’ve measured it, that it’s that that measurement is correct? So if you’re just talking about easy, it’sJon Shanks:

 18:49

really easy policies code. To do,Unknown:

 18:55

you need to do sets policies, does solve everything. So you know, all of the problems,Jon Shanks:

 19:00

but it has gotten you done that problem. So all you have to do,Unknown:

 19:03

but let’s say you you have some software, and that software naturally has some critical vulnerabilities that are known. And then you’ve got to measure I’ve got this many vulnerabilities. And, you know, my risk appetite allows me to have those and the thresholds that they’re at or whatever. But that is assuming that those vulnerabilities are unknown. Like you might be completely insecure, you might be getting attacked right now. I know. Not exactly. Security is something I’m so passionate about. But But yeah, you could absolutely be getting attacked right now and not know about it, right. So that that kind of air of security is it’s just one of those like, things. People sort of don’tJon Shanks:

 19:58

know it’s complicated as well, I suppose. Because knowing what do you remember when we used to get like all the CVE scans like buffer overrun and blah, blah, blah, blah, blah? And then people like, I don’t really know if that’s a bad way. You know, so? And if, if whether or not you are even consuming that thing in your code exactly, because it might have just slightly been on the, on the operating system, as opposed to something actually consuming that library anyway. So it’s very, you know, slightly mythical on on some of this stuff. So they just basically just patch all times, that’s the answer, basically, just patch kicks, and then I don’t have to know too much.Unknown:

 20:34

I mean, let me just ignore it, like put my, you know, put my head in the sand patch. Yeah, just basicallyJon Shanks:

 20:39

have to think too much. Because anything that’s cognitive, you know, if people are time bound, that’s the thing, isn’t it? Every time people are time bound, the minute there’s a cognitive element to it, or you’ve got to sit and think and work things out. You don’t in truth, you just don’t want to when you’re delivering, and you’re pressured, you don’t really want to work it all out. Which then is kind of part of the problem in some ways, because you kind of have to, but it’s so time consuming to do things really well. Yeah, to do so many things really? Well, yeah. Because there’s now loads of things,Unknown:

 21:12

never on an impossibility. And then even the people, you know, you have to be almost touching on on a little bit of a different problem, which is the people that do that do those things well, like, of course, they’re going to be highly paid in this industry, right? They’re going to be a sought after skill. And every single company is basically a technology company now. So you’ve got a finite resource that might be able to context switch and do things well. And they have the right experience and the right way of working the right culture and all and they fit really well with your team. But there’s only like, three of them. Or something. So it’s just yeah, it’s it’s, it’s a weird, it’s a weird problem, it’s a weird domain that we’re in is quite strange, it’s a little bit disconnected from it’s both disconnected from the business value. And then so connected to it, because you’re helping software, you know, moveJon Shanks:

 22:08

And everything is software, everything’s software, as well. And everything in the industry is spoken about in white, you know, even most people know about AI, right? And ml, even if they’re not highly technical, they’ll be hearing it quite a lot. Obviously, social social change, and three, yeah. What three NF T’s all those things, I suppose are all below industry becoming more mainstream terms outside of just tech. And then obviously social media and things like that. The accessibility of tech and expectation on tech, now, I can get this thing to my door, you know, I get food to my door shop into my door, everything is maybe I can just check out myself, I’ll just I don’t even have to pay. Maybe I just walk out of the shop with the items and just take it from my account. I just all this kind of experience around it. And I know it’s all Tech experience in the end behind the scenes. Yeah, tech enabled. That’s the right word. So it is funny, but then you look at how it’s delivered, which is where our space is. And it’s not evolved as fast as the tech itself. Yeah, it seems slightly lagging is like the industry’s gone really quick in many directions. But the way of delivering it and recognizing the value of those things is way more arduous than become arduous because it’s the growth. Like you were saying before, it was much simpler, there was less things, so less things to almost worry about and know and do. And now there’s way more things. And now the skills have to keep pace with all those things, which is really hard. And try and be a domain expert in some ways and all those things, which is obviously near on impossible,Unknown:

 23:49

but that’s why you have the like collation of so many job titles and term s, right? It’s like dev SEC fin management AI. Ops. Yeah, ml Yeah, all of the things.Jon Shanks:

 24:00

A lot of industries have the ops, like Rev ops. So it’s like just people just love the word ops. Because there’s just no one wants to do it. Yeah, exactly. They’re like, do you like money? Yeah, like revenue? Yeah, like revenue. Okay. Reb ops, we need someone to fix his ops problem as well. Are you okay with that? My title. But, yeah, I mean, it is everything’s got a big operational overhead now, because there’s so many things to operate essentially, that it’s become more and more important, but I think that’s why it’s just appended to most historic kind of roles, butUnknown:

 24:40

100% is, and you kind of touched on something there that I thought I’d kind of come back to so like, before, something gets popularized as a term in the industry. It might have already been done right? So like get ups You You’ve obviously worked at an ISP. That was all about software defined networks. Were you talking about software defined networks 20 years ago? Probably not. Right. But the, the fact that it was a thing, it there was a, you know, it was just part of doing your job. It wasn’t like, it wasn’t so, so called popularized or coined. It was just like, yeah, I need to do this thing, I’m gonna do it in the easiest way that I can, and put the controls in the right place to make it efficient to operate. So it’s, yeah, it’s a it’s a funny old industry to, you know, it’s kind of it kind of feeds on itself. Yeah, I mean, like, you create a term, then you, then you educate people about the term that you’re creating, and have a solution for it. And then it creates other problems. And you don’t know, when when you’ve solved those problems, whether the connection to the actual business value has increased or decreased, you’re doing something more securely, quicker, cheaper, whatever. Yeah, that that that tie back to sort of measurementJon Shanks:

 26:16

in well, yeah, we were speaking about before with me when, like the rise of the like, when markets get created by other problems, you know, so if there’s no problem to solve, no one’s obviously going to pay you any money, then there’s no market, right, essentially, is no demand for that thing to be resolved, or a demand for an item or whatever it really is. But problems generate markets, essentially. And then technologies come out to solve those problems. And then they obviously, then have a new market category, or it becomes just a growth of another market. And so if you look at like cloud security marketUnknown:

 26:51

creates markets, actually. So in this example, IJon Shanks:

 26:55

guess it depends on who sees the problem first. And then basically, the market might not exist at the beginning. And therefore you have to, you’re the first to create it, maybe you’re looking at the existing markets, but you don’t really fit in any of those properly, because they’re not defined well enough for what you’re doing. But at the same time, customers or other people might not even see that problem yet. Right. So if you’re too early, you might you might have been further ahead or projecting further ahead, I guess of what’s about to happen and start solving something earlier. And then it takes time maybe for that problem to grow enough for that market to then grow too. And I suppose, like cloud security market is a very similar thing, because you could say, well, that’s an interesting one. Because if cloud delivery was going really well, and everyone was doing an amazing job with that market exist, well, there might be some need for like an insurance policy, I just want to know, things are good. From different personas in the business, I could see so so it might still be a market for that reason, that insurance policy mindset reason, but the need and growth of it might not have been so rapid, right? Because people wouldn’t have felt the pain enough, you know, to necessarily want to purchase it. Which means for people to be rapidly purchasing something, it means there’s a lot of concern and worry, which means that there’s probably a lack of understanding, which probably means they’re, like, not sure how things have been delivered, or they’re not quite sure, on the consistency of that delivery, they don’t have the oversight them. And so, you know, they’re on the backfoot like, we need to get something tell us like what’s going on, we don’t know what’s going on.Unknown:

 28:44

And that’s it right? Most of the time, it’s just getting something to tell you the problems, it’s not actually solving them, solving them. It’s just like, I have no idea how my security what my security posture is at the moment or where where the risks are. Let me pay loads of money to something that gives me an idea, but then everything that has to happen behind that. So putting in people process technology, whatever to to stop to help me mitigate those things, or remediate those risks. That just gets overlooked. Unless it’s like a you know, critical vulnerability you’re or you know, you’ve got a signal that you’re actually being gonna sit use the word again attacked. Right now. This guy so, so yeah, it’s, it’s, it’s, it’s a weird kind of self perpetuate too early, too early for this for these words. So what was the other point that I wanted to make? So security We’ve touched on completely forgot.Jon Shanks:

 30:06

Oh, wow. Really? I was deeply interested. But we like to hit a wall. But yeah, so the other stuff says obviously the the I guess the to rein it back on the market staying in security market and cloud security market specifically. You have to kind of look at the other side of the coin, which is right. Okay, well, how’s the event of the delivery? That’s work out whether we’ve done it well, right, let’s work out, does it in risk in the business? Fine. Makes loads of sense definitely to do it. How we’re delivering that though, is that going to change? Because you could say, you know, the way we’ve clearly delivered hasn’t been if we’re talking about success again, right? We don’t have the dollar metrics anymore for this, because it’s security. That was kind of a little bit of the point. How did I even know? Well, there’s nothing even telling me? Where do I bake those measurements, probably need to think that through. But we do want measurements and around this stuff. That isn’t post everything, right? So there’s obviously a gap there. So But that aside, the ways of working clearly aren’t measuring the right things are iterating. And there’s no, you can’t solve a problem unless something’s defined, really, because you don’t know where to solve it. So if you’ve got an organization that’s delivering differently in eight different ways, very hard to solve a security problem, you’ve now got eight different ways to solve it, because they’re eight different ways of delivering in your business and not a great place to be. So you can ignore it and just keep, you know, I guess, going with the stick the security stick saying, Look at all this stuff that you’ve done wrong and banging the desks of everybody, but it’s like, that’s not necessarily going to fix the business problem.Unknown:

 32:00

Yeah, and doesn’t exactly, you know, encourage those people to give more of a shared about security, if we’re being honest, youJon Shanks:

 32:08

could have attacked them.Unknown:

 32:14

I think this podcast is going to be how many times I can fit in. Now, it’s get to the gym. Anyway. So it’s, you know, it doesn’t encourage people or educate those people in why security is such a big deal, the risk that I propose that it presents to the organization, and how they’re directly responsible for mitigating that risk, right. So it’s one of those, again, it’s one of those things where, where do you put the measure? Are you enforcing security, encouraging security? Like what’s, what is your way of addressing that problem. And if you’ve got eight different delivery models, then, you know, in those delivery models, this the software development lifecycle, you’ve got, what, like 2030, different points of which you can insert security. And so you’re now not only do you have a lack of consistent ways of working in the many delivery models and operating models that you have, you’ve also got no way to centrally manage policies code or, or whatever term you want to call in there, of where to insert that policy that makes the most sense, that isn’t duplicated, that isn’t, you know, exacerbating the problem to some degree,Jon Shanks:

 33:42

it’s also like, the most efficient place to put it as well, I think that’s the key thing, isn’t it? It’s like, you can scatter gun policy anywhere, you could put it all over the place, but it’s not necessarily the most efficient way. And if you do something in the wrong place, you can hamper delivery. Right? So it’s like, well, you know, you could have you could delay a launch date. Right, that could have financial ramifications to a business because somebody can’t actually deliver because there’s a policy somewhere like post the event of them iterating so there’s like it just need thoughts you can’t just like because everything you do has an impact unless you’ve thought thoroughly you know, on on how you’re going to deliver his team’s properly and then where to put the things to get the right outcomes because it’s all humanistic people will fix things if they know there’s a problem to fix. You know, there’s also a forcing function in it they should I mean, I think you know, let’s say the glass is half full or the most people are well intent had good intentions. I will do the right thing, but mostUnknown:

 34:50

might not have the skills to though right? Well, yeah, I suppose there is that as well. So so not they just don’t didn’t understand. Not only do they need to know about it They need to know what it means it’s important for them to fix, and then how to fix it. That’s a lot of that’s, you know, that’s layering on a lot of different lenses of what a person is supposed to do as well as their day job. And, you know, everything has been shifted left now. So now they’ve got a write some code, write some tests, do fix security, learn efficient. That’s a lot of things, you know, work in within agile update their tickets do the time to do all of the things throughJon Shanks:

 35:30

but I don’t think I don’t know, because that shift left thing. It depends how you look at it, because it’s a bit again, it’s another term that’s slightly ambiguous, because it’s not like, yes, but it doesn’t tell you what it’s shifting. Right. Specifically, it’s just saying you’re just shifting something. But like, what’s the something? Because it’s like is, are you shifting? The full blown responsibility left? That’s very different. Are you shifting insights left? Well, that’s very different as well. You know, you’re shifting the action left, right. That’s just, it’s like, which bit of it all you’re shifting left? Exactly. It’s likeUnknown:

 36:04

confusing if you’re, if your language also goes from like, right to left. So, you know, depending on where what part of the world you’re from shifting left means that you’re pushing it out. Rather? Yeah,Jon Shanks:

 36:15

I suppose. Yeah, I think because it’s starting, you know, people are moving left to right. Is it starting there, isn’t it and then you’re moving things, but I think it’s not, it doesn’t mean they’re the right person to fix everything. So again, if you actually shift the right things, to the right, people, the right things left, the right things left. Yeah. It’s like managing up managing databases, you know, we’re just we’re up down left and right. That’s how this all works. We’re just trying to just directional either up or down, moving left and right. back or forward. Exactly. It’s just a just a big dance move of delivery. Yeah, so I think there is there is all those confusing terms, again, that make sense, obviously, what they mean, but not, again, not enough context to actually rationalize to know, the value of.Unknown:

 37:10

And the funny thing is, so you know, we’ve talked about the security to the actual, or the risks of the company itself. Most of the time, these companies are, you know, they’re offering some value to the user. And it’s the user that owns their data, right, that user has no idea about the security of the service that they’re using, they now there’s obviously protection in place, like, you know, personal identifiable information and the measures that need to be put around that with GDPR, and everything else. But really, every time a user is using a website, or a service, that whose whose kind of security posture is not at all transparent, then there’s, there’s an implicit acceptance of that risk that that person is taking with their data. Right. So that’s that design its own problem. And that’s really where, like, ultimately, that’s where the problem is. And that’s that, you know, the organization is obviously trying to make sure the user doesn’t churn and that data reasonably, like they’re not getting fined and all of that stuff. But it’s, once your data is out there, what you’re going to do, yeah,Jon Shanks:

 38:27

I guess who’s because it’s detached, isn’t it, the delivery of infrastructure is often detached from the delivery of the application, because delivery will application is the business logic in the end, that’s got users. But then obviously, like we’re just saying before, if you do or too much autonomy, you’ve got lots of different ways of delivering, then when you do go and scan everything to tell you you’ve done it insecure, fixing that when you’ve got eight different ways really hard, because now you go through a consistent model, then it like means there’s some Centricity to it. If you do Centricity to it, then you’re no longer really in that team that’s now in the business unit. And so you kind of have to in some ways, I mean, you know, very biased a little bit around this clearly. So just caveat that but there is obviously an opportunity to do both to to create commodity for business units, in a repeatable way, is probably the right thing to do getting bias. That’s just what I think. Because then you’re kind of getting the best of both worlds. At the end of the day. If there’s any disruption to that service, they own the users of that service, there has to be communication to those users of that service, right? To set the expectations SLA is even to their own end users that are consuming it. They can’t do that if they’re beholden to another team that could change something at any point. Or if everything’s like this multi tenant thing where it affects everybody all at once. Well, not all services are equal, not all columns times will be equal, not all SL A’s are going to be equal for those services. So it’s very complicated. Ready to try and manage something from a central perspective in that way, there’s a lot of friction and a lot of problems and slows you only as fast now as your slowest team. And so it kind of brings everyone down when you kind of go back to Central. So it has its downsidesUnknown:

 40:18

only as fast as your slowest team, and you’re only secure as your most insecure team. Is that another lens?Jon Shanks:

 40:24

Yeah, potentially, yeah. Because if you’ve got a team that doesn’t think it needs a huge amount of security, because of what it does, then that the concern is not as quite as Lehigh then somebody that’s like, this data is so sensitive, we really have to think aboutUnknown:

 40:39

it. And if you’re in like a multi tenant environment, you know, you’ve got something, let’s say you’re, you’re in Amazon, and you’ve got an instance that has, you’ve deployed some code onto it, and that has a CVE. Are you able to get access to everything else? Yes, you can callJon Shanks:

 41:01

right now by following this link.Unknown:

 41:07

But you know, it’s like, again, it’s just another another thing that you have to think about it, the confines in which that environment is constructed for you or that you’re using is yet another layer of risk that is potentially presented. So it’s yeah, it’s really complicated.Jon Shanks:

 41:28

It’s very, very complicated. It does take a lot of a lot of modeling. Well, I guess we don’t want to kind of what we’ve just done is just given everybody all of the problems. We want to do this podcast just tell you all the problems are never gonna give you any solutions. And then just add to wrap it up. You’re welcome. Yeah. What we’ll do is well, in our, in our next one is really what I pick up some of these problems and maybe come up with some good answers. I don’t want to just leave everybody hanging and depressing them that obviously it’s all really bad because it’s not that bad, but and there are good solutions out there. It’s just how they can come together. So so stay tuned for our next episode, where we’re gonna pick up some of these. It’s obviously been great to have Jay on with me. And we’ll be carrying these on going forward.Unknown:

 42:17

Thanks, everyone. Cheers. Bye.

Share
Twitter
LinkedIn
Facebook