DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. DevOps and CI/CD
  4. Does Open Source Have a Place in DevOps?

Does Open Source Have a Place in DevOps?

Should you encourage freedom among staff to use whatever they want to get the job done, or promote a more structured approach?

Yaniv Yehuda user avatar by
Yaniv Yehuda
·
Jan. 07, 16 · Opinion
Like (1)
Save
Tweet
Share
3.75K Views

Join the DZone community and get the full member experience.

Join For Free

A number of issues frequently arise as IT teams begin to apply automation to more aspects of the delivery process. If left unchecked these can end up impeding higher level progress. A white paper from CA Technologies explored one of the most frequent issues: “The Open Source Dilemma.”

Open source software (OSS) is generally considered to be an integral part of DevOps, and for a couple of good reasons. It has led to the rapid emergence of innovative tools to meet the requirements of those leading the automation charge, and has also made those tools freely available. DevOps practitioners can adopt solutions to try new ideas and approaches without going through the usual investment justification and procurement process, or even seeking management permission.

But this can lead to a dilemma. Should you encourage freedom among staff to use whatever they want to get the job done, i.e. get out of their way completely, or promote a more structured approach?

Allowing freedom can mean teams are never constrained by limitations of the ‘company standard’ option — a frequent complaint when people are forced to use tools that are a poor fit just because they have already been paid for. When no money is involved, however, it’s all too easy to just grab something that appears to be suitable without conducting proper due diligence, e.g. considering how requirements may change down the line or how colleagues have met the same need. Perceived "coolness" of tools and marketability of associated skills can also influence choices.

This matters because decisions based purely on personal preferences and a parochial view of needs risk duplication of effort, redundant solutions, integration disjoints, and lock-in to tooling that is only partially fit for purpose over the longer term.

Building on the above, there is also a tendency for enthusiasts to sometimes get carried away with the power of their chosen tool, in turn leading to overextension of solutions. With enough scripting it’s perfectly possible to use build automation tools to configure hardware, or ops automation tools to run software builds, but neither is necessarily a good idea.

For the avoidance of doubt, it’s important to reiterate that implementing DevOps at scale is not about throwing out all of your open source software and best of breed solutions, and replacing them with integrated suites of "big iron" commercial software. A big part of DevOps is about getting away from the old rigid approach of forcing broad use of solutions that handle a range of requirements, but none particularly well.

It makes sense, for example, to continue to exploit OSS tools in most areas of DevOps. Even if you elect to pay for enterprise distributions and associated maintenance from commercial providers, you will still benefit from rich community and ecosystem support, and advanced availability of features to enable adoption of new ideas and practices. Sacrificing such things for the sake of standardisation is counterproductive. At the same time, there are some areas in which consistency allows you to optimize efficiency, quality and service levels without compromising agility.

The trick is to know where you need consistency and where open source can be a good option, and to find the balance between freedom and structure.

Open source DevOps

Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • A Simple Union Between .NET Core and Python
  • Data Mesh vs. Data Fabric: A Tale of Two New Data Paradigms
  • The Top 3 Challenges Facing Engineering Leaders Today—And How to Overcome Them
  • How and Why You Should Start Automating DevOps

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: