The Secret to Smarter, Faster Business Outcomes – DevOps Dialogues EP16

Hi everybody, and you've joined us here on DevOps Dialogues, where we talk to tech leaders, practitioners, folks that are into the world of DevOps, software development, all aspects of that. So my name is Mitch Ashley. I'm VP and practice lead for the DevOps and app development practice at Futurum Group.

And I am joined by a special guest today, uh, Johnny Hali Fe, who is CTO, and also founder with South Works. Welcome. Good to be talking with you.

We've talked a few times, Johnny, it's nice to talk again. Hi. It's great to see you again, Mitch.

You as well. Uh, so tell us a little bit about, just introduce yourself, tell us a little bit about South Works and what kind of things that you all do. Yeah, so my name is Johnny, and I'm CDO with South Works.

We've been in business for 20 years. We are a software development firm. Uh, we work with companies all sizes from startups to enterprise, working on this, you know, fantastic world of DevOps and multi-cloud and everything that has to do with this new wave of infrastructure.

And I'm excited to be here talking to you today. Very good, very good. You know, having worked in DevOps a while myself too, and we do a lot of research around DevOps.

We see a lot of data that shows that organizations have really done a lot of adoption. Mac fact, they're kind of moving into more maturity levels of it. Not everyone, but, um, you know, it's been, it's been around for a while, you know, almost a decade.

I, I'm curious your experiences, you work with customers, I'm sure you work with folks who are maybe getting started, kind of have somewhat of a practice going, maybe they've been doing it for a long, long time. What differences do you see DevOps making in how software projects are going and where, where do you see those differences? That's, you know, it's a great question and, and oftentimes when, when we meet companies that are not so into it, uh, we see a, I would say, resistant or a pushback because you are working for the software, not in the software.

And, you know, uh, after 10 years working on this, I would say that, uh, it's that feeling of going slow to actually go fast. Uh, we see that the business value for these people has to do with like lesser or more control, more predictability when it comes to deploying system, very complex systems. And, you know, you need to get into it because I agree with our customers when they say like, you're working for the software, not in the software, but at the end of the day, we see a lot of value on that predictability, on that ability to know that things will follow like a natural cadence, if you will, every time you're deploying.

And, and we see that also as, you know, the agility on the business. We see a lot of our customers when we meet them that they are like, you know, we prepare our release trains and this takes three months and we have our customers bugging us for X or Y feature, and we have no way of deploying that within the timeframe. So, you know, it's a maturity level for the company.

It's a peace of mind for the SRE, DevOps infra it, I've seen all the names. And it's also, um, a very like, interesting upside for the business because it's your ability to cater fast to your customer needs without having to say like, sure, that's planned for release X, Y, Z, that it's coming six months down the line when we are done, when our current release trained. So mm-hmm.

Um, but it takes a lot of education and training, right? Like, it, it takes a lot of, like, you need to be doing this. And, uh, oftentimes it takes these like, trust me, it will get better.

Uh, trust me, it will pay down the line. Uh, but once you get into it, I think, uh, the, the, I would say the results speak for themselves, right? Like people are like, yeah, how, like, how are we just getting started with this?

This has been around for 10 years. I even read the Phoenix project, but I never thought it applied to us. Mm-hmm.

You know, and there could be a lot of drivers for why people might adopt DevOps. A lot of attention is paid to how many releases or deploys that you do per day, per week, whatever. And that, that can be a driver, but most organizations are not ready to do, you know, 10 deploys or 50 deploys a day, right?

Like maybe a Netflix or, uh, others would be. There can also be just being able to, uh, make improvements faster. So fix bugs faster that you're in the development cycle, find out, get feedback quicker earlier in the process so you can make course correction changes.

Maybe it's also a direction in where the project needs to go. Here's the new feature. We're gonna, you know, prioritize this over other things.

We can pivot without, you know, course correcting the whole project and incurring a big cost to do that. So I'm curious, what, what are the benefits that you see people wanting to get by implementing DevOps As, as you just said, and, and I think that's like, uh, right on point. I don't think the driver being like the number of releases, that's just like a consequence.

I think that the major driver has to do with like, the complexity that it takes to deploy a modern system with microservices and bunch of the cloud dependencies and stuff like that. So that predictability and, you know, we see people like, you know, we are going to deploy everything quiet and all that. Uh, that's like number one.

