devopsy.kinsta.cloud

Tag: open source

observIQ Lauches Open Source Log Agent Project

Blue Medora, after selling its core monitoring integration platform to VMware, today changed its name to observIQ and launched an open source agent project that will serve as the foundation of a log management tool to be delivered as a software-as-a-service (SaaS) application.

Company CTO Mike Kelly said the observIQ agent, which is written in the Go programming language, will provide IT teams with access to highly configurable agent software that doesn’t adversely impact performance. In contrast, existing open source log agent software requires IT teams to sacrifice one for the other, he said.

Because the observIQ agent is highly configurable, it will also serve to make it easier to collect a wide range of metrics that can be consumed by a wide variety of management tools, Kelly added.

The company will employ observIQ to collect metrics for observIQ Cloud, a SaaS platform currently in beta, in addition to continuing to invest in BindPlane, an IT operations data management platform developed by Blue Medora that delivers a relationship-aware stream of metrics and logs in real-time.

Kelly said IT teams need access to a highly configurable agent software because the types of metrics that need to be collected continue to expand and evolve.

At the same time, Kelly notes IT teams need to be able to affordably instrument many more applications, which becomes difficult to achieve when relying on commercial agent software.

Finally, as IT environments become more complex, organizations are embracing best DevOps practices to manage applications, which requires organizations to increase dramatically the level of observability they have into any application environment. The issue DevOps teams encounter is they wind up having to support multiple agents, so if an open source project leads to fewer agents that need to be maintained and updated, that might be a benefit that resonates.

In the meantime, as log management heads into the cloud along with most other IT management services it’s also becoming easier for IT teams to manage applications from anywhere. Most IT teams are going to be working remotely much more often than they did prior to the onslaught of the COVID-19 pandemic. That transition is easier to achieve when the tools being relied on reside in the cloud.

Many IT teams also tend to limit their use of log analytics because of the costs associated with storing and collecting data. To limit those costs many IT organizations opt to only store log data for a limited time or only collect metrics for their most critical applications. The challenge is, the percentage of applications deemed critical continues to increase.

Of course, competition across providers of log management tools that can be accessed as a service is already fierce, so observIQ will have its work cut out establishing another platform. However, if DevOps teams adopt its open source agent software, there’s naturally a much higher chance organizations will wind up employing observIQ Cloud.

July 21, 2020
Google Exposes Old Wounds in Open Source Community
Things boiled over a bit last week with the announcement that Google launched the Open Usage Commons (OUC) consortium (see Mike Vizard’s article here). The announcement and subsequent angst it has caused has upset what had been a pretty stable environment that helped open source software become the dominant force in development and IT. While on its face OUC is about trademarks and usage guidelines, but make no mistake: This is about Google (and perhaps others) disagreeing with the management and direction of The Linux Foundation/Cloud Native Computing Foundation (CNCF).

Hand-in-hand with the OUC, Google also announced it was making changes in the board composition of the Istio project. A new formula based on code contributed by companies, as well as community seats selected by the community of other contributors, would determine who governs the project.

Together, this represents a clear bifurcation of managing the code of a project and the trademarks/IP of the project. This is not a new concept in open source, but in recent years has been seldom used. In probably the most famous example of this setup, Linus Torvalds controls a company that still owns the Linux mark, which the Linux Foundation manages it for him. It is separate from the Linux project itself, though.

The concept of the code being open and free while the project owners retaining the IP and trademarks was very much the norm in open source years ago. However, it led to many companies’ reluctance to contribute code to projects for which they had no say in the governance or usage of the marks. One of the benefits of the foundations such as CNCF, Cloud Foundry, Eclipse and others was that under their model, everyone had access to the same code base and mark usage rules. What you did on top of that was up to you. Ironically, this is the same argument we are hearing now regarding the changes to the Istio governing board and the OUC.

