Perhaps, the most challenging part of DevOps is that there’s no universal way to do it right. The tools you choose, the practices you apply, and the experts you involve will vary depending on your case. Still, certain elements seem to be set in stone. Here they are.
People are the fundamental element of DevOps success (or failure). The hardships of the M&E startup began with the team, which didn’t have the expertise sufficient enough to pick suitable tools and configure them in a way that worked for the client.
What’s more, the significance of the team goes beyond the technical side of things. Without a suitable team in place, it’s impossible to build the DevOps culture—the central aspect of the DevOps success according to DORA’s report.
So, if you see that your DevOps efforts don’t bring the expected results, consider delegating them to a team focused on results and growth acceleration.
Once you have all the needed expertise aboard, the next step is scanning the existing DevOps architecture for bottlenecks and areas for improvement.
At Alpacked, this happens during the discovery phase. After identifying the business and technical requirements of the client, we get access to their DevOps setup. We analyze everything that concerns DevOps—including CI/CD pipelines, environments, dependencies, tools, code, and even chats—and evaluate it against our standards. After that, we match our findings with what was requested by the client and proceed to outline our strategy.
DevOps was born to help businesses win competitive advantage and meet customer needs in the most cost-efficient way possible—a purely business goal. So, when building your DevOps strategy, it’s vital to take the business element into the equation.
What does it mean? First of all, it’s paramount for your DevOps team to be aware of the project’s ultimate business goals. After all, it will affect their technical decisions. For example, in one of our projects, the client wanted to make their infrastructure as cost-efficient as possible. As a result, the combination of AWS EKS Fargate, AWS Aurora RDS, AWS Lambda, Pulumi, and the feature “suspender” (built specifically for this project) allowed the client to scale up and down their infrastructure with a click.
At the same time, it’s critical for business decision-makers to stay up to date with what’s going on in the technical trenches. For instance, in the project mentioned above, the client declined a couple of our recommendations because of the limited budget—as a result, we focused on the most critical parts of the solution. Hadn’t they done that, they would have found themselves out of budget in the middle of the project.
Since the CI/CD market is dynamic, no matter how genius your DevOps strategy is, it isn’t something you build once and for all. New technologies and practices are mushrooming all the time, and your needs might change, too. Given that, you should always be on the lookout for better ways of doing things.
For instance, in a project with one prominent offensive security provider, our role extended beyond the basic DevOps routine—we also functioned as R&D experts, constantly experimenting with new solutions and incorporating them into the client’s workflow. As a result, we managed to take some inconveniences and inefficiencies out of the client’s processes. After all, continuous experimenting and improvement constitute the backbone of the DevOps mindset—and that case just proved this fact.