devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

Linux Foundation Takes Control Of AsyncAPI Specification

The Linux Foundation announced today that it now plays host to an AsyncAPI Initiative that has developed a specification and a suite of open source tools for asynchronous application programming interfaces (APIs) and event-driven architectures.

Founding sponsors of the AsyncAPI Initiative include Ably Realtime, Apideck, Bump, IQVIA Technologies, Slack, Solace and TIBCO. Most recently, Postman, a provider of API management tools, committed to providing engineering resources to the project as well.

AsyncAPI provides a language for describing the interface of event-driven systems, regardless of the underlying technology, and supports the full development cycle of event-driven architecture. That approach helps unify documentation automation and code generation, as well as managing, testing and monitoring asynchronous APIs.

Chris Aniszczyk, CTO and vice president for developer relations at the Linux Foundation, said the Linux Foundation will work with the member organizations to facilitate a governing framework similar to the frameworks other open source projects have adopted under its auspices.

In general, reliance on event-driven architectures is on the rise thanks, in part, to the rise of digital business process initiatives that require the processing and sharing of data across multiple platforms in near-real-time. The AsyncAPI Initiative makes it simpler for disparate event-driven platforms to be integrated. It’s unlikely multiple organizations involved in a digital business initiative are ever going to standardize on the same event-driven platform, so an AsyncAPI specification provides a critical linchpin.

Usage of the AsyncAPI Initiative is already fairly widespread, with Adidas, PayPal, Salesforce, SAP and Slack all employing it in production environments. In fact, the Linux Foundation cited research that identified AsyncAPI as the fastest-growing specification being implemented by developers, after seeing adoption rates in production environments triple from 2019 to 2020.

Event-driven IT architectures have, of course, been around for decades. However, as they have gained traction in the modern era of software development, the need for the equivalent of a REST API for asynchronous communications between platforms, based on different event-driven architectures, became apparent. The AsyncAPI doesn’t replace the need for other types of API specifications, but Aniszczyk noted that, over time, it will soon player a larger role, especially as cloud-native application environments become more distributed and the number of use cases that can’t be addressed using traditional batch-oriented techniques continues to rise.

In the meantime, the number of providers of event-driven platforms based on proprietary architectures spans vendors ranging from Oracle and IBM to cloud service providers such as Amazon Web Services (AWS). At the same time, open source messaging platforms such as Apache Kafka are starting to have a significant impact on how IT teams build their own event-driven platforms.

The level of enthusiasm for an API specification that makes all those platforms more interoperable than they would otherwise be is unclear. However, as modern IT platforms continue to evolve, more IT teams are becoming aware of the crucial role API specifications play in preventing them from becoming locked into one platform.

March 30, 2021
Python Remains Popular in Programming Language Study

A ranking by analyst firm RedMonk reflects on Python’s continued popularity as a leading enterprise programming language for a number of reasons. According to a recent study by RedMonk, JavaScript also remains widely popular as the web development programming language of choice for a significant number organizations.

In many ways, Python’s strong showing in the ranking — drawn from GitHub pull requests and Stack Overflow data — indicates its long-term viability among DevOps developers.

“One lack of change that is worth surfacing is Python’s number-two spot,” Stephen O’Grady, a RedMonk co-founder and analyst writes in The RedMonk Programming Language Rankings: January 2021. “Java was extremely hot on Python’s heels – and was, in fact, closer to the number-one ranking than to PHP behind it – but Python’s ability to defend its new high ranking is notable.”

Python’s prolonged high ranking is notable because of its versatility, Rachel Stephens, a RedMonk analyst who is responsible for the RedMonk Language Rankings’ design, told devopsy.kinsta.cloud. “The breadth of use cases — and associated libraries that support those use cases — means there are a number of possible entry points for developers. The number of toeholds for the language within the enterprise helps its ubiquity,” said Stephens.

There also remains much discussion about what accounts for Python’s continued popularity beyond the scope of the study. A popular subject in forums, including Reddit, Python is typically described as highly versatile, relatively easy-to-learn and a simple, yet elegant language. While not cited in the RedMonk study, some software engineers and coders — such as this writer — appreciate how Python can make more intuitive sense, and is also less rigid compared to, say, a classic language such as C++. While JavaScript is largely used for web apps and scripts, of course, Python could arguably be the most popular language outside of the sphere of web development, thus accounting for its second-highest ranking in the study.