Perusing the Twittersphere on this subject turns up a few other issues that may be at play here:
- The CNCF and the Linux Foundation, by implication, may be a victim of its own success. The amount of money they have generated and their “marketing” profile seems to have turned some people off.
- The CNCF/Linux Foundation model of allowing major corporate contributors to, in essence, buy board seats and having just a minority of “at large” seats open to the community favors the big, rich vendors over the rest of the pack.
- New leadership at Google and Google Cloud are having second thoughts about turning over the fruits of their work to foundations that they eventually lose control over. Recent former Oracle management is being rumored behind this, though that is not confirmed. In this scenario, second doubts about Kubernetes and other Google-donated projects that are now out in the market without a Google edge are causing them to rethink their approach.
- Companies that rely on these open source projects and historically are decent corporate members, such as IBM, have been caught in the open here as evidenced by their reaction to the Istio affair.
What I do know is that the loser in all of this will be the community. Open source works best when there are stability and predictability over its future and governance. The broader the base of management and ownership of a project, the more willing corporate contributors are to participate and contribute. I would hate to see us return to the maze of the Cathedral and the Bazaar. I sincerely hope we are not seeing the end of the golden age of open source software.
July 15, 2020
How to Source Vulnerability Data for True DevSecOps

Open source comes with code vulnerabilities that must be considered in the DevOps process

The war between open source and “only proprietary code” is long over. Open source won the day by convincing the opposition of the benefits of joining the open source community. “Vulnerabilities in the Core,” a report published by the Linux Foundation and the Laboratory for Innovation Science at Harvard in early 2020, explained: “Open source has now become an integral component of the modern economy and is a fundamental building block of everyday technologies like smart phones, cars, the Internet of Things, and numerous pieces of critical infrastructure.”

Development teams have embraced open source for its inherent strengths: efficiency, speed, quality and innovation. As one Gartner report puts it, “In most modern DevOps development projects, the majority of code used in an application is made up of open source.”

But open source comes with code management responsibilities that DevOps teams need to consider. Open source has the same security risks that plague all software—bugs or other defects that could be exploited by hackers. While larger open source projects have communities that generally issue patches for vulnerabilities much more quickly than commercial vendors, thanks to thousands of “eyes” on the code, keeping open source software secure is not as simple as enabling auto-updates, as is done for much commercial software.

Unlike commercial vendors that automatically “push” patches out to users, open source operates on a “pull” model. As patches are made available, consumers of the open source component first need to be aware that the patch is out there and then “pull” it from a repository to accomplish the needed update.

The NVD and Its Timeliness Problem

Public sources such as the National Vulnerability Database (NVD) are a good first step for information on publicly disclosed vulnerabilities in open source software. However, you need to keep in mind that there can be significant lags in data reporting, scoring and actionability of the data in an NVD common vulnerabilities and exposures (CVE) entry, with some research reporting an average 27 days between the initial announcement and NVD publication. The format of NVD records also makes it difficult to determine which versions of any given open source component are affected by a vulnerability.

For example, the Linux vulnerability CVE-2016-5195, popularly known as Dirty Cow, was announced Oct. 19, 2016. Proof-of-concept code exploiting the vulnerability was available a full two weeks before the Nov. 10 listing for the CVE in the National Vulnerability Database. That’s two weeks in which anyone relying on the NVD would have been left in the cold.

The problem is more recently reflected in the findings of the 2020 Open Source Security and Risk Analysis (OSSRA) report, produced by the Synopsys Cybersecurity Research Center (CyRC). Four of the top 10 vulnerabilities found in the audited codebases did not have CVEs associated with them at the time of the report’s publication. The vulnerabilities without CVEs included high-severity flaws in jQuery and FileAPI. Those security issues can be fixed with updates of the respective open source components, as can the majority of vulnerabilities listed in the CyRC OSSRA report. But, to patch any of those CVE-less vulnerabilities, you first need to be aware of them.

The issues impacting the NVD’s ability to publicize security vulnerabilities make it unwise to rely solely on that organization for vulnerability information. While I’m not recommending abandoning the NVD, DevOps teams should look to a secondary source of information that will provide better notification of vulnerabilities affecting your codebase and, ideally, supplement notifications with technical details and upgrade and patch guidance.

Augmenting NVD Vulnerability Information

