DevOps Strategies: The Secret to Smarter, Faster Business Outcomes – DevOps Dialogues

Mitch Ashley: Hi, everybody. 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, Johnny Halife, who is CTO and also founder with Southworks. Welcome. Good to be talking with you. We’ve talked a few times, Johnny, it’s nice to talk again.

Johnny Halife: Yeah, it’s great to see you again, Mitch.

Mitch Ashley: You as well. So tell us a little bit about, just introduce yourself, tell us a little bit about Southworks and what kind of things that you all do.

Johnny Halife: Yeah, so my name is Johnny and I’m CTO with Southworks. We’ve been in business for 20 years. We are a software development firm. We work with companies all sizes from startups to enterprise, working on these 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.

Mitch Ashley: Very good, very good. 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. Matter of fact, they’re kind of moving into more maturity levels of it. Not everyone. But it’s been around for a while, almost a decade. I’m curious your experiences as 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 do you see those differences?

Johnny Halife: That’s a great question and oftentimes when we meet companies that are not so into it, we see, I would say resistance or a pushback because you’re working for the software, not in the software. And after 10 years working on this, I would say that it’s that feeling of going slow to actually go fast. We see that the business value for these people has to do with lesser or more control, more predictability when it comes to deploying system, very complex systems. And you need to get into it because I agree with our customers when they say 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 a natural cadence, if you will, every time you’re deploying.

And we see that also as the agility of the business. We see a lot of our customers, when we meet them, that they are like, 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 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 a very interesting upside for the business because it’s your ability to cater fast to your customer needs without having to say, “Sure, that’s planned for release XYZ, that it’s coming six months down the line when we are done with our current release train.” But it takes a lot of education and training. It takes a lot of like, you need to be doing this. And oftentimes it takes these, trust me, it will get better; trust me, it will pay down the line. But once you get into it, I think that I would say the results speak for themselves. Right? People are like, “Yeah, 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.”

Mitch Ashley: Mm-hmm. And there can 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 can be a driver, but most organizations are not ready to do 10 deploys or 50 deploys a day. Maybe a Netflix or others would be. There can also be just being able to 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 a new feature, we’re going to prioritize this over other things. We can pivot without course correcting the whole project and incurring a big cost to do that. So I’m curious, what are the benefits that you see people wanting to get by implementing DevOps?

Johnny Halife: As you just said, and I think that’s right on point, I don’t think the driver being the number of releases, that’s just like a consequence. I think that the major driver has to do with 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 we see people like we are going to deploy everything quiet and all that. That’s number one. And the other is that without a practice, like an active DevOps practice, all the, I would say, agile or lean startup speech goes to waste because as you just said, you are in for the feedback. You want to iterate quickly, you want to deliver value to our customers iteratively 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, it kind of watered down. Why are we working this way? Why are we doing 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 six months.

So I think it’s a matter of alignment with the business priorities in terms of we want to work this way and be through and through with it, trying to go to market as soon as possible. I think that removing the complexity and the stress of what it takes to deploy a complex system will be number two and all the rest about doing these contention nets to make sure that you’re not introducing new bags or doing 10 deploys a day. And those sorts of things are more like an accident or a consequence of doing that rather than the primary driver. It eventually happens and it starts 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 chasing the agile way or the lean startup way and building this iteratively and incrementally and all that. But if that doesn’t go to market as soon as it should, then it doesn’t make sense.

Mitch Ashley: Talk a little bit about DevOps is a contact sport, 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, but you end up in part helping with the DevOps processes, streamlining workflows, maybe learning some techniques about how you do microservices as part of a flywheel faster to be able to deliver some of those software into test and into production or iterate on improving quality, things like that. So you end up kind of a little bit of consulting as a DevOps consultant while you’re there as a software leader. Is that true?

Johnny Halife: Yeah, and one of the things that I like the most about getting into this world and that I enjoy the most is working with people that have their own ways. Right? When you have a complex system, DevOps is not a recipe. There is no checklist of the things that you should do. There are a lot of practices, there are a lot of things that we would recommend doing, but we found these amazing techniques 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 deal with dependencies and reuse the deployment surface to make sure that things are changing the least they need to change and all that, that it’s amazing. 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 intra-network builders bringing the GitHub DevOps runners within your private network to reduce latency and stuff like that.

But then there are the, I would say the tips and tricks or the practices that are acquired and they
are part of the business that these versioning on 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 making sure that you’re hedging for the risk of releasing a new version or how they do API versioning and those sorts of things that are amazing. And I think that there is a baseline for everything. Like, hey, sure you need a build server and you need to pick up Git flow in any flavor and those sorts of things. But then there is the 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 proven practices for all these, it’s that thing of like, “Hey, I’m here to help you, but I enjoy the ride learning about you and how are you dealing with these complex problems.”

Mitch Ashley: In today’s world of software projects too, the success of those projects are even more important to the business because so many, it isn’t just back office, it’s business strategies, really outcomes that they’re looking to achieve, get into a market, be more competitive, deliver new capabilities. Given your experience of doing software for such a large period of time, what are some of the things that you and kind of the Southworks team do to help increase the chances of success?