As such, “due to the accretive nature of our methodology, movement within the top-ranked languages is an infrequent occurrence,” Stephens said.

“[However], Python overtaking and sustaining its ranking over Java was a big deal. That said, we remain strong believers in the future of Java and the Java ecosystem, and we know there is a vast amount of enterprise Java that isn’t captured in the metrics we use,” Stephens said. “We don’t view Python’s ascendence as a zero-sum gain over the use of Java.”

For JavaScript, “in spite of all of the competition from up-and-coming languages, all the discussion of fragmentation – and even criticisms of JavaScript the language itself – it remains remarkably popular,” O’Grady said.

“Simply put, JavaScript remains – its detractors notwithstanding – a force of nature like no other within the industry, and there are no indications in the data that this is likely to change any time soon,” O’Grady added.

Meanwhile, in the book Hardcore Programming for Mechanical Engineers, published by No Starch Press, JavaScript trails Python in other rankings, while Python is also more popular than JavaScript for other reasons than those described in the RedMonk study. Python, for example, is cited as the ‘The Most Wanted Language,’ based on a Stack Overflow survey.

While Python is not the fastest language, as measured in benchmarks listed in Hardcore Programming for Mechanical Engineers — Go consistently outperforms it, for example, in execution times — Python’s popularity remains very high overall, according to the book’s author.

“These results are not surprising; Python is an extremely versatile and productive language,” author Ángel Sola Orbaiceta wrote. “Writing code in Python is a delight, and its standard library is well-equipped: for just about anything you want to do, Python has something ready to help.”

March 29, 2021
Progress Unveils First Update to Chef Automation Portfolio

Progress today announced it has enhanced its Chef Enterprise Automation Stack (EAS) and released a new version of Chef Infra Client that promises to make the programming language on which EAS relies more accessible.

Sudhir Reddy, vice president of engineering for Progress, said the latest versions of both offerings are the first updates to the Chef portfolio since Progress acquired the company last fall.

Chef EAS combines elements of the Chef portfolio in a way that makes it easier to develop and integrate DevOps workflows that span everything from provisioning infrastructure to deploying applications. The latest update to EAS adds the ability to automatically execute compliance audits as part of any Chef Infra Client run using Chef InSpec tools. At the same time, the latest update also simplifies the implementation of the patch management processes.

DevOps teams can also view and manage Chef Infra Server details via the Chef Automate framework. Those views, when combined with Chef Infra Client Run Reports, provide insights into the various policies and Chef objects in use on a system.

Finally, the Chef Workstation module includes the Chef Habitat command line interface (CLI) to further simplify workflows.

Ultimately, Progress is moving toward creating a common user experience across all elements of the Chef EAS suite of tools, Reddy said. In effect, EAS is emerging as the control plane through which the entire Chef portfolio will be managed, Reddy added.

Meanwhile, Infra Client 17 promises to make the Chef Language underpinning that suite more accessible. It provides a streamlined developer experience as well as pre-built integrations with various cloud services. In addition, Progress is adding support for various ARM processors used in cloud services, macOS Big Sur, the Apple M1 architecture, Windows 8 and PowerShell Core.

Progress also enhanced its ability to securely capture metadata from the Amazon Web Services (AWS) public cloud as well as capturing data from Microsoft Azure clouds.

An early pioneer of a framework for automating IT infrastructure-as-code management, Chef is still widely employed. However, rival open source frameworks have since emerged, which Chef eventually responded to by making its core platform also available as open source software as it changed its business model. Progress today also announced it will recognize external contributors to the platform with recognition awards. Progress reports that, in 2020, there were more than 6,000 contributions from over 350 contributors in the Chef community in support of Chef Infra, Chef InSpec and Chef Habitat.

It’s still unclear how the battle for infrastructure-as-code framework management supremacy will ultimately play out. While many developers have clearly shown a preference for rival open source tools, Progress is positioning the Chef portfolio as a framework for IT organizations that need to automate processes at scale, including how application are deployed on infrastructure that is provisioned as code.

Of course, many rival framework providers have similar ambitions. The challenge, of course, will eventually be convincing organizations that tend to employ a wide range of tools across different departments to finally standardize on one framework versus another.