Many commercial software composition analysis (SCA) solutions can provide you with more timely, richer vulnerability data than the NVD alone, proactively finding issues and helping you fix them quickly when warranted. If you’re considering an SCA solution, you should ask your vendor what they offer in the form of security advisories and alerts.

For example, consider the Common Vulnerability Scoring System (CVSS), an industry standard for assessing the severity of a vulnerability. The CVSS score (v2 and v3) provides an overall base score that takes both exploitability and impact into account.

A robust SCA solution will provide a temporal score in addition to the CVSS base, exploitability and impact scores. Temporal scores take into account metrics that change over time owing to events that are external to the vulnerability. Remediation levels (“Is there an official fix available?”) and report confidence (“Is the report confirmed?”) can help temper the overall CVSS score to an appropriate level of risk.

Similarly, an SCA solution should offer key Common Weakness Enumeration (CWE) classifications—a list of software or hardware weaknesses that have security ramifications—for all vulnerabilities, providing insight into the type of weakness being exposed. A CWE classification tells developers which type of weakness leads to the vulnerability in question.

Information such as this can help you understand what you’re dealing with and aids in assessing the severity of the vulnerability for mitigation purposes. For example, a development team may prioritize a SQL injection differently than a buffer overflow or denial of service.

July 14, 2020
DevOps Deeper Dive: Google Roils Open Source Community

Google this week agitated the bulk of the open source community by launching the Open Usage Commons consortium to protect the trademarks of open source projects, starting with the Istio, Angular and Gerrit projects it launched.

Launched in collaboration with SADA Systems and some independent contributors, the stated goal of the Open Usage Commons is to help open source projects assert and manage their project identity through programs specific to trademark management and conformance testing.

Istio is a service mesh that runs on top of Kubernetes, while Angular is a web application framework. Gerrit is a code collaboration tool.

Unlike previous open source projects that Google played a major role in developing such as Kubernetes, Google has yet to contribute these three projects to an open source consortium. That decision has members of the open source community now questioning Google’s commitment to open source software.

In fact, IBM, which launched the Istio project in collaboration with Google, this week said the Open Usage Commons does not meet the level of open source governance IBM expects. Originally, IBM said the expectation was that Istio would be contributed to the CNCF once it achieved a level of maturity. That contribution would include Istio intellectual property and the trademark. Now IBM is encouraging Google to reconsider its Open Usage Commons approach.

If Google continues to hold on to the intellectual property rights for open source projects such as Istio, those projects will become little more than a community project that Google exercises control over, said Priyanka Sharma, general manager of the Cloud Native Computing Foundation (CNCF), which oversees the ongoing development of Kubernetes, among other open source projects.

“It’s not in the spirit of open source,” said Sharma. “I don’t think you can even call it open source.”

Other open source initiatives will be hesitant to build on top of projects such as Istio if the intellectual property belongs to a single vendor, added Chip Childers, executive director of the Cloud Foundry Foundation (CFF). The trademark is never the main issue, he said.

“The trademark is only part of the consideration,” said Childers.

In the case of Istio, the decision to launch Open Usage Commons might also draw more attention to a Service Mesh Interface (SMI) project being advanced under the auspices of the CNCF. That interface promises to make it easier to rip and replace one service mesh for another.

In the meantime, Google may be trying to maximize its investments in open source projects that until now have tended to benefit rivals more. In terms of consumption of cloud services based on Kubernetes, Google is a distant third at best to Amazon Web Services and Microsoft.

In general, there are more open source projects than ever. However, some of the entities that launch those projects have complained that cloud service providers simply turn those projects into cloud services in a way that consumes most of the revenue opportunities any open source project might generate.

Google now appears to be exacerbating those tensions further by trying to retain control over the open source project it leads, while selling services based on other open source software projects. It’s not clear to what degree this rift might drive a wedge between multiple open source factions. Google with this move may just drive more members of the open source community into the arms of AWS and Microsoft. However, for the moment at least, none of the projects covered by the Open Usage Commons trademarks are so critical that they could not be replaced by any one of several alternative projects that are truly open source.

July 10, 2020
CNCF Looks to Increase Open Source Sandbox Projects

