Any DevOp team wants to write clean code that enables minimum downtime, scales to meet demand and can be easily maintained. This, however, isn’t always easy to achieve. Some of the popular configuration management systems that development teams use include Chef, Puppet and CFEngine, to name a few.
These systems abstract the difference between the various IT environments function, but the problem is that deploying these systems is rarely without hiccups and they still often lead to errors.
Containers are still a relatively new solution to this problem. With containers, the image that was built and tested on a developer workstation is able to seamlessly run in production, which solves the ongoing challenge of cross-platform portability of applications. Many dev agencies have switched to containers because they were able to pick up on one or more of these signs that it was time to stop writing configuration management code:
1. Your developers have to go into lengthy details of what they are doing
Developers and engineers often take deep dives when asked about the challenges they are currently experiencing on a project. If you start picking up on how often they are spending hours on end writing configuration management code, then it’s a clear sign that they are not doing work that truly benefits the business. With configuration management, a significant amount of time still needs to be spent on replicating the process on different servers. Instead of creating one solution that works and can be automated, modifications to infrastructure happen on an as-needed basis, are often not well-documented, and leads to unnecessary manual duplication efforts.
2. You’re investing in many configuration management processes and tools
In the past, configuration code was written haphazardly if and when you had to deploy new software. Adding to this dilemma is that only one person knows how to code for the configuration management setup. In order to streamline this part of the build, your team members are now putting processes in place to make configuration management easier. There are now tools, scripts and user guides within a repository to help them with configuration management. The problem is that many developers find it difficult to keep the documentation up to date and this type of process integration is crucial for checks and balances of data. Configuration management code essentially makes change, incident, and problem management a more laborious process. Multiple tools are also needed for proper integration because there isn’t a single tool that can deliver the full functionality that is needed, so you have an ever-increasing list of configuration management tools that your team needs to invest in and use.
3. There is a lot of unnecessary duplication
Unfortunately, configuration management code isn’t an ‘’install tool and run’ process. Developers will have to revisit the initial design multiple times and rework their configuration management code to match new business needs and requirements. Most experienced dev agencies don’t necessary battle to execute configuration strategies, but it leads to a lot of wasted time. It’s not always easy to pick up on which parts of a project are eating away at your team’s time, but if you notice a lot of duplication in code and processes, then it’s a clear sign that you need to stop writing configuration management code.
4. Quick and easy changes aren’t quick and easy
In today’s business landscape, IT needs to offer fast problem resolution. If a small change to your application or software takes days to achieve because you’re busy running and testing it in various environments, then you have already spent too much time writing configuration management code for that service and you will continue to do so for every future change that is needed.
5. You’re worried about risks and security threats
CTOs and dev agency owners should always have risks and security on the top of their priority list, but having to consider everything from the prior structure and how this can constantly lead to security gaps due to new incompatibilities that may arise, is a sign that too much configuration management code is needed to run your services efficiently. Adding to this problem is that it is usually difficult to determine which modifications to infrastructure were authorized, making accountability to security risks another problem that many CTOs and dev agency managers have to deal with.
6. When configuration management is applied throughout the service lifecycle
Some configuration management will always be needed during a build, but if your development team is writing configuration management code throughout the plan, build, run and govern processes, then it’s a sign that you should actually stop writing configuration management code altogether.
As you can see, the configuration management vs. containers debate points to containers being a viable solution to dev teams who are still writing configuration management code. Using containers can help you with continuous delivery and eliminates the need of your whole team having to understand how your configuration management processes are pieced together.