Transcript: DevOps Decrypted Ep. 6 - A recap to the future

Join us for our final episode of DevOps Decrypted this year as we recap AWS re:invent 2021 and talk about what we predict for the future of DevOps as we approach 2022. We look forward to seeing you all in 2022!

Yo-ho-ho, everyone and welcome to another DevOps Decrypted podcast. This is our sixth episode, Recap to the Future. I'm your host, Romy Greenfield, and joining me today I have Jobin and Matt. So guys, what do you want to talk about today?

Do we have to talk about DevOps today? It's the holiday season. I want to kick off loose and let go off and have our holidays now, don't we?

Yeah, we can just talk about skiing holidays that have been cancelled and what presents you're going to get your grandma or we could talk about AWS stuff.

That's a good idea. So yeah, we could talk about AWS. It's the turn of the year, I guess when this goes out everyone's going to be in full on holiday season which means predictions time, right?

Yeah. I dubbed it the holiday season already kick started by the AWS Reinvent. Usually going to the Reinvent is like going on holidays, it's so much fun, right?

It is. Yeah. I've only been to the London ones. We go basically to a gigantic vast conference centre over in East London, called Excel. I think there's also one called Word and PowerPoint somewhere. No, that's a terrible joke, but yeah, Reinvent over in Las Vegas.

It's a big deal. I mean, there are too many things happening in parallel. You just don't have time to be everywhere, right? I mean, you'll be running all around in the casinos and you'll be tempted to obviously do some gambling, but then you have to attend all these Keynotes. You don't want to miss any action, right?

It's a real hard one, isn't it? I remember first going to the London one, probably five or six years ago and the proliferation of strands and threads and streams and announcements that were coming out all over the place, I think it was a bit intimidating actually and I can only imagine that's got worse. I feel that when I look down this list of announcements that have come out of Reinvent over the last week or so where there's just so much stuff.

Yeah. I feel you.

And I think it's a reflection of how AWS is now a very mature business and people are using AWS not just for storing some files in the cloud like we did in 2009 and not just for virtual machines, but Amazon have come further along the supply of services, higher order services and taking design and implementation stuff away from us in a good way. And so there's just loads of it, right?

Yeah. I like the fact that it's not just new services that's coming up, I mean, that's always something to look forward to and AWS really separate social with coming of the really good services that improve our lives doing the work. But at the same time, all these existing services that keep improving it to where we didn't aspect in the past there's a lot to talk about. But yeah, the kind of improvements they're making it's mind boggling.

Yeah, it absolutely is. And I don't know, so we found, actually Jobin, you found on a good page summarizing some of the best of the announcements. Even that was a bit too much for me to digest but yeah, we've been through it and picked out a few things that we want to go into that are probably relevant to a DevOps audience that speak to the particular specialisms that people have got that like to listen to the podcast. So yeah, should we do that? Should we go through some of these things?

Yeah. My favorite one is the CloudWatch RUM and mainly because I thought there would be rum involved.

Well, there's definitely rum, if it says there's going to be rum.

It's in the Christmas spirit, literally, so.

So I quite like this one. So RUM, I think... Quick, Google quick, is real user monitoring.

Yep.

Yeah.

Yeah. That sounds like something that's an obvious thing that everyone's doing, right? Real user monitoring.

Yeah, you'd hope so.

Definitely. And I mean, we had talked about monitoring quite a bit in the last episode so we all know how critical it is to design any application, obviously, in terms of law, scaling and performance. So I guess it is one of the key things that AWS has tried to address. No surprises there, I guess.

Yeah, I guess so, and it's an interesting one because we look at monitoring as meaning so many different things. I mean, as you said we spent a decent chunk of time last time just going through monitoring, whether it's like logging or checking that ports are up or who knows what. And this one looks like an interesting new entrant to the market and I think it takes Amazon a bit closer to the territory of companies like Dynatrace, New Relic-

New Relic, yeah.