And the other is that without a practice, like an active dev of practice, all the, I would say agile or, you know, lean startup, uh, speech goes to waste because everybody, as is just said, right, like you are, you are in for the feedback. You want to iterate quickly, you want to deliver value to our customers, uh, integratively and incrementally. But if everything comes down to this big one milestone process that you will do every three months, and it has a lot of risk and it's super complex, and your teams try to stay away from it as much as they can because of all the stress that it takes, um, it kinds of water down.

Like, why are we working this way? Why are we doing like agile weekly sprints? Why are we doing an MVP and iterating over it?

If by the time it hits the market, it will have been like six months. So I think it's, it's a matter of alignment with the business priorities in terms of like, we wanna work this way and be through and through with it, like trying to go to market as soon as possible. Um, I think that removing the complexity and the stress of what it takes to, you know, deploy a complex system will be number two and all the rest about like, you know, um, doing these contention nets to make sure that you're not introducing new bags or doing 10 deploys a day.

And those sort of things are more like an accident or a consequence of doing that rather than the primary driver. It eventually happens and it start happening without you noticing it, but I think it's more on the value side. Like, hey, we have this bag for which we are getting 10, 15 tickets a day.

We know it's a quick and easy fix. It will take us half an hour. It cannot take us three months to get into production.

I think that's kind of the primary driver and aligning the rest of the organization because everybody's, you know, chasing the agile way or the lean startup way and building this iteratively and incrementally and all that. But if that's, if, if that doesn't go to market as soon as it should, then it doesn't make sense. Talk a little bit about, you know, DevOps is a contact support Yeah.

Participation, doing it with others, but also learning from others that have done it before. I imagine you enter a lot of projects to build software for customers, deploy things in the cloud or whatever it might be, uh, but you end up in part helping with the DevOps processes, you know, streamlining workflows, maybe learning some techniques about how you do microservices as part of, you know, a flywheel faster, right? To be able to deliver some of those, uh, software into test and into production, um, or iterate on improving quality, things like that.

So you end up kind of a little bit of consulting as a, as a DevOps consultant while you're there as a software leader. Is that true? Yeah.

And you know, uh, one of the things that I like the most about getting into this world and, and that I enjoy the most is working with people that have their own ways, right? Like, uh, when you have a complex system, uh, it's not a ops is not a recipe. There is no like checklist of the things that you should do.

There are a lot of web practices, there are a lot of things that we would recommend doing, but we found these amazing, you know, techniques, uh, that our customers implement down the line, like versioning and how they deal with multiple API versions and how they enable rollback and how they, you know, uh, deal with dependencies and reduce the deployment surface to make sure that, uh, things are changing the least they need to change and all that, that it's amazing. And, and it keeps amazing me because it's like, sure, you can bring Argo and streamline the way you are working with containers, or you can do, you know, intra network builders bringing the GitHub DevOps runners within your private network to reduce latency and stuff like that. But then there are the, you know, I would say the, the tips and tricks or the practices that are acquired and, and, and they are part of the business that like these, like versioning or how you change traffic or how you roll out and do AV testing as you go to reduce the complexity of the deployment while also, you know, making sure that you're hedging for the risk of releasing a new version or how they do API versioning and those sort of things that are amazing.

And I, I think that there is a baseline for everything. Like, hey, sure, you need like a build server and you need to do, you know, uh, pick up, uh, git flow in any flavor and those sort of things. But then there is a reality of the business.

So I remember working with things that are real time, so how would you change traffic without affecting those that are connected to the system real time? And those are the problems that are unique to each and every system and learning about those while coming with our, you know, uh, proven practices for all these, it's, you know, that thing of like, Hey, I'm here to help you, but I'll enjoy the ride learning about you. And how are you dealing with these complex problems?

You know, You know, in today's world of software projects too, it's, uh, the success of those projects are even more important to the business. 'cause so many, it isn't just back office, it's business strategies, uh, really outcomes that they're looking to achieve, get into a market, be more competitive, deliver new capabilities. Uh, you know, given your experience of doing software for such a, you know, large time, large period of time, what are some of the things that you and kinda the South Works team do to help increase the, the chances of success?