Johnny Halife: So I would say two or three things that have been working for us. One is the crawl, walk, run sort of thing. Like start small and then increase the complexity as you need to increase that complexity, not just for the sake of future-proofing solutions because that ends up being a lot of work to introduce the smallest change and you actually don’t need it, right? So that would be one. The other one is that pay the tax of having a sounding workflow for delivering and controlling your software life cycle early on because the hack and slash sort of days are gone. You cannot live with that. And the later you introduce all these practices, the harder this it becomes because you have a lot of moving pieces, dependencies become buried into 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 would we care about it right now?” But at some point it’s live or die sort of decision because you need to keep up with the business.

So we would rather pay that tax of 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 don’t worry about what you don’t need to worry but be prepared for the future, finding that middle ground or that sweet spot is what we’ve seen as success because crawl, walk, run, it’s great. It always work. It comes from know extreme programming, TDD and all those practices before we even talk about DevOps and all that. But as I said, I agree with our customers when they say, “Hey, you’re working for the software and not in the software and you need to work for it 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 crafting features and talking to customers and have that assurance, that that thing that is bothering you or been 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 over-engineering it never pays off.

Mitch Ashley: Mm-hmm. How about some common pitfalls? What do you see causes DevOps projects or implementations to stumble or maybe even fail?

Johnny Halife: It’s a great question. I wouldn’t call them failures because I think everything is learning as long as you can capitalize on it and you can course-correct. It will be 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.” But I see this, 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 and 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 a regular basis, they become stale and you lose confidence and you end up working to fix them when you never need them and they become showstoppers. And that I would say distrust bubbles up to management. “Hey, you told me you would create this because everything will flow like a pipeline and everything will be fine and we won’t have to struggle with getting this into production,” and those sorts of things.

So I think that failure is when that working for the software becomes excessive and it’s no longer delivering business value. And 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 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 iterative and incremental. It’s something that you will 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.

Mitch Ashley: Well, let’s look forward a little bit. We’re at the beginning of 2025, when you and I are talking here. There’s a lot of anticipation about AI’s use in software development, also using AI in our systems and our applications. 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?

Johnny Halife: I think that leveraging AI to do that continuous optimization by looking at logs, by looking at things that might fail and course correct quicker, it’s an opportunity. I think that, 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 comprehensive view of what it is. And it will become a crucial part of elevating 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 continuous delivery, continuous integration and stuff like that. I think this 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 dangling thing that sits in between developers and IT pros, old school that just care about networks and hardware. It will become its own practice. I think it will eventually evolve to when you and I talk I think two months ago and I was saying about this platform engineering concept where we as developers would start taking more and more responsibility over it. It won’t be like, “Sure, I believe somebody else will take care of delivering it.” I think it will be a more vertical approach where developers 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 something that developers and the traditional IT people will fight over 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 converge. I like to call it platform engineering and thinking about this holistic view that has to go down to the networking level up from the app level. 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 KubeCon, I see more developers into it. I see more people that actually write software thinking about 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 the road, who’s going to maintain it, how we are going to version it and all those things that were sitting in between over the last 10 years, because traditionally you have the IT people, the developers, and we would just pass something along. I think we will converge into a more mature practice that will develop its own standards and its own patterns and practices. 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. Same thing as we don’t say like, “Hey, I’m a UI engineer or a backend person.” 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.

Mitch Ashley: And I agree with you, especially about the platform engineering and DevOps converging. Whether it’s one group or a combination of folks doing it, there’s a lot of synergies. And of course DevOps has helped kind of elevate a lot of things, helped platform engineering, I think come to of age, but also elevating testing, elevating operations, elevating security, software quality. And I think also as 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?

Johnny Halife: Exactly. And I think one of the things that DevOps 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 you just said, right, it’s a bigger squad in which you have 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 it will run, or the networking, or the ports, or the things that as developers we thought we didn’t have to care, it’s gone. We have that. 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, there is no Swiss-knife developer, I think, but you are aware. And that’s the most important thing because that waterfall that we’ve been fighting for the last 15 years in terms of being agile and using Scrum and XP and TDD and all those sorts 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.

Mitch Ashley: Thinking about things more systemically, more holistically.

Johnny Halife: Yeah.

Mitch Ashley: Well, Johnny, it’s been fantastic talking with you again. I always enjoy our conversations, hope we’ll have you back again on DevOps Dialogues.
If folks want to learn more about Southworks and how to engage with you and your team, visit the website. Is that correct?

Johnny Halife: Yeah.

Mitch Ashley: Southworks.com?

Johnny Halife: Southworks.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. They tell us 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, and we’ll be waiting at Southworks.com.

Mitch Ashley: Fantastic. Johnny Halife, CTO with Southworks, thank you to you and the Southworks team. And also thanks to everybody for watching and listening today on DevOps Dialogues. We’ll see you on our next episode.