The Cloud Native Computing Foundation (CNCF) today announced it has simplified the process it employs to enable open source software to become a sandbox project managed under its auspices.

Priyanka Sharma, general manager for the CNCF, said the organization is looking to increase the number of open source projects that make up the cloud-native ecosystem. While the CNCF is best known for its efforts to govern the development of Kubernetes, the organization’s mission spans a wide range of cloud-native technologies. Many of those projects are now applicable to both microservices-based and monolithic applications that can be deployed in the cloud or in an on-premises IT environment.

Key changes to the sandbox process include a simplified submission process using an application that asks the project owners how their project fits as part of the cloud-native ecosystem. Applications are listed in a spreadsheet available publicly for comment, with review by the Technical Oversight Committee (TOC) scheduled on a bi-monthly cadence. The existing Special Interest Group (SIG) recommendation and TOC sponsorship requirements for sandbox projects have been replaced by a simple vote for acceptance by the TOC.

There are currently 31 sandbox projects being developed under the auspices of the CNCF. The new process for approving sandbox projects has already been applied to 11 of them. Each sandbox project has signed over the rights to the intellectual property for that project to the CNCF, which then attempts to attract more developers to participate in the ongoing effort to increase the adoption of that project.

In some cases, CNCF projects will compete with one another for acceptance. The CNCF is committed to not becoming a “king maker,” said Sharma.

Obviously, the CNCF is not the only organization trying to advance the adoption of open source software. In addition to The Linux Foundation, of which the CNCF is a part, there are older organizations such as the OpenStack Foundation and the Eclipse Foundation, which, to varying degrees, compete with one another to become the entity through which open source projects are governed.

The number of open source projects being launched has increased exponentially in recent years as IT vendors transform their business models. Many now contribute their core software to an open source project in the expectation that increased adoption will lead to demand for commercial support services.

That shift in many ways has led to a change in terms of how innovative software is brought to market. Not too long ago open source software was viewed primarily as a way to create the free equivalent of an existing operating system or database. Today, the bulk of emerging software in the enterprise starts out as open source projects.

Much of that transition began when more IT organizations adopted “open source first” approaches to IT in the wake of the economic downturn that began in 2008. As the current downturn brought on by the COVID-19 pandemic deepens, it’s probable the preference for open source software is only going to increase in the months and years ahead.

July 8, 2020
Kong Donates Kuma Service Mesh to the CNCF

The Cloud Native Computing Foundation (CNCF) announced today it has accepted the open source Kuma service mesh developed by Kong as a sandbox level project.

At the same time, Kong announced an update to the service mesh for monolithic and microservices-based applications that makes it easier to deploy multi-tenant instances of Kuma across multiple types of networking environments.

A service mesh provides a layer of abstraction across networking environments that simplifies the deployment of distributed applications. Rather than having to manually configure each application service for a specific network, the service mesh automatically routes application traffic across multiple network underlays.

Kuma is based on Envoy, an open source proxy server developed under the auspices of the CNCF. Kuma will be the second service mesh project that CNCF has accepted after Linkerd. However, Linkerd is not based on Envoy, so the CNCF is adding another service mesh project.

Kong CTO Marco Palladino said Envoy provides an opportunity to create a lighter-weight service mesh that is easier to deploy across a distributed computing environment.

Arguably, the best-known instance of a service mesh is Istio, which was developed by Google, IBM and Lyft for Kubernetes clusters. Istio, however, is complex to deploy and manage, and it hasn’t come under the auspices of any open source consortium.

Palladino said given the popularity of Envoy, it only makes sense to add a service mesh that is both lighter-weight, scales better and is more extensible. For example, the latest release of Kuma adds support for global/remote control plane replication across hundreds of thousands of data plane proxies, he said.

Also added was an ingress data plane mode that automates cross-platform and cross-cluster service mesh communication and a native universal DNS service discovery application programming interface (API) that makes it appear multiple services are all sharing the same cluster.