March 23, 2021
Eclipse Foundation Creates Adoptium Working Group for OpenJDK Binaries

The Eclipse Foundation announced today a working group that will establish a governance framework for an Eclipse Adoptium project that enables developers to download compatible runtimes based on OpenJDK source code.

Members of the Adoptium working group include Alibaba Cloud, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic and Red Hat.

OpenJDK is a free and open-source implementation of the Java Platform, Standard Edition that is provided by Oracle. AdoptOpenJDK was created in 2017 to provide open source, high-quality Java runtimes based on OpenJDK. Since then, AdoptOpenJDK has been downloaded more than 240 million times.

The Eclipse Foundation is now continuing that effort under an Eclipse Adoptium project that aims to become the primary source for OpenJDK-based binaries. The Eclipse Adoptium working group has negotiated with Oracle to create an OpenJDK Community TCK License Agreement (OCTLA) that will enable it to run compatibility tests to ensure conformance to the Java specification.

Mike Milinkovich, executive director of the Eclipse Foundation, said the Adoptium WG will provide the infrastructure, marketing, community building and developer education required to ensure timely releases and adoption of Eclipse Adoptium runtimes.

OpenJDK is a reference implementation used by multiple vendors to create their own binaries, which are only guaranteed to be compatible with the standard until the next update arrives; updates are released approximately every six months. The Eclipse Adoptium project will make it simpler for developer teams to identify which binaries are compatible with specific implementations of OpenJDK. Ultimately, the goal is to encourage developers to build applications using frameworks that make use of new OpenJDK features as they are added to the platform versus continuing to rely on older binaries.

At the same time, however, the Eclipse Foundation is also looking at making it simpler for enterprise IT teams to rely on long term support (LTS) licensing agreements that would be based on Eclipse Adoptium runtimes, Milinkovich noted.

Despite the plethora of programming languages developers use and even after 25 years, Java remains the dominant language for developers working in enterprise IT organizations. Over the last few years, OpenJDK has gained traction as organizations adopted an open source implementation of the specification that enabled providers of frameworks for building applications to reduce licensing costs.

It’s not clear at what rate enterprise IT organizations are replacing proprietary editions of Java with OpenJDK. However, in the wake of the economic downturn brought on by the COVID-19 pandemic, reliance on open source software has increased to reduce costs. At the same time, many organizations are looking to build microservices-based applications using Java frameworks that are based on OpenJDK runtimes.

Regardless of the underlying platform employed, as developers are asked to build and deploy applications faster, most of them will rely on the programming language they already know rather than take the time to master another.

March 23, 2021
Open Source Vs. Proprietary DataOps
Core DataOps concepts are making their way into data engineering teams and, from there, into the broader enterprise. Data engineers are retooling how they create data products, and much of this work revolves around creating data pipelines.

DataOps pipelines offer the kind of observability that traditional data integration and ETL processes don’t or can’t. They allow you to continuously integrate and test new data sources and deliver data in streaming or batch contexts with higher levels of quality and reliability than traditional, siloed approaches. They can also support machine learning efforts by preparing data for training, testing and deployment.

DataOps pipelines shorten the cycle time between a data consumer’s request and how quickly and reliably the data producer can fulfill it, all while observing service quality throughout its life cycle. The challenge teams face when building pipelines is how to construct them. The two approaches, as I see it, are do-it-yourself using open source, or through commercial product acquisition.

Open source certainly has its vocal adherents and some visible successes, but there are trade-offs to taking the open source route.

Building Or Buying Your Pipeline

One advantage of open source is in its flexibility and availability. Open source licenses, excluding the SSPL, gives users incredible freedom over what they can do with the software. If you have the skill, you can compose a DataOps pipeline that can take any data, enrich it and route it to the right place. That flexibility, though, is also a downside. While you can do anything you want, you also have to do it. Open source projects like Kafka, Pulsar, Spark, Airflow and Flink don’t know anything about the data they’re handling. That’s up to the developer.

This may not sound like a problem, but today’s data engineers are handling dozens of data types in hundreds – or even thousands – of different formats. If you add in operational data, you’re also looking at data flooding in from firewalls, containers, SNMP traps and HTTP sources. And that’s just what’s coming at you. You also need to fetch data from object stores, multiple activity hubs and other messaging sources. No open source project natively supports the variety and volumes of data required in a modern DataOps pipeline. Every new data source you add means starting from primordial components rather than higher-level abstractions, adding time and undifferentiated effort to your work.