They're doing that sort of thing, right? It is real user monitoring. So I'm interpreting real user monitoring as being about checking things like errors that come off of consumers' web browsers and using web bugs to track how long it actually takes to get content delivered to a web browser like from the client perspective and looking at the same territory as client end tools, things like I don't know, Sentry, doing that. And this is the first time I've seen one of the cloud providers doing this unless you've seen anything else?

No. I mean, that's absolutely right. So this one is monitoring the application's client side, performance side, so what's happening on the client machines and not just on the AWS side of things. AWS is doing, of course, hosting, but there are a lot of services that AWS house, which improves the client side performances the ones that gives you caching options and stuff.

So with RUM, I think they're going to look at where the performance is impacted, whether it is client side or service side, right? So there's actually CloudWatch, by giving it some CloudWatch, you get the breakdown of where the application performance is impacted. Good idea. You don't have to rely on third party applications anymore. You can do that right there in CloudWatch, which obviously is free in many cases, so.

Yeah. Well, it depends on how you use it.

Depends on how we use it, yeah. Absolutely.

We managed to accidentally get some rather large CloudWatch bills in the past through turning things on, but frankly, benefiting from it. It's great that we can get some of these things for free, but equally, there's a price on this sort of information. And it happens-

Yeah. I haven't drilled down into the details, but it looks like there is real time monitoring across different geolocations, different browsers, different devices, enabling you to optimize the performance. So there's quite a lot of things happening here, something I definitely want to try out at some point.

Yeah. Another I think, it's probably like a lot of the similar initiatives that Amazon has started off where there's probably not a huge amount to it right now, but I think Amazon are quite famous at releasing things that if it were a mature product, then there would be a lot more to them. But yeah, give it away for free to start with and they see what the appetite is for these things and build on them over the next few years. I'm quite excited about this RUM. So yeah, there you go. Rum for you, Romy. Brilliant, huh?

Greatest.

Yeah. Start the holidays with a bit of RUM.

Yep. Very excited.

Speaking about all of these predictions I mean, one thing I liked about it, we talked about container recession quite a bit in the last episode, right? Now, they're introducing caching to ECR and ECR is one of the services that we use on AWS quite a bit, especially in the container world to host the Docker remeasures. So it's the elastic container registry, right?

I think by introducing caching, AWS is doing a service to all of us because a lot of the performance just in the past to do with how fast you can fully measure from DataHub or the other public registries available out there. With the intention of caching on ECR, I think that performance will be impacted in a good way. It'll reduce the time for pulling images from the public repositories or registries.

Yeah. And I think this is another entry in the ongoing kind of Amazon/Docker slightly public battle going on here. I think it's great to have the pull through. And I say that because things like the limitations that are on Docker hub know I've been bitten by that a few times in recent weeks for public images coming across where you can only download a certain number of them in a certain amount of time. So there's that. Also, as you say, the performance, brilliant. If you've got things caching in ECR then they don't have to be downloaded from the Hub.

So, and again, we're probably talking about relatively small amounts of time saving, but given that with DevOps, we're trying to encourage people to do tight feedback loops and iterate quickly. That's only going to help. The other angle on this which is interesting, I feel is a security one. And there's another security announcement in this, which I'll come to in a minute, but having those images or having the ability to cache images that are maybe public or semi-public, or even private images from somewhere else means that in your bill processes, you're pulling all the images from the same place now. They will come from ECR, which again can only be a good thing because you've got a centralized place where all the images come from.

And I presume if you have any scanners out there, maybe something like that to select, which we're going to look for vulnerabilities on doctor images, you can potentially run that against ECR now you don't have to go out and do that during the bill process, maybe do it in advance. I don't know, just thinking out loud.

Yeah. Yeah. Interesting. You mentioned scanning, because that was the other thing I was going to talk about. There's this thing called the AWS Amazon Inspector. So around continual vulnerability management. So I think when we get onto the predictions bit, we'll talk a lot about their SecOps being bigger and bigger and bigger. And one of the things that I've noticed over the last few months, maybe even going into the last few years is that doing anything with containers anymore, especially when you're using public images, either as your base image or as in an interim build stage you got to scanning. Even if it doesn't pick anything up because the quality of these images is so good these days.

