Arul Jegadish
The DevOps methodology is becoming mainstream for good reason: 99% of practitioners say it has positively affected their organization.
While DevOps is foremost a way of collaborating, a lot of it is shaped by tools. And it turns out that many popular DevOps tools, such as Prometheus, Argo, Grafana, KubeFlow and Jenkins, are open source software (OSS).
While using OSS is free, assembling an OSS DevOps toolset — with an average of 15 tools per company — isn’t without challenges. Let’s take a look at what these hurdles are and how to avoid them.
Pick active, backed projects
Before adding an OSS project to your DevOps toolset, make sure to perform a full audit: How many contributors does the project have? Are they individuals or organizations? How quickly are issues resolved? Is their community forum, or Slack, active?
This will give you a picture of the overall activity and health of the project.
Even established OSS projects can be at risk. For example, logging tool Log4j has been in murky waters since last year. Numerous serious security breaches were found, and it took time for the community to develop security patches.
These patches themselves unfortunately brought in new security vulnerabilities. And because the tool is embedded in so many parts of the software stack, fixing issues is a tough task. For smaller organizations with a small IT budget or no exposure to security issues, the patching may never happen. The situation is so bad that the FTC is stepping in and threatening to start handing out fines.
Picking projects endorsed by leading OSS leaders such as CNCF and the Apache foundation is another good indicator. These organizations will perform security audits on projects they support, and, more broadly, ensure that they have reached a level of maturity based on clear criteria.
For example, the CNCF process has three stages — sandbox, incubating and graduation — so that companies know what they are getting into by picking an OSS project. Depending on your organization, you might only allow projects that are past a specific stage. These organizations are community-centric, so these tools tend to be more trusted among the developer community.
Watch out for licensing requirements
Open source does not mean that you can do whatever you want with the software. There are plenty of OSS license types, and you must understand them to verify they fit your needs. Some questions you may want to ask when shopping around include: Will I need to customize the software? Will I sell a part of the customized software? Will I want to sublicense it?
Even if you pick a proper license, a project can decide to change it. It is pretty rare, but it does happen. For example, Elasticsearch, one of the most popular search engines and a key element of most DevOps toolsets, recently switched from Apache License 2.0 to the Elastic License and Server Side Public License (SSPL). This event triggered a lot of mixed reactions in the community.
While every license has pros and cons, I recommend MIT, Apache 2.0, ISC License, and BSD-3 and BSD-2, because they are among the most permissive ones. They give you the freedom to make changes and distribute. Projects with permissive licenses tend to see high participation and adoption within the community.
Favor open standards
Using observability as an example, DevOps tools that use the OpenTelemetry framework, an open standard, provide a lot of advantages. The DevOps stack becomes plug-and-play, and new tools can be added to the pipeline seamlessly, which also helps avoid vendor lock-in.
As part of their DevOps strategy, one of our large customers was working on implementing a centralized observability system. They wanted to use two different tools: a leading commercial tool and an OSS ELK (Elasticsearch-Logstash-Kibana) stack. Because the commercial solution wasn’t following open standards, they had to make custom code changes to their applications. That extended the project time to over a year, which caused unpredictable, spiraling costs, without any success.
Using open standards also better positions your company to hire and retain talent. Because they are broadly used, you will have a bigger pool of talent to choose from, and your current engineers can use the acquired knowledge in the future, too.
Consider complexity and cost
As your company follows DevOps principles, the associated tools will become the backbone of your product-building process in relation to development, testing, deployment and monitoring. Therefore, this set of tools will grow in management complexity and require resources to run.
Let’s look at an ELK stack, a pillar of many companies’ DevOps toolset. Multiple total cost of ownership (TCO) analyses have found that the cost of running an ELK stack can easily go from $200,000 to over $2 million a year for an average, growing startup. Most of the cost is for hosting, followed by talent, support and customization. Setting up the stack is the easy part, but day-to-day operations such as upgrading, patching, scaling and planning for disaster recovery can be rough.
You must remember that while the software is free, operation costs are always a reality. Sometimes, it might make financial sense to use a SaaS version of an OSS software or private SaaS if the company stack has to be on-premises for data privacy reasons. Externalizing the complexity offers better time-to-value, as the engineering team gets to use the tool sooner, and it reduces toil by allowing DevOps engineers to solve problems more closely related to the company’s core business.
If you want to do it on your own, follow best practices and pick a deployment method recommended by the community. For example, using a pre-existing Kubernetes Helm chart along with the recommended operator will let you take advantage of updates and easily get help from the community if you run into issues. Similarly, look for binaries and container images built and published officially by the project team.
Using OSS for your DevOps toolsets isn’t without challenges, but it’s worth it. Most companies who have OSS-based DevOps stacks reported reaching a “fully deployed” state compared to only 30% of their counterparts who didn’t.
Comment