You’ll also need essential features like per-source backpressure, support for a range of protocols and data stores, role and permission management and so on. That’s a lot for overworked data engineering teams to build and maintain over the life of a pipeline.

There’s no ‘easy button’ for proprietary products, either. Many commercial products only support a handful of sources and destinations and may have excessive licensing costs related to data ingest rates or per-connector licensing fees. Also, they can be challenging to scale, from an operations perspective. Seeing a cool drag-and-drop interface may look great during the demo, but it quickly becomes a cluttered mess when you’re looking at thousands of similar data processing pipelines.

The advantages to commercial products center around the features enterprises need, like governance, management and security. They may also integrate with other components more readily than open source. Finally, having someone to call when you need support is also essential when running in production, although open source core companies also offer support.

Take a Higher-Level View

As you’re evaluating DataOps pipeline options, keep two things in mind. First, regardless of which path you choose, ensure your chosen technology offers observability and monitoring features. DataOps is about reacting to change faster, and you can’t react if you don’t know what’s going on. Building observable DataOps pipelines ensures you are delivering a valuable data product to the range of data consumers in your enterprise.

Next, get past the technology. DataOps is more a people discipline than a technology practice. A key component of a successful DataOps implementation is aligning metrics and incentives across teams. If the staff running the DataOps pipeline are disconnected from the business outcomes their data products inform and influence, they’re not incentivized to run the pipeline as a mission-critical infrastructure component. It’s key to align all of your teams with shared metrics and incentives.

DataOps Determination

Before you decide on your DataOps pipeline implementation, there are some things you should do.
- Determine who your customers are and what their expectations are around data delivery, enrichment, user experience and observability requirements. Are you only serving data scientists, or are you also serving infrastructure and operations, business intelligence and marketing? Knowing your customer allows you to make better decisions.
- Test the software in a real-world environment. Everyone dislikes being told to perform a proof of concept before you buy/build, because POCs are time consuming. Remember – they’re less time-consuming than picking the wrong tool and looking foolish later.
Engineering teams sometimes choose technologies that are in fashion rather than selecting the right tool for the job. Taking a pragmatic view of performance, manageability and engineering effort, as well as involving a wide array of stakeholders, will give you a higher chance of success with DataOps.
March 19, 2021
Harness Revamps User Interface for CI Platform

Harness today announced it has updated the community edition of its continuous integration (CI) platform with, among other updates, a revamped user interface.

Formerly known as Drone.io, the latest release also adds pipeline execution visualizations, governance and security controls and live CI pipeline debugging capabilities. Harness last year acquired Drone.io, an open source CI project, to extend its existing continuous delivery (CD) platform into the realm of CI. Harness claims there are now more than 50,000 active monthly users of the community edition of Harness CI.

Brad Rydzewski, co-founder of Drone.io, said the user interface for Harness CI will soon be applied across the entire portfolio.

The update to the community edition of Harness CI comes at a time when the debate over how tightly integrated CI and CD platforms need to be is heating up. Harness launched a namesake CD platform before it acquired Drone.io to add a CI capability. While most DevOps teams are proficient with CI, the CD side of the DevOps equation has proven more elusive. There are now GitOps advocates that contend the rise of Kubernetes makes it more advantageous to enable a separate CD platform to pull updates from a Git repository, rather than having them pushed out by a CI/CD platform. The challenge with CD has always been that each platform on which code is deployed is unique. Kubernetes, however, now provides a de facto standard layer of abstraction that runs atop multiple platforms.

Rydzewski said the integrated CI/CD approach will ultimately prevail, because it enables DevOps teams to more easily integrate a range of processes, including testing, that are required to consistently build and deploy applications at scale. Harness is, essentially, making a case for solving the CD challenge using a platform that encourages – but doesn’t require – a DevOps team to replace their existing CI platform.

Regardless of how DevOps evolves, the CD issue needs to be addressed. As the enterprise becomes more extended with the rise of both cloud and edge computing, the number of platforms a DevOps team needs to support continuously expands.