Two or three things that, that has been, uh, that have been working for us. One is the crawl, walk, run sort of thing. Like, uh, you know, start small and then increase the complex, the complexity as you need to increase that complexity, not to, for the sake of future proofing solutions, because that ends up being like, you know, a lot of work to introduce the smallest change and you actually don't need it, right?

So that will be one. The other one is that pay the tax of having a sounding workflow for delivering and controlling your software lifecycle early on, because the hack and slash sort of days are gone. Like, you cannot live with that.

And the later you introduce all these practices, the hardest is it becomes, because you have a lot of moving pieces, dependencies become buried into, you know, the complexity of the actual system, and nobody wants to pay the price. And it's like, yeah, we've been doing this for a long, long time. Why, why would we, you know, care about it right now?

But at some point it's, you know, um, live or die sort of decision because you need to keep up with the business. So we would rather pay that tax of, you know, having the pipelines and understanding how we would go from development, staging, production, how we would test our changes, how we would know that things are working and so on and so forth early on, even if it's a small prototype, we want to set the pipelines and see them working because if you introduce that later on, it becomes way harder. So I think that in between those two things, that sounds quite like an oxymoron because I'm saying like, don't worry about what, you don't need to worry, but be prepared for the future.

Finding that, you know, middle ground or that sweet spot is what we've seen as success because crawl, crawl, walk, run, it's great, it always work. It comes from, you know, extreme programming, TDD and all those practices before we even talk about DevOps and all that. But I, as I said, I agree with our customers when they said like, Hey, you're working for the software, not in the software, uh, and you need to work for it like during a period of time.

And that increases the level of confidence for your team, for your business, and even from the non-technical people, those that are, you know, crafting features and talking to customers and have that assurance that that thing that is, you know, bothering you or being bothering you for, I don't know, three, two weeks, we are going to fix it tomorrow. And you can say that and you have the confidence, you know, that you have the process and you know how to get that into production. So I think that finding that sweet spot is kind of key to ensure success.

Sometimes you need to pay the price, but you know, the over engineering it, it never pays off. Mm-hmm. How about, how about some common pitfalls?

What do you see, uh, causes project DevOps projects or implementations to stumble or maybe even fail? It's a, it's a great question. Uh, I, I wouldn't call them failure because I think everything is, you know, um, learning as long as you can capitalize on it and you can, you know, course correct, it will be, uh, harder or it will be more expensive, but everything is fixable.

There is nothing I would say like, Hey, let's drop and start over. Um, but I see these, you know, eventually we will have a multi region multi thing, so we need to figure out how we will align this. And every system is a living up breathing organism.

So as with your body and everybody telling you to go do exercise, this is the same thing. When you build pieces on your infrastructure that you don't exercise on regular basis, they become like sta and you lo like you lose confidence and it, you know, you ended up working to fix them when you never need them and they become shown showstoppers. And that, I would say these trust, but up to a management, Hey, you told me you would, you know, create this because everything will flow like a pipeline and everything will be fine.

And we would, we won't have to struggle with getting this into production and those sort of things. So I think that, um, failure is when that working for the software becomes excessive and it's no longer delivering business value. I mean, we need to be conscious all the time.

And it's something that I talk with our teams and with our customers, that it's a price that you need to pay to have a, you know, healthy, well tested infrastructure process, a DevOps process, if you will. But it needs to be active and you need to be exercising it constantly. It's also integrative and incremental.

It's something that you will, you know, make more complex as you move forward, but everything that you put in you will need to maintain. So when you end up maintaining things that you don't use, and these become blockers for delivering actual business value, that's where everything crumbles. Uh, well, let's look forward a little bit.

We're at the beginning of 2025 when you and are talking here. And, uh, there's a lot of anticipation about AI's use in software development also, you know, using AI in our systems and our applications. Well, that's just one area.

I'm curious about your thoughts on where we're headed with DevOps. What's next? What do you see as the next evolution or challenge of it?

I think that, um, leveraging AI to do a, that continuous optimization by looking at logs, by looking at things that, you know, might fail and, and, and course correct quicker, it's an opportunity. Uh, I think that, um, as you just said at the beginning, we are almost 10 years in, so as it matures, I think we will start having a more, uh, comprehensive view of what it is and, and it will become a crucial part of delivering business value. I think we will no longer have to explain why we are doing this, why you need to be doing this.