As a sandbox-level project managed by the CNCF, Kong is now inviting other organizations to contribute to the development of the Kuma service. It remains to be seen which service meshes will eventually gain broad support. In addition to Kuma, Istio and Linkerd, the open source Consul service mesh from HashiCorp is vying for support. There are other proxy servers as well, such as NGINX, on which service meshes can be constructed.

Very few IT organizations have deployed any type of service mesh in a production environment. However, as the number of microservices being deployed steadily increases, IT organizations need an easier way to enable applications to invoke network resources. Kuma provides a service mesh to address that issue that can be employed by both emerging microservices-based applications and legacy monolithic applications.

Kuma also makes it possible to more easily secure traffic, establish service connectivity permissions and capture metrics using a combination of routing rules that can be set using APIs, says Palladino. It also comes with out-of-the-box policies for the most common service mesh use cases.

Service meshes should also play a major role in the eventual convergence of network operations (NetOps) and best DevOps practices. Network specialists still will be needed to deploy the physical network underlay. However, network services themselves are becoming a virtual abstraction that developers can invoke within the parameters of policies defined by a central IT organization.

The challenge now is advancing service mesh platforms to the point where the average enterprise IT team is capable of deploying and managing them.

June 30, 2020
Red Hat Extends Reach of Ansible Automation Framework

Red Hat this week launched a collection of downloadable workflows for automating IT processes that will be made available via the Ansible Automation Hub.

At the same time, Red Hat has updated the Red Hat Ansible Automation Platform to add an automation services catalog to keep track of workflows and a return on investment (ROI) calculator that enables IT teams to determine which workflows are the most valuable based on usage.

Red Hat also updated the core Red Hat Ansible Tower automation engine to streamline processes and reduce bottlenecks.

Tom Anderson, vice president for the Red Hat Ansible Automation Platform at Red Hat, said Red Hat Certified Ansible Content Collections includes workflows from Red Hat and vetted third-party providers. As such, IT teams employing Ansible to automate the management of IT can have confidence these playbooks and workflows are both secure and supported, he said.

Red Hat decided to separate the management of Ansible workflow content from the underlying platform because it’s become apparent new workflows are being made available at a faster cadence than updates to the core Red Hat Ansible Automation Platform, he noted.

As part of that effort, Red Hat this week is also making available additional automated workflows that leverage Red Hat Tower to automate tasks and jobs via a centralized console, along with workflows that leverage Red Hat Satellite systems management software and the Red Hat Insights monitoring service.

Anderson said interest in IT automation has expanded significantly in the wake of the economic downturn brought on by the COVID-19 pandemic. Many organizations have either frozen IT headcount or been forced to reduce the size of their IT staff. However, managing IT environments continues to grow more complex as emerging technologies such as microservices and Kubernetes clusters gain momentum.

Some organizations may, of course, opt to put a hold on adopting new platforms, but just as many are continuing to invest in cloud-native technologies necessary to drive digital business transformation initiatives, which require applications that are both more flexible and resilient. Because of that, Anderson said, the urgency surrounding IT automation project has increased.

In fact, he noted, Red Hat has created “office hours” during which the company provides IT teams with access to Red Hat personnel at specific times to provide additional guidance.

As an open source project, Ansible is gaining traction as a management framework because it provides a declarative approach to automating IT that doesn’t require IT operations teams to learn how to code. Ansible is also being embraced by IT infrastructure providers including Cisco Systems and Dell Technologies, which makes it easier for IT teams to create playbooks that automate tasks across multiple platforms. Over time, those cross-platform capabilities foster the creation of an ecosystem that further increases Ansible momentum, Anderson noted.

There’s no doubt IT teams were increasing their reliance on IT automation frameworks prior to the pandemic. Now, however, automating the management of IT is not just about increasing productivity and efficiency; in many cases, it’s become a matter of survival.

June 26, 2020
Snyk Report Finds Decline in Open Source Vulnerabilities

Snyk, a provider of tools for discovering and remediating vulnerabilities in open source code, today published a report that finds the number of new vulnerabilities discovered in open source software packages has declined 20% on a year-over-year basis. However, the bulk of the vulnerabilities being discovered are considered to be high severity, the report finds.