Despite the fact that DevOps teams employ CI/CD platforms, it is clear most of those organizations are not overly committed to the way they currently manage CD. It may be years before most organizations finally implement a consistent set of processes for automating application deployment.

In the meantime, the number of organizations just starting out on their DevOps journey continues to increase. There are still plenty of instances where organizations have yet to deploy any type of CI/CD platform. It’s also worth noting that, in many cases, different DevOps teams within the same enterprise have decided to deploy different CI/CD platforms.

Regardless of how DevOps evolves the pressure to automate is rising. The challenge many DevOps teams face today is the current platform they are relying on to automate the building and deployment of applications requires a small army of specialists relying on all too often manual processes to maintain.

March 18, 2021
Oracle Updates Java Development Platform

Oracle announced today the availability of Java 16, which adds 17 enhancements to a software development kit that is now being updated every six months.

Georges Saab, vice president of development for the Java Platform Group at Oracle, said while most Java development teams are still using Java 8 or earlier editions of the platform, the expectation is that many of them will soon move forward, as updates are made available in smaller increments that are easier to test and vet.

At the same time, Oracle is committing to make available long term release editions of Java that won’t be updated as frequently. While there are many organizations anxious to take advantage of new capabilities as quickly as possible, Saab noted there are just as many that value stability more than innovation.

The latest edition adds support for finalized pattern matching for instances and records, as well as other language enhancements that were previewed in Java 14. Developers can also employ a packaging tool to ship self-contained Java applications that will make it easier to deploy in modern IT environments, said Saab.

Additional capabilities now available include the Vector application programming interface (API), the Foreign Linker API (JEP 389), and the Foreign-Memory Access API that are all available in incubations as well as a sealed classes capability that is being made available as a preview.

In general, Saab said, one of the primary reasons many organizations don’t tend to update Java more frequently is the frameworks they rely on to employ it at a higher level of abstraction are still optimized for older versions. However, as Java updates are delivered in a more modular fashion, it will become easier for the providers of those frameworks to keep pace.

It’s not precisely clear to what degree IT teams are employing Java to build next-generation applications based on microservices. However, a recent survey published by VMware, found 95% of respondents have either already used the open source Spring framework, based on Java, to either containerize an application (65%) or plan to do so (30%).

A quarter of a century after its initial development, Java is still the dominant programming language relied on to build enterprise applications. In many instances, the lack of tools for building Java applications for Kubernetes platforms was a significant inhibitor of adoption for the cloud-native platform. In the last six months, however, the number of tools for building and deploying Java applications on Kubernetes clusters has increased.

Despite the proliferation of alternative platforms for building and deploying applications on Kubernetes platforms, the appetite for retraining legions of Java developers is low. Most developers will rely on the programming tool they already know, especially when it comes to building mission-critical applications for the enterprise. That may mean some of those applications might not be as fast as they could be, but, given the level of risk, there’s always going to be a natural tendency toward being safe rather than sorry.

March 16, 2021
Linux Foundation Project Secures Software Supply Chains

The Linux Foundation today embraced a sigstore project founded by Red Hat, Google and Purdue University to make it simpler for developers to employ cryptographic software, enabled by transparency log technologies, to secure software supply chains.

Luke Hinds, security engineering lead in the office of the CTO at Red Hat, said he and Dan Lorenc, a staff software engineer for Google, led a small team creating a lightweight mechanism for signing software artifacts, such as release files, container images and binaries, in way that creates an immutable, tamper-proof log.

Now, the goal is to take that project to the next level by contributing it to the Linux Foundation, at a time when the focus on software supply chain security has increased in the wake of a spate of high-profile breaches. As part of that effort, a free service, based on sigstore, will also be made available by the Linux Foundation to make the cryptographic software easily accessible to a wide range of developers.

Hinds said one of the reasons that artifacts are not signed by developers is that the current processes employed are too cumbersome. The cryptographic software is designed to be integrated as an extension of existing workflows, Hinds noted.

Because the log created is immutable, everyone participating in the software development process, including auditors, can now transparently track chain of custody for any software artifact, Hinds said. At its core, sigstore creates a set of short-lived ephemeral keys with a trust root based on an auditable public log.

Existing approaches rely on digests stored on insecure systems that are susceptible to tampering. Cybercriminals can, for example, swap out digests if they can gain access to compromised credentials. Those types of targeted attacks can be thwarted using sigstore, because the log management system that underpins it is immutable, said Hinds.

Of course, no system for securing software supply chains is going to be useful if developers won’t employ it. Key management, key compromise/revocation and the distribution of public keys and artifact digests are challenging to manage. Developers, then, need to determine which keys to trust in addition to learning how to sign them when different platforms are employed. Digests and public keys are also often distributed across vulnerable websites susceptible to hacks, or stored as a README file on a public git repository.

As organizations embrace DevSecOps best practices, it’s only a matter of time before the entire software supply chain comes under greater scrutiny. Ultimately, the issue will come down to finding a way to secure those supply chains, either from the top down by deploying and maintaining a platform, or simply making it easier for developers to better secure artifacts from the bottom up.

Regardless of approach, the signing of software artifacts should, one way or another, become more routine in the weeks and months ahead. The biggest challenge will be overcoming the simple inertia that currently exists among developers who routinely ignore the whole process.

March 9, 2021
Kong Integrates Service Mesh with OPA

Kong, Inc. today announced an update to Kong Mesh, built on top of open source Kuma service mesh, that adds support for Open Policy Agent (OPA) software that enables DevOps teams to manage compliance as code.

Kuma and OPA are both being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Kuma, unlike other service mesh offerings, provides connectivity across both microservices-based applications running on Kubernetes platform and monolithic applications deployed on virtual machines.

In addition to adding support for OPA, the 1.2 release of Kong Mesh adds authentication mechanisms between the global and remote control planes operating across multiple zones. That functionality extends the Kuma Discovery Service (KDS) to support multiple authentication mechanisms.

Finally, Kong has added support for the federal information processing standard (FIPS).

Like the Istio service mesh, advanced by Google and IBM for Kubernetes environments, Kuma is based on open source Envoy proxy software. In contrast, however, Kuma is both lighter-weight and designed to span both cloud-native and legacy application environments.

Marco Palladino, CTO at Kong, said OPA support will be a significant advance for both classes of workloads as organizations start to employ Kuma within the context of zero-trust computing environments. As DevSecOps processes are extended to include managing compliance as code, OPA will provide a programmable mechanism for ensuring that policies are not only properly implemented, but can also be easily audited, Palladino said.

In general, an effort led by Kong, VMware and others to elevate the service mesh conversations to more broadly address application connectivity is underway. A service mesh, at its core, provides the means for integrating hundreds of application programming interfaces (APIs) at scale. It also provides a level of abstraction above the network layer that makes it easier to connect applications across a heterogeneous networking environment.

Kong is making a case for a lighter-weight approach that spans multiple platforms and is highly extensible. As such, third-party vendors and IT teams can add extensions to Kuma as they see fit.

Ultimately, Palladino said, the time has come to take cloud computing to the next level. If all organizations wind up doing is lifting and shifting monolithic applications to public clouds, an opportunity to advance the state of IT will have been lost.

Of course, it’s still early days as far as adoption of service meshes are concerned. Most organizations today are relying on API gateways, proxy software or ingress controllers to manage APIs. It’s not clear to what degree a service mesh may remove the need for some of that existing application connectivity middleware.

Regardless of which approach is ultimately favored, it’s apparent that, as microservices-based applications become more widely deployed, a different approach to application connectivity will be required. Monolithic applications, however, are not going away. In some cases, a monolithic application might be carved up into a smaller set of microservices, but it’s unlikely that every existing monolithic application will lend itself to that architecture any time soon.

March 9, 2021
How Open Source Software Powers Digital Innovation

Open source has permanently altered how we work and conduct business. Linux, and thousands of other open source projects and open standards, now dominate the software landscape, supporting emerging technologies like artificial intelligence and edge computing. Without open source, the DevOps tooling ecosystem would lack Docker, Kubernetes, service mesh, popular databases, and many CI/CD tools used by DevOps teams daily.

Now, more than ever, companies are searching for ways to meet escalating user demands. The pandemic has amplified this urgency, accelerating existing digital transformation initiatives. Arguably, open source is the engine that now powers the digital innovation required to compete. Leveraging open source could also help check rising cloud costs. With proprietary solutions falling out of favor, many enterprise leaders are adopting open source alternatives for infrastructure modernization and application development.