Just to have that assurance that you are as safe as you can be or if you're cynical to tick off some boxes on an audit requirement. Yeah, absolutely essential. So yeah, we've seen Amazon Inspector vulnerability management service, which is looking at vulnerabilities in images and across your virtual machines. I think it even goes into scanning something almost akin to old fashioned disk scanning for vulnerabilities on EC2 instances as well. And yeah, this sounds really, really exciting.

Yeah. I was just reading through it. It's interesting that they now have integration with AWS organizations, so you don't have to do it on an account level. You can now set it up for the entire organization and once you set it up, it'll scan through, as you mentioned, the EC2 instances, EC variables which is all of that in the entire organization. So the different accounts that you might have. So we could actually potentially do it for [inaudible 00:12:46] or go to a customer and set it up for the entire organization on the customer side. Right?

Yeah. We'd love a bit of that. So we've done some decent amount of work in the last couple of years around AWS account organizations. I was cynical about it in the first place as I always am. No, actually I'm not always cynical or am I? Why have we got all these accounts and the reality is we have got 100s of Amazon accounts and they're great for separation. So production, staging, development, put all them in different accounts if you can, for separation. While everybody who's technical in Adaptavist, sorry, can get their own sandbox account for doing what they want to. And so we're very liberal around that.

Yeah. Another interesting bit I was reading through on that particular one is there's the integration with Amazon EventBridge. So you can integrate with event management and workflow systems and then connect it with systems like Splunk and even Jira, so you can trigger automated remediation. That's very interesting. I found that very interesting, especially with us being Atlassian partners and all.

It's probably a good opportunity for us to talk to our customers and say that how you can connect those sort of things with maybe Splunk putting all the locks into Splunk and maybe even indicating it with Jira will automatically create tickets as soon as you come across any vulnerabilities. Yeah. Right. Maybe if it is critical... Maybe even now that we are Slack partners, sending messages to the channel, let them know that, hey, there's a critical vulnerability, you better get going. Right?

Yeah, absolutely. And yeah, I'm very interested in this from an internal perspective because we're already doing things like using guardrails on Amazon, which would create these sandbox accounts for people and they'd only let you do a subset of things. And whilst not wanting to squish down the innovation that people are doing and the experiments that people are doing, it gives us a little bit more confidence that bad things aren't happening to be able to add this new inspector into the mix. Yeah. It's brilliant.

Yeah. And speaking of security, right? Another thing that I liked a lot about this, AWS announcing that network ads analyzer that will help to identify the unintended network assets on VPCs. One thing I was really scared of when I started working on AWS initially was, it's pretty easy to sell VPCs and all the different things within a VPC subnets network, access points and everything. But at the same time, I was a bit scared.

Am I actually opening up any holes anywhere? And am I unintentionally opening it to the internet? Obviously, I would then pull in others from different teams to take another look at it, just to have some peer reviews. Now it seems like AWS is coming up with its own services, which will help you identify those unintended network accesses. It's very reassuring, to be honest.

There's about three or four things here, which you conclude together how and as you wish depending on your risk appetite to make sure that the baddies don't get in. Or if you... Well, I think you have to accept that the bad people will get in at some point through something and the worst thing about that is if you don't know about it. And yeah, another tool that's going to help identify that. So yeah, if you can't stop from getting in then you or better make sure that you know what they pin in, right?

Or that they're still there and kick them out.

We're getting back into ghost stories now. It's going on there any minute now.

Yeah. The funny thing is I was always scared about this AWS shared responsibility model in which the responsibility of keeping our network securities is on us, not on AWS. And it's a good thing. It's a good thing in many ways, but at the same time for some reason the word responsibility scares me a lot, which of course, we're allowed to make sure that the network is closed and that we are not letting anybody else come with these traditional services. And I feel a little bit more confident and I'm pretty sure a lot of folks who are starting on AWS will really appreciate it.

