August 15, 2023
Season 1, Episode 16
In this episode, Jon and Jay discuss the evolution of self-service in the realm of platform engineering. They delve into the challenges and nuances of enabling developers to utilize existing technologies efficiently.
In This Episode, You Will Learn:
Themes Covered in the Podcast:
Quick Takeaways:
Follow for more:
Jon Shanks: LinkedIn
Jay Keshur: LinkedIn
Jon & Jay’s startup: Appvia
[00:00:00] Jon: Hello, welcome to cloud unplugged. I’m John Shanks and I’m, we’re gonna be talking about how as a platform engineer, would you do develop a self service with technologies that are in the industry already? And what’s the engineering effort you might have to do as a cloud platform engineering team to work out how to bring self service to life. So we probably want to caveat just in case people haven’t listened to the other episodes and what we mean by self service. So just to recap, developers don’t have to wait for anything. There’s a predefined set of commoditized stuff that they can get, they can just get like a
[00:00:37] Jay: catalog of things like storage or whatever
[00:00:41] Jon: else where to run their workloads, potentially patterns for those things of how they deploy their apps and things like that. So like a a kind of traditional platform, none of this is new. There were platforms like that historically, but I think since the technologies have changed, people have aligned now to newer tech. So like obviously Cubin and containers and things like that, that’s probably caused a bit of a change on needing those platforms still. But wanting to change the technologies that drive them under the hood. So the question is knowing the technology is out there as they are, obviously cumulate doesn’t have an opinion of self service. It’s about running containers and apps. The cloud doesn’t really have an opinion massively, other than cloud formation, there’s an assumption that whoever’s doing that knows how to configure the settings for each cloud service against their api if you’re going to do it programmatically, you wouldn’t want people to go into the cloud accounts necessarily and just kind of do whatever they wanted because they wouldn’t know how to configure those things properly. So say you
[00:01:43] Jay: need things to offset risk. Basically, you wouldn’t do it because they might screw something up and there’ll be a, you know, data leak or, you know, reputational damage or something. Definitely.
[00:01:53] Jon: That, which is obviously the biggest thing I think second to that is there’s probably some in most businesses, there’ll be some architectural patterns like transit gateways and how do I hook into the networking and what are the DNS things? And how does it get exposed and how do I get certificates? So there’s a bunch of operational stuff that might not be in the wheelhouse of developers to know about. So, yeah, you could click around but you might not get a working outcome necessarily. Even if you were to click working outcome, maybe it’s not
[00:02:22] Jay: really the best use of that developers time, right. So really all you’re trying to do is make sure that the people that know those functions are the ones that are making it easier for the developers who know how to code to do their jobs. So stay in your lane type of thing. Yeah, I know. Right. So make sure that, you know, you’re, you’re kind of like just doing the things that, you know, how to do really well and execute on those on that. And if you’re someone that knows networking and platforms and stuff like that, do that really well, deliver a service to someone else and do the rest of their thing really well.
[00:02:58] Jon: Yeah, exactly. So if we frame it under that lens of playing to people’s strengths, you don’t want to be putting everyone on Amazon courses or Google courses or Microsoft courses, right? To go and learn the cloud and then try and upskill your entire developers to like a certain level plus.
[00:03:16] Jay: It’s funny you say these things like going off and learning the cloud vendors and, you know, doing the certificates and all that kind of stuff doesn’t actually teach you how to do it. Well, no, really. It just tells you what the technology is and maybe how to use it. It doesn’t say this is how you scale that to your business. It doesn’t say, you know, you string all of these things together G and C I CD and you know, the tools that you might use in your pipeline to get an outcome that’s then easily to, easy to maintain and support and all that kind of
[00:03:49] Jon: stuff. Yeah, because it’s a slight scale, like experience counts for something the same way as being a good dev would take experience right to learn all of the nuances and learn the language really well and how to do it properly and testing and iterating, all those things are still a discipline. So to expect the people to be really efficient
[00:04:09] Jay: After a two year course,
[00:04:11] Jon: not likely, otherwise we’d all be able to dev after a two week course. Right. And be really good developers as much as well. Well anything you turn your hand, we don’t take two weeks and you’d be awesome at it and you’d be done
[00:04:23] Jay: woodwork courses. Smash now,
[00:04:29] Jon: next to one.
[00:04:31] Jay: Wow, haha
[00:04:33] Jon: that was too easy. Anyway, if we’re looking at then how to do it. Because if you were to go into a team now and knowing the, the landscape of all the technologies and what there is, how do you take something that, you know, because the industry, a lot of the open source tech necessarily isn’t self service paradigm, but it’s a lot of different text. Should we talk
[00:04:57] Jay: about what, what people did say 89 years ago and then they, well, well, I think it’s, it’s important, right? Because the way that you, the paradigm of self service has changed so like back in the day, I think people would like say you can put a request in and get a Linux box or something like that. And that’s, that’s your self service. Like you can self serve by using a ticket to get a really not outcome driven thing and that not outcome driven thing.
[00:05:33] Jon: I just said, yeah, you don’t have to wait. It’s kind of no wait time you can consume, it’s commoditized and you can go and get it. But without the risk of also going into the account.
[00:05:44] Jay: So the next level of that I think is then like where it met Cloud. So people maybe did that 10, 12 years ago with a request to a team like Linux team or a Windows team or something like that. And then they would get a box that they could access and then a few years later and they’d wrap that thing with Jenkins or, or, or something where it’s like, oh, I’ve got some manual stuff that I have to do, but I’m just gonna automate it. So you don’t have to put a ticket in and now you can, instead of requesting a ticket, you just go to some Jenkins front end and like click a button, put your thing in or whatever and then you get a Linux machine or a Windows machine or whatever that you can access. And that was like self service because you’re not really waiting for a thing. You’re just, but it’s not really attached to any sort of value and it doesn’t, it obfuscates a bunch of like stuff done by other people to really make that a thing. Like someone has to go in and you know, maintain the scripts that it will take them to one build, whatever it is that they’re doing, like getting the operating system, the storage, the networking, all of that configured in a potentially private cloud scenario and then fast forward a few more years and cloud now exists and you could get that same outcome. So a Linux box, let’s say, and you have like VPC S and networking and all of that stuff that’s now defined as a template as code or, or whatever. So the way that you’re self serving and the operational overhead is smaller because you don’t have to write scripts, you’ve just got to write configuration, right? That’s kind of changed. And now it’s even easier because the configuration that you have to write is even smaller. Now, it’s like you, I can have a, you know, Docker image that has Linux in it or a Docker image that has windows in it, a window server or whatever and just point it at a cluster to run, right? So I don’t even have to the, the configuration that I have to now maintain as a person creating self service isn’t all of the operating system, the networking, all of those things because it’s, that’s already taken care of somewhere else. The way to provide self service. If you’re that team that’s trying to provide, it is easier in one aspect because it’s less to maintain. But it’s hard because you have to make the experience really good and you have to think about the outcome rather than what they’re self serving.
[00:08:26] Jon: Yeah, I think, I, I think I know what you mean. So now you’re saying like containers of simplified things. They don’t have windows server in them though. By the way, they’re just gonna be like obviously it’s just gonna be could be scratch image, it’s just
[00:08:38] Jay: window server. Yeah.
[00:08:39] Jon: Yeah, it could be just a scratch image of barely anything in the container. That’s what you want in really like of course the libraries of just the bare bones of what you need, that’s how to do
[00:08:50] Jay: it well, but
[00:08:52] Jon: promote you basically not taking advantage of it of
[00:08:56] Jay: containers. Yeah. No, but I was like saying the same the equivalent outcome over time, right? So I
[00:09:02] Jon: see you mean the journey that we went on now? Yeah. Yeah. Yeah. But then, so you’re saying that there’s no containers and that’s simplified a lot, but I’m still confused with the self service. So you still have machines, V MS like workloads are a thing C P U is gonna be a thing needed, right? So processes, apps are all processes in the end. So they’re gonna need processing power to run them something has to get them there and those applications have to be done and delivered in a way that makes sense. I’ve already spoken about well, architecture frameworks and all these other opinions that the cloud has on certain levels of enterprise. So it’s not just that the technology of that bit is the end as in like just use containers and you don’t. No, of course not. Yeah. So I’m saying, how do you do self service though? Even if you’ve got containers, that doesn’t mean you now have self service or just because the devil got containers doesn’t mean that you now self service, you don’t need to do anything.
[00:09:56] Jay: Well, it’s like partial, they might be able to self serve a part of their workload which is Where a lot of organizations probably stop. Like they give someone access to a multi-10anted cluster or something like that. And there was like, oh yeah, we do self service. You can go and get some compute and some storage and things like that. I see.
[00:10:15] Jon: Yeah, I suppose.
[00:10:17] Jay: But then there’s, that’s not
[00:10:18] Jon: like this possibility of the container, which means the developer can use their own machine. Yeah. Right. That’s right. In like iterating, the type of technology that gets deployed is consistent even locally. Whereas before that’s a change because you wouldn’t have ever had a, you know, we’ve had to do all the vagrant stuff. We’d have to like, mimic out what it was gonna be in, you know, in the real world, outside of depth, at least you got that. But then what you’re saying is people might just say self service means to developers. I’ve got a cluster that I’ve just created and everyone’s going to share it. And if you can deploy your app in it with a deployment file that’s self service.
[00:10:58] Jay: I, I think there’s because it’s self service, what some people can be such an ambiguous term. Some of the, you know, people in the industry might have defined that as self like having is, is self service now that you have cub is self service. Obviously, we don’t think that’s true, right? Because the developer isn’t able to self serve for all of the bits that they might need that there are patterns for in that organization and that’s what we’re, that’s like,
[00:11:27] Jon: yeah, exactly. There be wait time even to get access to the Q and A is presumably was wait time
[00:11:33] Jay: potentially. Yeah, exactly. It’s not like someone has to tick a box or, you know, give you access or, or put you into the right
[00:11:39] Jon: group, whatever. And then environments I’m presumably to be wait time,
[00:11:42] Jay: name spaces. Are you giving people the ability to create name spaces in that cluster or not? And then what happens? What do they have their own limits to sort of manage or are you configuring that for them and stuff as well? Like there’s a level of self service? And then when it comes to like pass their workload. So they’ve got an app, let’s say, and the app needs, I don’t know, some sort of cloud resource or database or some storage or whatever else. How do they get that? How are they gonna get access to either the people that have the skills to give them those things or a well defined thing that they can just configure in a way that they have the knowledge of to do to just get the outcome. So how do they do it, John, I was
[00:12:31] Jon: still waiting for you to answer my question. How do you take the technologies of the industry about them self service for the things you just mentioned? So it’s like, so you’ve already give us some examples. So it’s like obviously Q eight is a certain point, but you’ve just said that’s not really true self service. So so like what are the technologies that you would use? I guess like what are the self service technologies that exist in the industry that you could take? That’s what I’m saying because there’s a paradigm that’s going around that self service, which is obviously a good thing. Nothing like it’s obviously effective to have productive people getting things they need. So how would you look at like one, what technology would you want to standardize on?
[00:13:13] Jay: Well, maybe the industry is standardized a little bit on some of this technology, right? Because I don’t think you would find a single DEV ops or platform engineer CV. That doesn’t say terrible,
[00:13:26] Jon: awkward.
[00:13:27] Jay: Don’t hire John as a platform engineer.
[00:13:30] Jon: It’s quite strange. I can’t remember where it was but there was some market research. Ah, I can’t remember the exact numbers but it was not, it was quite low on what I know. I know. I mean, I would get a bit dubious sometimes with, with the research but the information was way higher than terraform was which I found really surprising bamboozling I even think was higher. So I don’t know how they’ve obviously got. I mean, I’ll find out where that was, it could have been in the flex maybe or something. It was definitely something in some report I was looking at, I’ll find out because it’s not very useful, but I was shocked because I assumed it was like going to be huge. OK.
[00:14:11] Jay: So let me change that or, you know, C L or whatever it is, right? So there’s a, you’re gonna use a language to define the thing to define the configuration of a state that you want in cloud or private cloud or whatever it is. So one that would be the, you know, basis of how you consume something, not self service. That’s just how, how to define the thing that you’re going to consume.
[00:14:39] Jon: But would you pick a certain tech because obviously just saying this configuration, I mean, yeah, so
[00:14:46] Jay: I’ll probably pick Terraform because one it has, like, you know, you’d find the skills in the market really easily. It’s extensible. It has great support overall. You know, the portability isn’t great because obviously you have providers that you use in Terraform and, you know, the Aws provider isn’t the same as the Google provider or whatever. Yeah, exactly. Right. So, but the skills that you learn using Terraform means that it’s hopefully not too difficult to port. I mean, it’s going to be difficult to port, but it’s not as difficult to port. Say if you were using like cloud formation versus arm templates or whatever else. So, yes, I picked Terraform, then I would try and figure out what my company’s policies are, security policies. Like how am I gonna use Terraform? How am I gonna let other people know how to use terraform properly? How am I going to centralize the patterns that I’ve created in Terraform like modules? Is it just git am I publishing them somewhere? Like what am I, what am I using for that? Do you have any opinions or answers in this space that no, of course, stay quiet. No.
[00:15:57] Jon: Listen, I think, I think you’re right. I mean, it’s good. I, I probably agree. Most people I’ve seen on, on the CV, irrespective of this report, most people CV S I’ve seen tend to have tariff form on them. Not, is it because the
[00:16:10] Jay: job application says only form need apply?
[00:16:14] Jon: But I just found that a bit bewildering. So I just thought I’d say it because I, I remember like being really bamboozled by that start anyway, myself. Not, doesn’t really make sense to the market that I’ve seen. But then Terraform takes a certain skill level, obviously. So people can learn it, but it’s changing these new API S and cloud services. You kind of have to learn the DS L framework of terrible, even though there’s loads of modules out there that you can reuse, you still need to know how
[00:16:39] Jay: to, it’s good, right? That’s the thing with these modules. Like how are you gonna know if it’s a good module? Like
[00:16:45] Jon: you can’t tell the quality of the module but then there is linting and the check. So I guess all those things like standardizing on those I think makes sense and test the to the check off of the world, putting those in C I pipeline and for them
[00:17:00] Jay: even like frameworks like terra test or whatever that you can use on the actual thing,
[00:17:05] Jon: that the actual thing. Yeah. But then also though the modules, I think you have to work out how much, if you think about self service, you need to work out how much somebody knows about that service first. But you have to think, right? There’s a developer, they might not gonna know the 36 parameters of the configuration of that terror module, right? So maybe most of these aren’t particularly relevant. So I need to work out what is relevant to them in the business and what isn’t. And so if I only want to give very few choices to people in relation to those that service, so it could be just if it was a database, you choose the type of database. But then from that point, it could be just the database name and that’s it. Or maybe it’s data based region, right? So it’s like how much is configurable from them and how much do we want to standardize on?
[00:18:00] Jay: I think that’s really where the value is, right? Because it’s super easy to just give someone access to do something, but it’s hard to make it easy to consume, right? So, so like even, I don’t know, say something really mundane taxis, right? Anyone could just like put their hand up and get a black cab if you’re in London or whatever. But it obviously Uber had a or any of these taxi companies, they had, they did quite a lot of good engineering to make it accessible and easy for you to press a button and for the taxi to come to where you are, right? That that took a lot of engineering feat. And just in the same way like being able to just type in the name of the database that you’re gonna gonna want or say the distance type or the storage amount instead of having to configure whether it’s going to be encrypted at rest in transit. All, all of the other things that you would have to do, like, with skills to kind of simplify, like it takes time experience, effort to do all of those things. So, yeah, I’d have something to do that. Do you know of anything that does that?
[00:19:05] Jon: Yeah, I think there’s like, there’s open source things that do it. There’s telephone providers and Q and A, that people have created different companies have done it to a point
[00:19:14] Jay: Tatis, that’s one TF operators. And yeah,
[00:19:18] Jon: there’s different Terraform operators. I think it’s the terra operated by has but I think that works with their, I think it’s to the offering. But I guess there are technologies in that space where people have looked at it more from a Cuban, a perspective of like how do I back into Q and A to operate.
[00:19:37] Jay: But because that’s where presumably that’s where their apps are. Exactly.
[00:19:41] Jon: That’s what the developers are already maybe doing, deploying in a place
[00:19:45] Jay: already standardize experience based on what they already
[00:19:51] Jon: an interface, which is Q and A is I’ve already learned that rather than me then going off and saying go and learn Terraform as well, you like actually can I bring tariff on to Cuban? Because then Terraform experienced no human experience to terra form.
[00:20:06] Jay: Because then you also if you if you’re doing it without Cuban, then you also have to have like something to run to Terraform and that’s C I, so you’re moving all of the, you’re then changing the experience for the developer to get some, well, it’s just you’re instantiating something from different places. So, so like you might get your database via C I but then you’ll get your, you know, compute and networking or whatever via, I don’t know, get s or one away from it
[00:20:43] Jon: to be fair. Most cases nice, nice
[00:20:45] Jay: self service John.
[00:20:47] Jon: Without it, it would be mostly tickets.
[00:20:49] Jay: So you want an environment and their application and their components all to be managed in the same way because that’s the, that’s the artifact, that’s the artifact that that developer ships, right? It’s the whole application together all the services that, that make up their application and for that to be defined as in different ways as separate things just doesn’t make sense. Yeah,
[00:21:12] Jon: I think there was a blog as well. So I’m just referencing those of other people, a blog of Spotify and they had, oh what was the metric? Basically, it was the number of tools that the developer had to interface with and there was a there was a metric associated with that. I don’t think it was like
[00:21:31] Jay: high is bad,
[00:21:32] Jon: high would be bad. Yeah, but I don’t think it was like cognitive load necessarily. There was some, some specific metric, but I can’t remember the terminology of it. But if there was obviously a lot of tools that they kept having to use oh context switching. So they classify context switching as the amount of tools you have to interface with. And if you, and that’s how they measured it, it’s like if you keep switching to tool, to tool, to tool, that means you’ve context switched away from one thing to another to go and get an outcome and then back to maybe another tool and then go and get a different outcome. So that obviously for them is like quite unlike suboptimal, I guess that’s what really we’re talking about. If you standardized on a common interface, which is Q and A is, then there is only one tool and you’re not switching context like repeatedly all over the place to try. And
[00:22:21] Jay: it’s funny that because there’s obviously nuances to that, right? Let let’s say you’ve got a tool and you’ve say bought in another tool or you’ve integrated another tool depending on the con depending on the quality of that integration, you could be contact switching again, right? So let’s say, I don’t know bad example, but because these are good products, but um let’s say like github, it now has, you know C I and it also has like security integration and things like that if they were badly integrated. Um then maybe it has like a different, different front end or something like that. So it looks like and feels like different tools. The experience isn’t consistent. It’s a hard kind of learning curve to understand how the to the new tool has been melded together in. But if it’s a good experience, you know, it’s consistent, you can click through it in the same way. The developer doesn’t have to learn whole new paradigm because you’ve just exposed more information, then the experience is good and the context switching is less. Yeah. Yeah, because that, that happens a lot
[00:23:30] Jon: in this industry, I suppose you would have then switched context to a point. I think it’s just the degree, I guess. Then you’re saying it’s the degree of complexity of the thing you’ve switched to, which is then taking more time and energy because the quality of that was bad. So if you actually can’t get an outcome quick, even after you’ve context switched, there’s obviously project switch in itself and there’s a time investment on whatever you’ve had to switch to, to get the outcome. So
[00:23:54] Jay: all of it together is the,
[00:23:56] Jon: no, that wasn’t. They just had a number of tools. I’m just saying no, but actually if you to be a bit more granular, you could like what you’re saying is that you could have a bad tool or a bad implementation of that tool. And so it’s not just the number of tools because it’s the quality of the tool and how, well it drives the outcome on top of how many of them there are, but it’s just hard to measure, I suppose unless you just get all like the data metrics. But I suppose for self service though, if you are standardized on Q and A, which is what you’re suggesting, then there’s now one tool, then I guess you got the quality of what it is. There was
[00:24:28] Jay: a quote somewhere um that said like Cuba is, is now like the default operating system for all of compute networking and everything across like the whole world, right? And that’s so like something like an orchestra to schedule or whatever. It’s so true, like cloud providers themselves run, run this come from. So in some aspect, you’re running something that looks like this and the closer you are to to it, the more value that you’re gonna be able to drive from it potentially but abstracting away enough of the, of the things that don’t offer any value. Yeah. So I think.
[00:25:08] Jon: that’s what you got to understand your customer, isn’t it at the end of the day? And I think that’s the point of if you’re talking about self service for developers, the technologies aren’t designed for those people. It’s just a fact they were designed for specialists who understood cloud and it didn’t have an opinion specifically
[00:25:25] Jay: because
[00:25:25] Jon: the business needs to define what it is in relation to the cloud. And the cloud doesn’t have an opinion either because we don’t know what you need. We’ve got those of customers here configuration of all of the different things you can do. So somebody has to go and decide what the right level of configuration for those things is. And then on top of that, what the input is from somebody else at the minimal amount of effort that they have to put in to get the outcome.
[00:25:49] Jay: And they, because it’s configuration, they change their opinion, right? So recently, for example, when you created free bucket, well, previously, when you created a free bucket, it was publicly accept, that was the default. And fairly recently they changed it. So the default is now is privately accessible. No one gets access right? It’s a massively impactful change for something so small but like
[00:26:14] Jon: in some, yeah, I guess the design of it back then was like public cloud with a public three bucket because it kind of began with
[00:26:28] Jay: us.
[00:26:29] Jon: So that kind of makes sense. But yeah, that’s taken so long to make change that
[00:26:34] Jay: 15
[00:26:35] Jon: years, 15 years and eight bazillion pounds of people getting compromised like you know what, maybe like a default denial on traffic, like maybe any, any good no been hacked now, I really think we should change.
[00:26:59] Jay: No, we’re sticking by public cloud.
[00:27:01] Jon: Public cloud. Yeah. Wow. So um but yeah, the I guess you’re saying you choose Q and A is the old terra forms of the and then check off and linting and terra sets and all these other things, the stack sets for some reason.
[00:27:20] Jay: What else? Obviously an operator to put it into communities, look for one. Yeah, there’s loads that exist and then something to make it kind of declarative. So probably use say, you know, flux or a or something like that to wrap it all so that I can get a consistent outcome in every environment that I’m in.
[00:27:40] Jon: You could get a consistent the developer, right? I’m
[00:27:43] Jay: designing it, right? For yourself. For the developer, you asked me, what would you put into?
[00:27:47] Jon: Just because you said you’d use flux. So you get a consistent outcome. But as in like you as in the developer, you or you as in what you’re providing. So it is a developer using flux or you just mean that you’re gonna use flux,
[00:27:59] Jay: I would use flux for probably the platform level and then depending on the skill set of the organization, they would, you know, would figure out what makes sense but how
[00:28:10] Jon: myself serving. So now I’ve got there’s a bit of cute because
[00:28:14] Jay: you already use GIT. The developer already knows how to use GIT, right? Presumably because that’s there every day. They’re
[00:28:21] Jon: checking like an app in GIT that I go to to then be like, so yeah, I know how to use GIT and I can do git commit but that’s got nothing to do. Like I can’t do like git show cloud resources or something, right? So just because I can commit code, why would I suddenly know about the cloud service?
[00:28:38] Jay: You need to, why do you need to know how do I get
[00:28:41] Jon: them then? So
[00:28:44] Jay: you go through some level of building a pipeline and deploying code. So you’ve built a container, you’ve now published that container and then maybe in a separate repository, you have like environment configuration where you ask for that application to be deployed somewhere as well as all other dependencies that you need. And your interface is still, that’s
[00:29:10] Jon: what I’m saying about the dependencies I need. one of them is a cloud resource. So yeah, you
[00:29:16] Jay: terraform and terraform operator. We already talked about
[00:29:19] Jon: that. Yeah, I’m just saying now how a developer is just in git certainly can now understand that there’s a terraform operator.
[00:29:27] Jay: Oh right. So how does a person in an organization know to use these services? Like where, where
[00:29:35] Jon: to like you’ve given me some, like you’ve said there’s an operator which I don’t know anything about because I’m a developer. Um How do I suddenly know how to consume this operator?
[00:29:47] Jay: Some documentation or searching something maybe like a module library or you know, some sort of catalog that exists some somewhere that you consume?
[00:29:59] Jon: And how do I know what to put in this spec
[00:30:05] Jay: uh because it has documents documentation to say what you need like optional, optional variables and you know, things that are already defined for you or not optional, whatever.
[00:30:19] Jon: So to be like (pause) there’ll be a bunch of things in here that I might not really fully understand. But then, but hopefully
[00:30:25] Jay: you understand all of the things that you are given an option to change, right?
[00:30:31] Jon: Ok. So there’ll be like a spec or,
[00:30:33] Jay: or, or like a really good description obviously that helps you understand because you’re not, you’re not gonna get it all right away, right? But what, what an instance type, how do, how do I know which instance type is? Right for me. But it’s probably important because you’re gonna have developers that are a little bit more used to using cloud services and maybe used to the terminology or whatever because their experience is different, of course, and then people that just aren’t so you have to, to do self service. Well, you have to give a common way of each person with their experience being able to get a consistent thing,
[00:31:10] Jon: right? OK. A common way for reach experience to get a consistent thing. So, but then if the experience is different, which is what you’ve just said, how do you get a common way with inconsistent experiences? Because it’s like, so like for example, isn’t high but I’m consuming something that so
[00:31:28] Jay: you simplify but let’s say you don’t want so Cuba as an example, right? Let’s say let’s say you put a wrapper over um and you abstracted even Cuba away from Cuba, no, away from the developers so that they had like, I don’t know something to just go into and throw it, throw an image out or whatever and then that was always. Yeah, exactly. And then something bad happens and you’ve now like the developers that know how to potentially or could investigate and trying to debug and all that kind of stuff. It makes it harder for them to debug just because you’ve made it easier for someone else to get the first outcome, the first outcome being deployed my thing. But to make the whole cloud experience self service, it’s deploy, manage run, you know, observe all all of the things. So
[00:32:23] Jon: you’re not just can’t just facilitate, just developing.
[00:32:26] Jay: Yeah, you can’t just facilitate deploy
[00:32:28] Jon: one Thing. You’ve got a life of it and
[00:32:31] Jay: it’s got a life cycle and you’ve, you’ve got to do it in a way that doesn’t like abstract away the value or the experience that people might have.
[00:32:40] Jon: So you would choose and give them a way to look at this. The operator specs to say here’s a bunch of operator specs,
[00:32:49] Jay: not the operator
[00:32:50] Jon: here with the spec of the custom
[00:32:52] Jay: resource here is a way to use these custom resources to get, you know, an R DS or s
[00:32:58] Jon: exactly what I mean. So they have to learn in some ways,
[00:33:03] Jay: not really learn them, they’re just documented and it’s just learning living documentation, you know, maybe
[00:33:10] Jon: telephone operator keeps changing just it’s like keep updating the docks,
[00:33:15] Jay: maybe it’s self documenting. Yeah, maybe it just, you know, it’s
[00:33:19] Jon: right. And would you provide just one type for everyone or would you have different types of database configurations for different scenarios, like a big database or like Aurora database or a post database and then different flavors of each one. Good question. I guess that’s a
[00:33:34] Jay: different version to a certain degree down to the operator because it has it, right?
[00:33:40] Jon: Um Because obviously the versions to be versions
[00:33:42] Jay: of the, but that would just be like configuration, I guess. So you would just be able to state the version that you want, making sure that that version is supported and you only get the supported versions and then you obviously need a way to upgrade versions and manage the lifecycle. Yeah, exactly. Yeah. Sounds like I’ve solved it. This is
[00:34:04] Jon: a just be a magic operator that yeah, that
[00:34:08] Jay: check checks against security policy, maybe like tells you the cost of the thing that you’re about to run because you, you’re offloading, you know, there’s this whole shift left security movement, but people don’t really talk about shift left in terms of cost and being able to like make developers at least responsible or you know, make it visible, aware of the decisions that they’re making. And cost is like a really good example of that like Infra costs. Yeah. Yeah, exactly. So an API in is, is an API that you can use with terraform. So using something that wraps all of that
[00:34:50] Jon: cool. So Q and A is an operator around terraform standardized modules or standardized configuration of terraform around those modules or around the operator of those modules. However, it’s gonna work documenting them versioning in line with the management of them and security testing don’t
[00:35:14] Jay: write your own operator guys
[00:35:16] Jon: and security of them. So you’d be like you and then also awareness like visibility of those things and then all of that would happen somehow inside of the account, the cloud account. What about the I M permissions and all the identity management part, identity management and all that kind of stuff. Yeah, I
[00:35:34] Jay: guess you know, you need some, some way of managing the things that get created and whether that is like depending on your kind of security profile flat, which is not good, not not recommended or specific to just the workload that needs to access.
[00:35:50] Jon: So you have to make sure those permissions for each thing that you’re doing, the operator had the permissions to go and do those things to provision it inside that account.
[00:35:58] Jay: Exactly which is, which is complicated. Yeah, yeah, but there are solutions out there that
[00:36:05] Jon: which is already a thing anyway, because terraform basically is godlike, isn’t it in most organizations? Because it literally can create all of the things and all the I am and all the things in all the accounts centrally usually most of the time, but that’s fine. That’s OK. What is it like really confused? But doesn’t that have like loads of
[00:36:29] Jay: least privilege doesn’t apply to terraform in C
[00:36:31] Jon: IC, I doesn’t, that’s fine.
[00:36:36] Jay: I never gets
[00:36:36] Jon: hacked. C I never gets hacked. All right. So that’s really good. So basically you take certain technology stacks, blend them in for consistency, make some decisions on like how people are already working, try and standardize on that way of working and then take technologies and extend those technologies around other technologies, more industry aligned to be like, actually let’s now create a pattern around all of this where it becomes more self
[00:37:03] Jay: service. And you’re not just doing this for the sake of doing it. Although it sounds really fun to do. Um You’re you’re obviously doing this so that you can developers can deliver software quickly and consistently in a secure way so that they can actually focus on delivering business value. All right. Well, there you go.
[00:37:23] Jon: So solve problem. Yeah, obviously reach out to us. You got any questions? Hello at cloud and plug dot I O and then cloud unplugged on Twitter which goes to find us and on the other platforms linked in. Cool. Speak to you soon. Thanks all. Bye.
Part of the Appvia family.