Alyssa Miller, application security advocate for Snyk, said the decline represents a significant improvement as developers become more conscious of cybersecurity issues. As long as humans write code there will always be security issues; however, Miller said the latest report suggests improvements in open source security are likely to continue as more developers embed vulnerability scanning tools within their application development tools.

Those tools enable developers to discover vulnerabilities in their code long before they ever find their way into a production environment, she noted.

The Snyk report is based on a survey of 500 developers, security practitioners and IT operations staff and scans run by Snyk on open source software packages. It finds the top vulnerability currently impacting scanned projects is prototype pollution, which results in objects in JavaScript applications being modified, was found in nearly 27% of all the projects Snyk surveyed.

Better-known vulnerabilities, such as cross-site scripting attacks, are still being reported in high numbers, but Snyk reported the number of projects actually being impacted by this class of vulnerabilities is fairly low. These threats appear to be getting caught and remediated much earlier than many lesser-known vulnerabilities, said Miller.

Want to learn more? Tune in Tuesday, June 30, at 11 a.m. Eastern for The State of Open Source Security in DevSecOps Pipelines: A Panel Discussion, a devopsy.kinsta.cloud webinar hosted by Snyk

The report notes the bulk of the vulnerabilities discovered continue to involve indirect dependencies (70%) within packages built using tools such as Node Package Manager (86%), Ruby (81%) and Java (74%). The survey also finds 60% of organizations do not fully inventory the dependency trees in their software.

Despite the progress being made, Miller said it’s clear much work needs to be done. For example, the survey finds more than 30% do not review Kubernetes manifests for insecure configurations. Requirements for security-related resource controls in Kubernetes are also not widely implemented, according to the survey. Many container images labeled as final contain large numbers of known vulnerabilities—the 14.3 Node image had 642 known vulnerabilities, for example.

In addition, 44% of the participants indicated that they are currently using Kubernetes to orchestrate their containers. Many respondents who said they use Kubernetes also employ Helm to package applications (40%). According to the report, 68% of stable Helm Charts contain an image with a high severity vulnerability.

Ironically, Miller noted many of the same vulnerability issues that have derailed many “golden image” initiatives in the past decade appear to be manifesting themselves again in the age of containers.

Finally, the survey finds 57% of respondents have implemented static code analysis tools (SAST), followed by employing security test cases during quality assurance (28%); dynamic application security testing (DAST) (20%); software composition analysis (19%); and threat modeling (19%).

Despite that relatively low reliance on security tools in the development process, it’s clear progress is being made as DevOps teams and cybersecurity teams collaborate more closely. As more security tools are incorporated into the DevOps pipeline, application security should begin to improve at even faster rates.

June 25, 2020
SaltStack Looks to Automate DevSecOps Processes

SaltStack announced today it has integrated its automation framework with a variety of third-party security platforms to further the adoption of best DevSecOps processes.

Mehul Revankar, director of product management for SaltStack, said version 6.3 of SaltStack Enterprise provides integration with offerings from Splunk, Tenable, Qualys, Rapid7 and Kenna Security. Data generated from vulnerability scans conducted using tools from Tenable, Qualys and Rapid7 can be directly imported into SaltStack Enterprise to inform automated DevSecOps processes, while integration with Kenna Security makes it easier to automate and prioritize vulnerability remediation based on the level of risk.

Revankar said that latter capability is crucial because remediation efforts should not be prioritized based on the severity of a vulnerability alone. For example, a vulnerability may be discovered in an application that sits behind a firewall, but if that application doesn’t provide access to the web an organization may decide to not patch that vulnerability immediately regardless of its severity because the risk of a breach is still relatively low, he said.

These capabilities will enable SaltStack Enterprise to serve as a foundation for providing security orchestration, automation and response (SOAR) capabilities within the context of a DevSecOps process by making it easier to incorporate cybersecurity within the context of a larger playbook for automating the management of IT, he added.

Most of those playbooks will be developed by DevOps teams in collaboration with cybersecurity professionals, noted Revankar.