Yeah. I also noticed they've got the AWS Chatbot, it now supports management of AWS resources in Slack so you can help remediate issues in AWS workloads by running AWS CLI commands even from within Slack channels. So that's quite handy.

Yeah. That sounds good. I mean, part of me is like, "Oh, that's going to get you away from your configuration as code-type scenario," but it doesn't have to. And I think yeah, we're seeing more and more of these integrations with things like Slack and the ability to use, I don't know AI, a bit of ML to convert somebody sending in a ticket saying things like, "Please, can you create me an EC2 instance to do blah, blah, blah, blah, blah, blah." And automating that sort of thing to give people what they need. Yeah. Fabulous. Fantastic. And yeah, more things are bringing up slowly.

So anyway, this one is specifically interesting because it seems like it will let you run AWS CLI commands from Slack channels. I remember, I think it was during one of our hack days, I think one of the teams was looking at creating AWS CLI commands from... Not specifically AWS, they were looking at in-working bills and Jenkins from Slack that sort of thing. And this one is very, very interesting because it's pretty much doing the same thing, but actually running AWS CLI commands which is even better because you can do quite a lot of things using AWS CLI, not quite a lot, almost everything that you can do on AWS using AWS CLI. So if you can do that right from Slack, that's really powerful.

Yeah. And it could be helpful if you're in the middle of an incident and you just need to run something really quickly, maybe someone's alerted you on Slack. It doesn't have to... It could be that something needs changing instantly and then you could catch up with a forward fix, like a poor request if you need to change the infrastructure code.

Yeah. And I like the way that you can not just do those commands, but presumably it's a very, very easy step to notify people that that stuff's happened and the commands that you're making. So you're integrating not only the fixes, but also notification of what people are doing to fix things when you're in a swarming or an incident. And yeah, picking up on what you just said, Jobin, about it's got the CLI behind it famously the CLI can do everything that you can on the console, on the web console. Sometimes things lag behind a little bit, but not by much.

So yeah, the fact that it's a Chatbot that uses a CLI on the back end means that it's going to do pretty much everything you can possibly want to do to any AWS service anywhere ever. Yeah. Really, really powerful. And yeah, I'm going to line it dark and really think about all the possibilities of that because that's interesting.

Yeah. This will probably redefine the way startups work because right now we are using Slack mostly for notifications on monitoring. Now we are talking about operating using Slack. So that is definitely I think, going to redefine the whole chat of scenarios.

Because it makes it more synchronous, doesn't it?

Exactly. Yeah.

Because we've got Slack channels pinging off saying, "This has gone down or we're not very often because we're good. Or it's hardware we're after."

We believe you.

Yeah. And things like, "We've deployed this, we've deployed that. So and so has committed stuff to a Git repository." And any actions that we tend to take off the back of those tend to involve command tabbing out of Slack and then going off and finding a terminal window or a web browser and doing something. And I've always been thinking that having things ping off in Slack is all very well and good, but it's not the end of the story and being able to do this stuff synchronously in Slack, so if something happens and you want to react to it use that is where you get the real value.

And yes, we've got bots that can do things like trigger Jenkins bills, et cetera. But we'll be reinventing doing things on the web console or doing things with the command line up until now. And so having this takes a lot of that work away. Yeah. That's awesome. "Looking forward to spending more time in Slack," said no one ever.

Yeah. That's true. With their 1000 channels.

Cool. Are there any other things that excited you about what AWS released?

I think that's probably enough AWS for today. Isn't it? I think something we probably should have signed posted is that other cloud providers are available. And I think it's an essential part of any sensible strategy that not only do we put ourselves in a position where we can start exploiting and taking advantage of new things that AWS provides... AWS, sorry. Adaptavist is an AWS partner. We do a lot of things in AWS. They're our primary cloud provider, but part of the essential strategy is making sure that we're not too enthusiastic about these things and making sure that we're not outsourcing our entire IT strategy to AWS.