There has been a lot of literature over the last 10 years explaining, you know, continuous delivery, continuous integration and stuff like that. Uh, I think, um, these art or craft will become a real practice within companies where you will have people looking at it. As we look into security, as we look into developer productivity, as we look into patterns and practices for building complex systems, DevOps will be its own entity.

It will no longer be this, you know, dangling thing that sits in between developers and IT pro old school that just care about net networks and hardware. It will become its own practice. I think it will eventually evolve to, uh, what you and I talk like, uh, I think two months ago, and I, and I was saying about this platform engineering concept where we as developers would start taking more and more responsibility o over it.

It won't be this like, sure, I believe somebody else will take care of delivering it. I think it will be a more vertical approach where developers will need, will, must think about the full life cycle of whatever is that they are building. So it will become integrated, it will become its own entity and it will no longer be like, uh, something that developers and the traditional IT people will fight over, like who owns it, right?

And we are the one who hold the keys to production or we are the ones writing the software. I don't care about that. So I think it will come merge.

Uh, i, I like to call it like platform engineering and thinking about this holistic view that has to go down to the networking level from the app level. Uh, it's the evolution of full stack and I think that's where we are heading. Every time that I go to events like the Q con, I see more developers into it.

I see more people that actually write software thinking about like how to make their software resilient, how to take that software into production, how to make sure that it doesn't become a headache down, down the road, who's going to maintain it, how we are going to version it, and all those things that were like, you know, sitting in between over the last 10 years. Because traditionally you have like the IT people, the developers, and we would just, you know, pass something along. I think we will converge into a more, you know, mature practice that will develop its own standards and its own, you know, patterns and practices and, and it's here to stay.

It won't change, it won't go back to what we knew as like I'm a full stack developer. Uh, same thing as we don't say like, Hey, I'm a UI engineer or a backend person. That that has changed.

We talk about full stack. I think that we will start talking about platform engineering from an end-to-end perspective more and more and more as we go into the future. That might not be that far away.

Yeah, I, and I, and I agree, I agree with you especially about the platform engineering and DevOps kind of converging, whether it's one group or, or a combination of folks doing it. There's a lot of synergies. And of course DevOps has helped kinda elevate a lot of things.

Helped, you know, platform engineering, I think, you know, a a come to of age, but also elevating testing, elevating operations, elevating security, software quality. And I think also is AI is introduced more and more into software as well as the pipeline that'll help us get there. It's a lot easier to improve something you do consistently as opposed to different every time.

Correct. Exactly. And I think one of the things that, that they will have brought into the bigger picture is increasing the level of consciousness for those, writing the software about how it will run, how it will go into production, even as, as if you said, right, like it's a bigger squad in which you have like dedicated people working on that.

But you need to be aware, you need to be aware those things of like, hey, how we would deploy this or how we would run or they're not working, or the ports or the things that as developers, we thought we didn't have to care. It's gone. Like we have that we, we are conscious about it right now, and that is an important piece.

It will converge. And as you said, it might not be the same person like the, the, there is no Swiss knife developer I think, but you are aware, and that's like the most important thing because, uh, that waterfall that we've been fighting for the last 15 years in terms of being agile and using Scrum and XP and TD and all those sort of things need to transpire into infrastructure and to production and making sure that we are a sounding team. So I think that's one of the benefits of DevOps that it has brought into the picture, increasing that level of consciousness about everything that's going on with a piece of software that you're writing.

And I think that will become the gold standard. There is no way back. You think about things more systemically, more holistically.

Yeah. Well, Johnny, it's been, uh, fantastic talking with you again. I always enjoy our conversations.

Hope we'll have you back again on DevOps dialogue. Uh, folks wanna learn more about South Works and how to engage with you and your team visit the website, is that correct? com.

You can send us an email, an inquiry. We are always happy to chat with customers and as I said right, we learn a lot that there is like, we don't hold the truth. We are just there to accelerate people goals and make sure that they are confident about what they're doing and they can scale and deliver value to their customers.

That's what we do. com. Fantastic.

Johnny Heli Fe, CTO with South Works. Thank you to you and the South Works team. And also thanks to everybody for watching and listening today on DevOps dialogues.

We'll see you on our next episode.