The future of open source and DevOps.

Source- jaxenter.com

Only a few short years ago, organizations considered open source to be a high risk. These days, enterprises and governments alike are embracing open source and placing it at the center of their software development stacks. IBM’s recent acquisition of Red Hat and Microsoft’s acquisition of GitHub, which is the home of many open source projects, show that open source has won the hearts and minds of the general populace.

In fact, if you’re not already using open source, you’ll soon be marginalized by those organization using it to move faster and be more innovative. Even large enterprises like Microsoft, Google, Intel and IBM have become major contributors to open source code.

The writing on the wall is clear: for large, independent software vendors not doing open source today, you’ll need to either start open sourcing your code or else purchase an open source vendor to stay relevant in 2019. Your open source will need to be layered on top of DevOps, responsible for bringing together everything from coding and building to deploying and monitoring applications.

Below are predictions about where open source and DevOps are going this year.

The increasing importance of DevOps

DevOps will become a bigger focus for open source practices. Specifically, this relates to DevOps teams with open source in their CI (Continuous Integration) practices, as well as how to programmatically enforce open source policies to ensure compliance against practices. And, perhaps just as importantly, how to automatically update CI/CD (Continuous integration/Continuous delivery) servers with the latest open source language build.

To ensure a truly agile framework, DevOps will need to connect with Build Engineering. And the Build Engineering process will need to become automated, reproducible and continuous to produce continuous builds for the DevOps process.

Additionally, security testing will need to begin much earlier in the development lifecycle. In some circles, DevOps is synonymous with DevSecOps. However, for DevSecOps to become a reality, you’ll need to not only consider baking security into code but also think about how to build open source language builds on-demand with only what you need.

This year will also see enhancements in performance, speed-to-market and ability to comply with enhanced security policies. The promise of DevOps is agility; said otherwise enterprises thirst for the ability to be responsive to both changes in technology deployed as well as changes in market and customer needs. Agility is at odds with a one-size-fits-all approach, which inherently results in loading everything into a larger build, creates bloat and reduces performance.

Agility is also at odds with rigorous security practices and larger builds with greater attack surface. 2019 will necessitate reconciling speed-to-market, performance and security through a process for deploying and managing open source language artifacts inclusive of automatically updating CD servers with the latest open source language builds.

Important ways DevSecOps is changing

An increased focus on testing software earlier in the development process will accelerate push to production and protect the enterprise. Developers and engineering teams will need ways to bake security into the code without having to jump through hoops to pass corporate policies. This baking-in of security needs to be agentless and enable runtime monitoring that not only provides insights about new vulnerabilities (since the code was pushed to production) but also identifies where exposed code is running.

DevSecOps is changing in another important way: building only what you need and standardizing on builds based on language, operating system and vetted packages. This way, application delivery will be faster and more robust. Open Source language builds won’t need distributions heavy loaded with every package. This will improve performance but also decrease attack surface

Important open source trends for the new year

  1. Language-level automation

It will become standard to automate open source languages – an automated, reproducible process resulting in continuous language builds. Continuous language builds will enable organizations to accelerate productivity and give more freedom to developers. Stability of builds was a key concern reported by ActiveState’s 2018 Developer Survey, open source language automation automatically creates maintenance builds, reduces time to resolution of vulnerabilities to automate the app dev process.

  1. Effective deployment practices will require consideration of the growth of polyglot

Today’s organizations must work with applications and systems built from different programming languages, tech stacks and environments. Yet systems are siloed per language while DevOps works in polyglot environments. Systems that support and reflect the polyglot environments that DevOps navigates on a daily basis will be developed, introduced to DevOps, and ultimately solve the “polyglot is killing the enterprise” problem.

  1. Creating a trusted source of information

A method of centralizing open source languages and the related packages, dependencies and licenses deployed across environments will arise. This will enable languages and packages to be tracked across DevOps and provide a comprehensive understanding of open source usage. A single source of truth, a trusted source in the software supply chain, will become seminal.

Ring in the new normal

2018 saw significant changes in the open source world, and more changes are on their way. It has become a driving force in developers’ hearts and minds and will be closely aligned with DevOps. As the need for earlier testing arises, DevSecOps will change to meet those challenges. Multi-language environments will proliferate, and it will become the norm to use Open Source Language Automation. Enterprises that don’t embrace these new tools and new ways of doing business risk becoming irrelevant.

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x