So yeah, it's brilliant and these announcements are really, really good, really good stuff coming along. Each one of them we need to be quite careful with, I think and make sure that we are doing the right things for the right reason because some of this stuff there's a temptation of like, "Oh, no new JavaScript framework, new shining, we have to go and use this," that sort of mentality around some of these things, which again, we have to be a bit more careful about.

But yeah, overall all these things where it looks like AWS had gone to the effort of providing things that save us having to think about the technical details of, it's got to be good, right?

Yeah. And I do want to reinforce what you're saying. There are other cloud providers out there and obviously, we have seen that companies are more and more embracing the cloud agnostic architectures and designs and they're looking at multiple clouds at the same time. And we have seen over the years that Azure for example, or GCP is growing at a really, really fast rate and there's a lot of market share out there. So it's not like AWS is slowing down. It's just like all the other cloud providers are catching up and the growth is pretty much similar to AWS if you take a look at it.

And I guess it's safe to say that Adaptavist is also cloud agnostic in many ways, because we don't solely look at AWS, even though we are an AWS partner. There are a lot of customers out there who actually want to host Jira data centers, for example, on Azure because they are a Microsoft shop and they don't want to do it in AWS. And we are like, "We just go with customer wants and we always do what they need." We have done quite a lot of implementation on AWS, but at the same time we have done it on Azure and I'm involved in TCP, but I'm pretty sure there are people who are doing it in GCP as well.

Yeah. And people are choosing different providers for good reasons. And the interesting thing is that it's not so much... I mean, we can fall into a trap of trying to work out which AWS service is equivalent to which Azure service is equivalent to which GCP one under the guise of doing a multi-cloud strategy. But I think the interesting stuff is where they differ. And in particular where you get a lot of Azure take up in organizations that have been traditionally Microsoftian, if that's a word. It is now. And similarly you see organizations that started out along the G Suite route a long time ago go to GCP.

I thought you were going to say Googly, but it's all there.

If Microsoftian is a word, then Googly has got to be one, right?

I'm pretty sure Google does use Googliness in their interview procedure. I've heard that before. They rate someone based on their Googliness.

There we go.

Their Googliness.

So it's real, these things are real. Yeah, they hear first from us.

So we're not inventing these words. I'm sure. I'm sure they've been used before, haven't they? I look forward to more Googliness. What would the Adaptavist equivalent be?

Adapter liveliness.

It feels kind of adaptavist with too many syllables as it is. Isn't it? It's just getting silly now, right?

Or adapter vision.

Adapt vision.

How much adaptive vision do you have?

Well, we usually adapt to the customer, hence the name Adaptavist, right? But, hey, I'm making it up.

So what would you guys think is coming in the future for DevOps in 2022?

Cool. I mean, I'll probably start with cloud, right? I mean always going to be cloud focused, especially a lot of the... I mean, I think with the pandemic, I think it is an increased importance of the cloud because a lot of the time you are not there the data centers anymore. So you're relying on remote operating anything and the cloud is obviously giving you that opportunity. Everything is now moving to the cloud and that trend is going to continue in future. What do you think, Matt?

Yeah. So I think there's a tie in here that we can do with what's being termed the great resignation. Don't know if you've heard of that.

I haven't.

But it's the idea that since the pandemic started, that people are now voting with their feet and doing things like not only moving out of big urban areas to live where they want to live, but also now having the choice of being able to work for companies that are increasingly more distributed. And so it's massively opening up the job market for people. And you're probably thinking, "What the hell has this got to do with DevOps and security?"

So there's an interesting parallel with something that we've been looking at in security terms, which is that given that people are working remotely, the pandemic wasn't as a seismic change for Adaptavist as it was for many organizations, given that we were already remote for the first few years of the company's existence that I don't think there was even an office back in the early 2000s or sorry, the mid 2000s.

But for many it involves things like coming to terms with things like all your employees are not in the office and therefore they're not coming from the same IP address range that they always were, therefore you need to... Or do you lock down everything to be behind a VPN? And how does that work in scenarios where actually you're not self-hosting because maybe you're using GitHub or CircleCI or any number of SAS products, S-A-S products, which are all over the place, you can't lock things down anymore.