Red Hat recently released its third annual State of Enterprise Open Source report. The report surveyed 1,250 IT leaders worldwide on their open source adoption and usage patterns. The findings validate what most of us already know — open source is now fundamental to most technology stacks. Without it, most development projects would fall flat in an instant.

Open Source Use Cases

Open source is at the heart of modern software development. According to the report, 90% of enterprise IT leaders are using open source. So, where is open source being applied? Well, 64% of enterprises use open source software for IT infrastructure modernization. The report surmised that this could be due to Linux and open source infrastructure replacing proprietary systems.

The report also found 54% of enterprises use open source for application development. This is no surprise, as engineers routinely adopt open source libraries and packages to construct B2B and user-facing experiences. In a digital-only environment, applications are the lifeblood for many businesses, and open source is critical scaffolding.

The third top use case for enterprise open source is digital transformation, at 53%. This figure has increased by 11 percentage points in the last two years alone. Open source will likely continue to replace non-digital or manual processes with software-based, automated processes.

In the enterprise, open source is used in networking, adopted by 54% of enterprises, databases, at 53% and security, at 52%. Other areas mentioned in the report include big data analytics and cloud management tools.

In recent years, multi-cloud has become a notable trend. The idea is that organizations will seek out multiple cloud vendors to support different use cases. The Red Hat report confirmed that hypothesis, finding that 69% of respondents prefer to use multiple vendors for their cloud. As hybrid, multi-cloud setups profligate, cloud expertise and smart multi-cloud economic practices continue to gain importance.

Containers and K8s

Open source components are the foundation for containers and container management utilities. As reliance on containers grows, so will the dependence on open source technology. The report found just under half of enterprises now use containers in production. An additional 37% also use containers for development-only purposes.

To orchestrate these containers, IT teams have coalesced around Kubernetes. Sixty-six percent of respondents view Kubernetes as very or extremely important. As Kubernetes becomes ubiquitous, growth in container usage is slated to continue — about one in three respondents reported their container usage will increase significantly in the next 12 months.

“Kubernetes has become the de facto standard for Linux container development,” said Michael Hinterland, team lead, ICS cloud & automation and ICS system & middleware, Porsche Informatik.

While Kubernetes is flourishing, there are certainly variances across industries. For example, 62% of financial services and telecommunications respondents adopted containers in production, while other sectors, such as health care and retail, saw a lower adoption of containers in production, at 47% and 50%, respectively. The highly-regulated financial services sector also scored high on Database DevOps, a separate report recently concluded.

Open Source Benefits and Barriers

There are numerous benefits to using enterprise open source software. For one, a commitment to open source brings transparency and collaboration improvements. Respondents also cited higher quality software, access to the latest innovations and improved security as being among the top benefits to adopting open source software.

But open source has its drawbacks, too; 42% of tech leaders reported a lack of support as a top hurdle to enterprise open source adoption. This checks out – community-driven projects don’t typically offer traditional support systems. Without accessible frameworks for learning, creating a Center of Excellence at scale becomes difficult.

Other top barriers to enterprise open source adoption include compatibility, code security and a lack of internal skills. Introducing open source within an enterprise means upskilling the workforce and encouraging secure-by-default settings to avoid costly misconfigurations. It could also mean working with trusted allies that further open source initiatives, the report recommended.

Open Source Fuels Emerging Tech

“Open source has solidified itself as an innovation engine for the software industry,” wrote Paul Cormier, president and CEO, Red Hat.

Indeed, open source is at the heart of most cutting-edge emerging technologies. For example, 55% of respondents report using enterprise open source in edge computing and internet of things (IoT) settings. Simultaneously, 48% of respondents use open source for artificial intelligence and machine learning (AI/ML). Amid open source projects like OpenAI and GPT–3, AI is eating the software world, Forbes reported.

Both categories are slated to increase by nearly 20 percentage points in the next two years, whereas the use of proprietary solutions for AI/ML will decrease. Open source will continue to affect buying decisions, as 83% of IT leaders are more likely to choose a vendor that has contributed to the open source community.

Within a COVID-19-influenced world, “the problems are too big for one person, one company or one organization to solve,” said Cormier. “But it’s in moments like this where open source truly shows its power.”

March 8, 2021