In addition to improving DevSecOps processes, SaltStack hopes to make it easier for external applications such as Splunk and Datadog to consume data generated by its framework by providing compatibility with Prometheus, an open source IT monitoring tool developed under the auspices of the Cloud Native Computing Foundation (CNCF). A SaltStack Enterprise Splunk add-on tool has been added to the Splunkbase repository.

SaltStack is also making available a performance and health dashboard to enable DevOps teams to track 25 SaltStack Enterprise metrics that are surfaced using the Prometheus data format.

The open source Salt framework on which SaltStack Enterprise is based has emerged as a popular option for automating IT processes. Because it is based on Python, the barrier to adoption for Salt in terms of programming expertise is comparatively low to other programming languages. As such, more IT operations teams have been inclined to learn Python to leverage Salt to automate processes.

Like most vendors that have adopted open source business model, SaltStack extends the capabilities of Salt via an enterprise edition that it both extends and provides commercial support.

Interest in IT automation is on the rise as organizations of all sizes look to maximize what limited cybersecurity resources they have and cut costs. IT automation in the form of SOAR presents an opportunity to consistently apply cybersecurity policies more broadly without having to increase the size of the IT organization.

The challenge, of course, is having the expertise required to build a playbook. In the case of open source frameworks, many of those playbooks are shared among the members of a community such as Salt. Regardless of how those playbooks are acquired, it’s clear that as IT becomes increasingly more complex most IT organizations are not going to be to do without them.

June 25, 2020
Eclipse Foundation Touts Jakarta Progress

The Eclipse Foundation today published the results of survey of 2,180 software developers that finds over half of respondents (55%) have adopted Java/Jakarta EE 8.

In addition, the Eclipse Foundation is making available an update to the Jakarta Enterprise Edition (EE) specification that will move away from the javax namespace to embrace jakarta namespaces for all components.

Jakarta EE 8 is essentially Java EE 8, which Oracle agreed would become open source software when it transferred ownership last year to the Eclipse Foundation. The transition from Java EE to Jakarta nomenclature remains a work in process.

The Eclipse Foundation finds the use of Java technologies is in a state of flux across the board. For example, adoption of Java 11 now stands at 28%, while Java 14 adoption is at 11%, according to the survey. That compares to 64% that are still employing Java 8.

Spring/Spring Boot at 44% adoption continues to be the leading framework for building cloud-native applications, compared to 35% using Jakarta EE and 16% for Red Hat Quarkus, a framework that runs natively on Kubernetes.

Usage of Eclipse Che, an open source integrated development environment (IDE) for building applications on Kubernetes, now stands at 11%, the survey also finds.

Mike Milinkovich, executive director of the Eclipse Foundation, said it’s clear organizations are now employing multiple frameworks to build Java applications, given a 13% drop in reliance on Spring/Spring Boot from last year’s survey results.

However, the survey also finds that overall, the use of Java to build microservice applications has declined to 39% from 43% during the same period. That drop may reflect both the complexity of building microservices-based applications, given the fact that 25% of survey respondents said they are using Java to build monolithic applications, said Milinkovich.

At the same time, some organizations may be opting to lift and shift existing monolithic Java applications into the cloud in response to the COVID-19 pandemic, he said, noting once redeployed, those organizations may then opt to modernize those applications using microservices.

With access to many local data centers limited during the pandemic, many organizations may have decided the most prudent option was to lift and shift Java applications as they are than re-engineer them first, he added.

There are currently 12 frameworks officially that are compatible with Jakarta EE 8, which Milinkovich said is indicative of the continued relevance of Java technologies for building applications both inside and out of the cloud. Now that Java is available as open source software, the level of innovation surrounding Java platforms will also accelerate, he said.

There is still a large base of developers that rely on Java and by extension Jakarta to build enterprise applications. However, IT organizations now routinely employ a wide range of programming languages and platforms to build applications. Java is still the most dominant when it comes to building backend applications; however, many organizations are still evaluating their options when it comes to building cloud-native applications on platforms such as Kubernetes.

Java in all its forms will, of course, be around for a long time to come. The only real question is how much organizations will continue to rely on it, in an IT world that continues to transform.

June 23, 2020