And so I think there's a consensus. So we discover this within the database and we've got some predictions coming out for this where we're going to have to double down on security because all these safeguards that we used to have, aren't quite as valid as they always were.

And it's interesting, right? It's not just for moving your applications to the cloud. We are also talking about companies actually moving their entire development into the cloud. So we are starting to see a lot of developers using cloud names for example, as their ID. And they're not relying on entering their eclipse at their work station anymore. In fact, a lot of the organization are now moving their entire workstation to AWS, using AWS workspaces, right? So those are some of the trends that we have started seeing. So you're...

Cloud Nine has been around for a few years and has gained an importance and significance but now other people are getting into this game. I mentioned GitHub Universe earlier, and the GitHub Universe they've announced some improvements on their own cloud-based IDE. I can't remember the name of it, apologies. But if you think about who owns GitHub... Do you remember who owns GitHub?

I think Microsoft now, right?

Microsoft. Yeah. You think, "Is there a really, really good editor or IDE that people might use from Microsoft? Oh, yeah. VS Code, Visual Studio Code."

Visual Studio, yeah.

And everyone has gone really hot on VS Code. It's market share has just gone woosh in the last couple of years. And so you can basically run VS Code in the cloud now. And oh, my God, that means that basically every single keystroke that your developers are now doing is getting sent off to GitHub or to Amazon or in Cloud Nine, et cetera. Oh, my God. That's quite scary. Right?

It's a bit scary, but at the same time, you don't have to worry about travelling with your laptop when you're going on vacation, right? Yeah, yeah. Go to the beach and you now start working on any machine that you can find there. I mean, not that we're going to have a lot of machines there and starting to work on holidays, but you can basically travel, I mean, and access your space from anywhere, that's an advantage in many ways.

Yeah. That's definitely not something I would want. If I'm travelling, I'm like, "Oh, no, sorry. I can't do that. I haven't got the right SSH keys on this machine. Sorry, I'm on holiday, bye. I'm just going to go and sip another rum."

That excuse is not wanted anymore, Matt.

Yeah. You've got all the live sharings, you can be working even when you're pairing with people remotely. I know that IntelliJ's got their own version of that as well. So all of the IDs are enabling people to work remotely even if they're pairing on something.

That's not just one, right? I mean, there are a lot of other predictions coming on the probably for 2022 in terms of everything as scored we have talked about configuration score, and Success Score in the past quite a bit. I think that trend is going to continue again. Everything is going to be on call and I can't imagine anything like in the past where we are doing something. It's interesting, we just spoke about it not doing in-working AWS CLI from Slack, but is that going to be the trend?

I don't see that happening because anything that you want to do on AWS or any intra-sector that you want to create, you actually want to monitor it. Everything should be caught. Everything should be checked into your source control repository, right? So that's going to be interesting because if you start calling AWS CLI commands on Slack, who is keeping track of them, right?

Well, yeah. So this is something that actually, I find quite intriguing and even almost exciting about the industry that we're working in is that we come up with ways of working and things that make our lives easier. And then almost in the next breath, we then go and introduce something that utterly changes that or invalidates the assumptions that we'd made before. And oh, my God, that can be really, really stressful, actually. If you think, "We're doing this and then this new thing comes along, we can't do that anymore if we use this new thing. Well, let's not use the new thing."

And then you end up with people subtly in the back door using this new thing and shadow IT, et cetera. And then you're like, "We're going to have to do something about this." And my first reaction is like, "Oh, right, we need to control this." Don't worry it's only a reaction that lasts very momentarily because I realize it's absolutely impossible and not something we should do. We should be encouraging people who are using new things and solving their problems and working out ways of making them work well. And maybe there is a root here.

I mean, the phrase GitHub just flushed into my mind here. Maybe the first Chatbots that we do with the new AWS functionality end up causing all sorts of configuration drift and people get crossed because suddenly someone's changed something with a Chatbot and now Terraform is going, " [inaudible 00:35:06] this has changed and actually it does not compute." But then we make it part of the system somehow. So you can be committing code, possibly commit changes through this Chatbot those changes-

And it's very sad for it to support this one. Yeah. I can see an army of Chatbots now.

They're going to need the likes of us humans. Our raw flesh is going to be redundant before we know it, right?

Exactly. Speaking of this, right? I mean, it's not always going to be tools and Chatbots on the DevOps world because one of the interesting predictions that we are seeing for 2022 is have a lot more focus on people and culture done on tools and processes, which I thought was very interesting because people immediately think of tools and processes when they talk about DevOps. But I think in this show, we have talked in the past about how people and culture are very, very important for that equation. And in real life we are seeing that shift while working with customers, because we are already seeing that a lot of the customers are now focusing on the people culture aspect of DevOps. Do you see that trend continuing? And is it going to take over tools and processes going forward?

I think it has to, because the tools are getting both simpler to implement and more complicated in what they can do. So yeah. People are like, "Yeah. Tools, yeah. Let's do some DevOps tools. Let's hire some people to install some tools." That's getting easier and easier, especially if you're just buying stuff, tools across the internet. You're just signing up, put a credit card in off you go. And also they're getting more complex and the worst thing you can do with the tool that solves your problems is to not understand what it... Not necessarily how it works, but how it does what it does.

And so I'm foreseeing people seeing these tools for what they are, which are brilliant, absolutely fantastic buying them. But then the way that you then glue your organization around these tools is going to become more important given that the tools are getting more complicated. We're getting more of them or getting single tools, maybe monolith tools that do an awful lot. It's going to be really important that we're using these in the right way and ultimately smack massively of better processes, better culture and everything that that entails.

It is also the shift in mentality, right? I mean, we speak about DevSecOps and all the different tools that are now shifting security to the left. Like GitLab is doing a lot of work on that data, for example. But at the same time, if people are not prepared for that, right? I mean, if developers are not prepared for the early security conversation while they're developing the code, it's going be a failure. So that shifting mentality is very, very important. It's also that culture where the security team works hand and hand with developers, not working in isolation.

So until that culture is developed within the company, anything that you do, like buying a lot of tools or buying a monolith application, which will do everything for you, that's not going to help.

Yeah. No, exactly. And I think it's the sort of thing that you're going to see people get wrong in an organization first before you get it right. Even DevSecOps is a hard one to actually do it according to the letter of why that is different to security and time has gone by. It's so easy. We've made this mistake at Adaptavist I think I can safely say where with all the best one in the world, you end up actually shifting a load of stuff right when you were supposed to be going in the other direction, just because you haven't managed to get the right mentality going across the organization, which maybe hasn't been working in the right way in the past.

And so you're going to get these false thoughts and come back to things and look at things like why were security teams involved and acted in not the wrong way, but not in the way that we wanted to do in a DevSecOps scenario, why did that actually happen? And I'm picking that stuff. It's not easy in the organization.

And especially when you're within it, right? Especially when you are in the organization in the midst of it you probably don't realize what's going wrong. And that's probably why you will need some external help and taking a step back and looking at it as a whole and seeing where the issues are. Right? Is it with people? Is it with the process? Is it with the tools themselves? Which is probably also one of the reasons why we're hearing this Value Stream Management quite a bit these days.

Adaptavist is offering workshops on that matter. You have worked on that quite a bit. So you said going to be another trend of Value Stream Mapping and Value Stream Management going forward. I see a lot of organizations starting to pick that up quite a bit. We have written blogs about it in the recent past. So do you see that as a trend for 2022?

I don't know. So the reason I say that is VSM, Value Stream Management, it's been around for a long time. It reminds you a little bit of, there's an old saying in the community of people who want to use Linux on the desktop, which I have a bash app once a year or so. And then generally end up finding things like Zoom and Slack and my web browser don't really work well enough together and then I go back to my Mac. And they say, "Finally, this is the year of the Linux desktop." It's an ongoing joke they say every year.

