Episode Transcript
[00:00:00] Speaker A: You're listening to the Arbery Digital Experiences Podcast where strategy meets technology.
Got a topic, suggestion or want to see how Arbri can boost your digital presence? Let's talk. Visit arberrydigital.com or find us on LinkedIn. Now onto today's episode.
[00:00:18] Speaker B: Hey, welcome to the Arbery Digital Experiences Podcast. My name is Chase Hollander and I'm an AM developer at Arbry Digital.
Today I'm joined with Dwayne Hale. He is our CTO and veteran in the AAM space. He has been involved with many projects over the years and we're going to talk about how you can save money by consolidating onto tools you already know.
Now many teams are struggling with their tools and before you know it you're paying for five different tools and they're doing 80% of the same thing. Before you know it, it's, it's expensive, it's confusing and it slows everyone down.
Now Duane, do you just want to start us off with some advice on common tools people don't realize they aren't using properly?
Tools that could actually cover multiple areas if leveraged.
[00:01:09] Speaker C: Well, yeah, so one of the tools that I commonly come across that's either under leveraged or is leveraged to a certain degree, but it's more of a cloud classical or traditional leveraging of it is your version control system.
So nowadays a lot of off the shelf version control systems. Now I'm not talking about your old school SVN that's hosted locally to your organization.
I'm talking about off the shelf tools such as like GitLab, GitHub, BitBucket, they all pretty much come with some sort of built in CI CD functionality, whether that be GitHub Actions or BitBucket pipelines or even the GitLab pipeline adjacent CICD work that they've been doing, I often see that not leveraged to the fullest extent. And what I mean by that is oftentimes organizations will have a dedicated CI CD tool such as Jenkins or some other build and continuous deployment tool and then they'll just utilize their version control system for just version control.
Where that kind of gets to be overlapping with the tooling that you already have is that you know, the GitHub actions, the BitBucket pipelines, those are specifically developed for the versioning system that you're using. Where Jenkins is, you know, Jenkins or others, CircleCI, Travis, CI are more general purpose tools and oftentimes organizations will have both of them. And I don't know that they just, you know, never went Back and revisited the original offering from, you know, BitBucket or GitHub or GitLab and just didn't know that it could also cover, you know, 80 to 85% of what like a Jenkins or a Travis CI would accomplish. And it's already baked into the tool that you're already paying for out of the box.
So that's one of the common issues, or I guess you would say common tool that a lot of organizations either don't utilize properly or they spin it off some of that functionality into a separate tool.
And so that's one common use case that I see where, you know, organizations leveraging essentially two. Two tools and one of them can accomplish most of what the other one provides.
[00:03:32] Speaker B: Yeah, it's just following up on that. How do you know when you are using. Using too many tools, when you're overlapping way too often?
[00:03:42] Speaker C: So one of the kind of, I guess not really a gotcha, but exercise that I like to do is to bring somebody in that maybe might be outside of your department or, you know, their developer, and you tell them, hey, I need you to go and modify this build pipeline, for example, if that developer or that sysadmin or if they're from a, you know, separate DevOps team, and they come in and they say, oh, hey, which, where is the pipeline? Where should I go to modify that? That's a pretty good indication that, that you have multiple tools that accomplish the same thing. And that outsider, even though they're, you know, inside your organization, in the back of their mind, they're wondering, hey, which one of these multiple tools that we're using do I have to go and, you know, complete the task in. So. So that's one really good example. You just bring in somebody that's not super familiar with what your team does and ask them to, hey, go do something simple, modify this pipeline. And then they start having questions. If it's not upfront obvious to that individual, then you might actually have too many tools that have overlapping functionalities and it's not clear to somebody who's outside of that particular team that's entrenched in those tools that they need to go to either, you know, like I said before, Jenkins, or they need to go to your BitBucket repository and actually make that monetization.
[00:05:11] Speaker B: Yeah, you touched up on this a little bit. But if you're like a manager hearing this, what's their next step or what's something that they should watch for?
[00:05:21] Speaker C: I think the next step in that, honestly, this is kind of a watch for before you go buying these tools or taking the initiative to set these tools up, you really need to audit both the toolings and figure out what it is that you actually need from it. And can that be provided by something that you already have ownership of or that you're already using within your organization?
A lot of times we find that using something as simple as GitHub Actions or BitBucket pipelines will cover again, 80 to 85% of the use case.
Especially now that these products are becoming more mature, they have more integrations where you can do code vulnerability analysis, you can do code security analysis all within your version and control ecosystem. And then you don't have to have a separate third party instance that sits out there in your AWS account or your Azure account and to get that functional work done on your project.
[00:06:22] Speaker B: Okay, gotcha.
Yeah, just going off on that a little bit different direction. But where are the hidden costs of using too many tools in DevOps and engineering teams?
[00:06:36] Speaker C: That's a good question, and it's one that I think comes up in engineering teams and DevOps teams quite often is that you have your cost up front. And a lot of people say, well, Jenkins is free, I'm just paying for the underlying server or the ec2 instance or the physical server that it runs on. But there are a lot of hidden costs to that equation as well.
One of the primary ones being the time of your team. Right. If your team is always. Well, I wouldn't say always, but if you're on LTS Jenkins, for example, there's usually quarterly security updates for the application and you're going to have to pull away an engineer's time to actually apply those security updates, verify that they didn't break anything in your custom pipelines, and there is a decent amount of overhead to running those tools on your own versus letting GitHub or Atlassian deal with the finer grain details. And you focus on actually delivering your code and doing your quality checks, doing your security checks, and it allows you to focus more on what you're doing, not how you're doing it.
[00:07:48] Speaker B: That's a great point. And just to follow up from there, like behind just licensing costs and all things that you've mentioned, are there productivity or training costs that people might underestimate?
[00:08:03] Speaker C: Yeah. So if you have an organization and let's say you bring in one of these third party CICD tools and yet nobody on your team has really ever had exposure to it or exposure to some of the back end languages that these tools would use, I've Gotten mine groovy here.
You would have to train up your DevOps engineers to be able to tackle and administer the CICD tool in question.
Now, when on the flip side of that, if you're using something that's already baked into your versioning, such as GitHub Actions or BitBucket pipelines, those are common enough and they're not super customizable to the point that almost anybody, you know, even a developer could pick up and make changes to their pipeline. And it brings the ability for the dev team to, you know, more or less dictate how their code gets into the environment. It brings that closer to them. So kind of circling back to the hidden cost, there's no more of, hey, we got to put in a ticket with the dev team, they got to modify our pipeline. That's going to take a day or two and you're bringing the work closer to the developer. And so that enhances the velocity of all the teams involved because you're not pulling away your DevOps person to go and modify a pipeline. The developer can do it right then and there and they can be off to the races building.
Let's say they're moving from Java 11 to 17, or they're moving from, let's say Node 18 to Node 20, they can go make those changes directly in their BitBucket pipeline, Yamls or GitHub actions. And there's no more of this kind of lost cycles of creating the ticket, waiting for the ticket to be prioritized on a different team, and then that team actually accomplishing the work. It more or less brings that work closer to the development team and allows them to reach more velocity than relying on a completely different team to make those changes.
[00:10:06] Speaker B: Okay, yeah, that's a very good point to know.
And so going from that, how do you think teams can audit their current stack? So these hidden costs aren't, you know, hidden? Just how can they evaluate their stack and identify overlap and waste to prevent more issues and wasting things?
[00:10:29] Speaker C: Yeah, I think the first, more or less, the first step before even, you know, logging into your CI CD and really doing any kind of information collecting is to step back and say, what is it that we need out of our cicd? If it's something, you know, a lot of organizations might produce internal apps and they don't really, you know, put applications out for consumers to use. They're going to have a different set of requirements even internally than, let's say, a company that, you know, puts out a mobile app or has a website that anybody Any consumer can visit, they're going to have different requirements around security, different requirements around code testing. And so I think it behoves those, behooves them to back up and take stock of what their actual requirements are. And then once they have a good understanding of, hey, we need, you know, our CI CD pipeline needs to be able to do security audits, it needs to be able to do code quality checks, then that's when you can really dig down into the weeds and figure out, okay, what is this CICD stack doing today? And can that be done by something that we already, you know, subscribe to or purchased or already own?
[00:11:42] Speaker B: Yeah. So going from that, what do you think is like the quickest win? What is the thing that teams should check first?
[00:11:51] Speaker C: I think the quickest win is again backing up, taking stock of what it is you need out of a cicd platform. And if it's something, like I said, pretty simple, you need to push code into your instances or your kubernetes cluster or whatever it may be, you need to do security checks and code quality checks.
Those are pretty run of the mill. They're offered in almost every CICD platform.
GitHub Actions has integrations, BitBucket Pipeline has integrations that you can actually accomplish those tasks and you don't have to go and build this super custom framework that runs within Jenkins or Travis CI and accomplishes all those things for you.
A lot of these technologies or integrations in currently hosted versioning offerings, those are pretty quick to get set up. If you have an API key, you can go in, configure it once, and then use it across all of your repositories.
[00:12:52] Speaker B: And yeah, going from that, do you think we're trying to optimize tools, we're trying to not have too many hidden costs.
What do you think? Teams chase these shiny new tools way too much and it's too often at the expense of cost and simplicity at their own company.
[00:13:13] Speaker C: I think there's a mix of both. Right. So I think there's a mix of where teams see something that, you know, it's a, it's a 5% feature where, you know, only 5% of everybody that uses the product actually utilizes that feature. But they see it as, this could save, you know, 20 hours a week, or it could save five hours a week. So they go chasing after that, not really understanding what the implementation, implementation costs are or again, what is the overhead on the teams that have to keep up with that integration and make sure that it doesn't break and when it Breaks, they have to go and solve for why it broke.
But also on the flip side of that fence, I think there's a lot of organizations out there that are comfortable with having two separate tools that mostly do the same thing just because it's a known quantity.
They don't want to, for, for example, move off a dedicated CICD stack and move that into their versioning system, whether that be GitHub or GitLab or Atlassian BitBucket. They much rather stay the course and just do what's always been done, regardless of what cost savings might be there and what procedural value it might bring to the company.
[00:14:25] Speaker B: Okay, yeah, I'm just going to give you another follow up question from that.
So when should I know if choosing a new tool is the right move? How can I evaluate the tools I'm currently using and say, hey, this new tool just came out. Is this the one that I should be pursuing? Is this the one that is best for our company and especially my team?
[00:14:49] Speaker C: Yeah, I think there's a couple different criteria where that becomes pretty clear cut. If the tool provides functionality that, let's say, you know, your versioning system doesn't provide, then that's pretty obvious win. Right? We need that to accomplish xyz. That's why we're getting this tool. But if it's something that you might be able to get 80% there, there may be a few manual steps involved and it's, you know, not completely automated, then that's when you have to weigh is, is the cost of the licensing for the tool worth it? Is the overhead that it's going to impose on my teams that have to manage it, is that worth it for what might be a 15 minute step, you know, for a release manager or a DevOps engineer to go in and execute that step? Are you, it comes down to, are you really saving the money? If you're going to be putting up a lot of upfront work to get this, you know, new tool or integration set up and it's really only going to save, you know, 15 minutes a week or a half hour a week. That's where the calculation of, you know, is this worthwhile to implement?
That's where it starts to get a little fuzzy and that's where it requires more diligence in terms of, you know, is this actually needed at our organization?
[00:16:07] Speaker B: Okay, so have you ever seen a company take that tool consolidation a little bit too far then where they lost a lot of value?
[00:16:18] Speaker C: I've seen.
So it again depends on the company's requirements. But I have seen in the past where a company, let's say they moved everything into hosted GitHub. It's very rare that these third party software as a service providers ever have issues. But if they do have issues, and let's say your, you know, your account, your repositories, go read only, they're having an issue with their build pipelines or their GitHub Actions or whatever the underlying implementation might be. That's where, you know, if your organization relies on the velocity of releasing apps, you know, two or three times a week, that's where you could get into some trouble because now you're blocked from being able to release anything until a third party gets those integrations up and running or gets, you know, the underlying implementation up and running again. And so I could see where that would end up having a negative impact on the organization. Especially if it's like I said, one of those organizations where they have to continuously move fast and bring new versions of whatever it is, whether it be a mobile application or a website.
If they're having to do periodic releases and something was to happen to the third party, then they're kind of out of luck. They have, they're at the behest of that third party to get the underlying implementation or technology back up and running before they can even release, you know, any code, so to speak. But, and I've also seen it kind of on the flip side of that, right, where they're already using third party CICD tooling, but their repositories go into read only mode or the provider ends up having an issue on their end. And so it's kind of a trade off, right? It depends on the actual, the organizational requirements. So if you're releasing, you know, once a month and that's your cadence, then you have a little bit of a window there. If something was to happen with a third party provider versus if your cadence of releasing is once a week or three times a week, you don't really have that cushion. If a provider ends up having an issue, that's one spot where it would make sense to probably host things on your own. If you require that kind of uptime so that you then have control over, hey, this service is down, you know, push on the server or drive down the data center and get it back up and running. Because we need to release on that type of cadence, right?
[00:19:01] Speaker B: Yeah, I think those are really great points. And just going from that, I'm going to ask one of our bigger questions. I think companies really should look at and pay attention to. I think it'd be very helpful.
How do you balance cost savings with, with innovation when you're evaluating your own tools?
[00:19:22] Speaker C: I think that's a good question.
It really comes down to, you know, your due diligence. Is that tool going to, you know, provide xyz that's going to make us faster or it's going to introduce some new functionality or feature we couldn't get out of our other tools that are really going to provide our developers, our DevOps engineers with game changing ability and functionality versus what are the upfront implementation costs of that and what are kind of some of the lingering costs as the product or the innovation or the technology that you purchase ages And I think that's where it's not really a one size fits all. It really comes down to the organization and what they're looking to achieve out of the tool.
And, and again, it could be something as simple as hey, it makes our developers lives easier and they could push code a lot faster. Or it could be something as simple as using Ansible or Terraform to manage infrastructure. It all comes down to what's the overhead on supporting this particular functionality or technology we're bringing on board versus what are the time savings for developers for your DevOps engineers? And does the cost of bringing that item into the organization or the licensing cost for it, does that outweigh the productivity enhancements and the ability to empower the dev or the dev teams or your DevOps teams?
[00:20:57] Speaker B: That's very good point as well.
And I'm just talking a little bit more about Arbor Digital.
How have you seen Arbri Digital help save money through tool consolidation enhancements that you've seen?
[00:21:12] Speaker C: Again, it comes back to it's not really the licensing aspect of it per se because you can get a lot of these CI CD tools either open source or for a very low cost. Where we see the significant advantage is you don't have to have engineers spending their time maintaining these tools and making sure when application updates come in that it doesn't break, you know, your custom pipelines or some of the plugins that you've installed in these tools. And it also simplifies the process inside the organization.
Instead of having, you know, three steps to get to, we won't use production as an example, but Instead of having three steps to get to QA or UAT, you now have just one tool where you centrally manage all your developers, your DevOps profiles for the individual contributors and then they have access to the build pipelines to be able to modify them how they see fit. And then that really brings everything process wise closer to who's actually generating the code that makes up the functionality of your app or your website.
[00:22:25] Speaker B: Have you seen a specific instance that Arbore Digital has helped with tool consolidation recently?
[00:22:38] Speaker C: That's a good question. We have had a few customers where we've advised them to move off of some of the more open source, customized, build CI CD functionality and move into either GitHub Actions or BitBucket Pipelines.
Again, for all the reasons that I've kind of pounded on throughout the podcast, it removes the overhead of having an individual engineer or DevOps person kind of babysit the CICD stack and make sure that the updates are applied cleanly and allows them to focus on other things that either empower your development engineering team to make their lives easier in the day to day, or they could start focusing on other special projects that bring a better value to the organization than, you know, making sure Jenkins can be updated to the latest version or making sure, you know, Travis CI doesn't break when we apply this latest change.
[00:23:38] Speaker B: Yeah, and I think for the reasons you mentioned, I think that's really where our breed digital shines.
You really make sure that the tools fit properly.
And just wrapping us up a little bit. Is there anything of note that we missed that you think is important to let people know?
[00:23:58] Speaker C: I think I kind of hammered home this point throughout the podcast, but I think there are times at an organization where it necessitates taking a step back, taking inventory of your tools and seeing what does this tool functionally provide for the organization. Is it, is it something that we have another tool that we're paying for, you know, gets us most of the way there. And if it does, you know, let's say tool A only gets you 50% of the way there, but you already have tool B, which could get you 80% of the way there. It makes sense to migrate off of tool A and on the tool B just because, you know, you're going to be closer to the actual end goal and it might be a little bit more expensive, you know, upfront for the additional licensing or additional nodes or whatever the licensing model might be. But you could also save money not having engineers having to spend, you know, time and processes and things of that sort maintaining the tool that only got you 50% of the way there.
[00:25:01] Speaker B: Definitely.
[00:25:02] Speaker C: Either be maintaining the tool that provides, you know, additional functionality on top of what you already needed and then that makes sense organizationally to, you know, retire tool A and move into tool B.
[00:25:16] Speaker B: Oh, Yeah, I think especially focusing on the long term savings by choosing your right tools, especially the most a really important part when looking at the short term costs, upfront costs that you mentioned.
So I think that's just a great place to wrap up. Dwayne, thank you for your time today. And thanks for joining us. And until next time.
[00:25:37] Speaker C: Yep. And until next time.