Is it the same with Value Stream mapping? I'm not sure. I think actually we might be getting somewhere now with Value Stream Mapping. Sorry, I'm trivializing the good work that people do in VSM, but it doesn't feel like it's quite mainstream. And maybe now is actually the time. Maybe this feeds into what I was talking about a few minutes ago where tools and processes that we use are getting more and more complicated that we are losing sight of what they actually do. And because of that, we need to take a big step back and have a look at what they're giving us, which is undoubtedly really, really good stuff.

But in the context of the wider organization and delivering stuff, delivering value, delivering services, getting code out in front of consumers might not be as obvious as it once was. So yeah.

Value Stream Management, it's a term that has been out there for quite some time. But at the same time, the shift that I'm seeing is the customers are starting to recognize the word, right? And they're starting to put a budget into doing Value Stream Mapping, which was supposed to sign because from the past the little budget that you had, you probably allocate it for buying the tool and probably hiring a consultant company like Adaptavist and coming and helping them.

But now they're taking another step back and looking at VSM as a whole and doing that exercise and finding where your way is, where your value is and attacking those specific areas, which is really great. So I see that shift happening. So probably, I think the biggest thing is customers now realizing that Value Stream Management is important and probably starting to look at it. It has been there always, but now they're starting to put more effort into doing that.

Yeah. Couldn't agree more. Yeah. One interesting year we have ahead, right?

I guess so.

If it's about this one.

Anything more about any other ops, because we had been hearing about in GitOps, SatOps, Data ops recently about AOPs, right? A lot of ops stemming out of this, coming out, not surprisingly.

Good, good. Yeah. The great thing is they all end in Ops. So yeah, operational getting some more time in the spotlight I'm all more for that. If you take a look at DevOps where we first came in, it was all about acknowledging the people who have the software thrown over the water then to go and operate and fix the middle of the night. And yes, we're putting lots of words, front of Ops. Brilliant. Great. Bring it all on.

Any closing words about Kubernetes? We know how much you like Kubernetes.

I love Kubernetes. Although interestingly and I think this... I can turn this into a prediction. So I was on a call... No, you were on the call as well, Jobin. Where I'm the Kubernetes guy and I was saying, "Don't use Kubernetes. Don't use Kubernetes for this."

I remember that one. Yeah.

You remember, yeah. So is an installation for a customer we're talking about.

Was it a data center because the client didn't have any expertise on Kubernetes on their side. So the ongoing maintenance was going to be difficult, right? That's the reason you said, "Probably we need to take a step back and think about recommending this for the customer."

Yeah. Yeah. So Kubernetes is massive. There's not a single day where I don't mention the K-word but it's still, I wouldn't say it was mainstream in terms of... Well, definitely in some organizations in the organizations that we see that we do consultancy for and we provide services for, we see a massive breadth of skills and maturity, et cetera. And we can't do things like just install Kubernetes for our customer when they've never even seen Docker containers, that isn't going to happen.

But much for me is like, "Oh, this is actually really a missed opportunity because we've got really good Kubernetes manifests and charts for the core products that we deploy partly thanks to the efforts of the community and partly due to some hard work by people in Adaptavist." And yeah, it's a missed opportunity and it's waiting for the world to catch up. And so Kubernetes, more of that 2022. Maybe at the end of 2022 we can be having conversations around the kind of customers that we were talking about last week where this is actually an option and this wonderful dream of Kubernetes being the operating system for containers is as universal a thing as virtual machines are, maybe.

Yeah. That's very glad to be. Yeah. Every customer having a Mac working for them who loves Kubernetes and can take care of it.

Oh, God, I can't think of anything worse. Can you?

So 2022, we get cloning mats.

Cloning mats like that?

You have to stop this world. I want to get off.

Thanks for joining us for this holiday edition of DevOps Decrypted. Please @ us on social media @Adaptavist Live. And for me, thank you for listening.

Thanks everyone.

And from Jobin?

Happy holidays.

Happy holidays.