Editorial Calendar for February 2016
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Denis Pushkarev is fed up with core-js freeloaders, and hundreds more malicious packages found at PyPI. (more…)
Fiberplane today announced it is extending the reach of a real-time collaboration notebook designed for DevOps teams by making available tools for building plug-ins based on the WebAssembly (Wasm) framework.
Micha Hernandez van Leuffen, Fiberplane CEO, said these plug-ins, dubbed providers, will make it much simpler for anyone to connect the Fiberplane notebook to other DevOps tools and platforms.
The Fiberplane notebook uses the same operational transformation algorithm used in Google Docs to enable teams to easily collaborate around a document or spreadsheet. The core platform itself is built in Rust and WebAssembly. That approach enables a DevOps team to, for example, write and run PromQL queries and display Prometheus charts alongside other data presented via an integrated graph. Wasm makes it possible to run those providers both in the browser and on a backend platform.
Fiberplane also announced it is open sourcing its Provider Development Kit (PDK), written in Rust, to enable organizations or third-party developers to create additional plug-ins. A Fiberplane Daemon then executes the plug-ins. The overall goal is to provide an open format based on Wasm for consuming DevOps data, noted Hernandez van Leuffen.
The full open source Fiberplane WebAssembly-based Plugin System includes a Fp-bindgen to provide the bindings generator for building plug-ins, the Provider Development Kit (PDK), a toolchain for building plug-ins, a set of pre-configured plug-ins for Prometheus, ElasticSearch, Sentry, Grafana Loki, Cloudwatch and a generic HTTP provider, the Fiberplane command line interface and the Fiberplane Daemon.
Fiberplane is essentially taking the concept of notebooks used for collaboration by data science teams and applying it to DevOps workflows. The goal is to improve DevOps teams’ productivity by reducing the amount of time it takes to sort through multiple types and classes of DevOps data to resolve an issue.
As IT environments become more distributed in the age of the cloud and microservices, troubleshooting issues now invariably spans the responsibilities of multiple members of an IT team. Fiberplane, in effect, makes it possible to spin up a virtual war room that enables the members of an IT organization to collaborate until the issue of the moment is resolved.
The speed at which any IT issue is resolved has become a crucial metric. Given the complexity of IT environments, it’s inevitable that incidents will arise. Ideally, IT teams would discover those issues before they disrupt the business. However, in reality, the metrics organizations use to evaluate the effectiveness of a DevOps team are often how quickly IT issues are resolved once they are discovered. The longer it takes for a distributed DevOps team to marshal its resources, the more likely it becomes that team will be perceived as being inefficient—regardless of what level of application availability is actually achieved.
Most DevOps teams have, of course, implemented a wide range of incident management best practices that create a level of muscle memory for responding to a wide range of issues. The trouble is there will always be unforeseen issues that arise. DevOps teams, as a result, need to find ways to quickly focus on an unpredictable issue that they didn’t anticipate.
A survey of 879 enterprise developers and architects from Vaadin, a provider of framework for building Java applications, found that, as part of modernization efforts, the pace at which Java applications are moving to the cloud is now accelerating.
The survey found more than one-third (36%) of Java applications are already deployed in the public cloud. More than half of respondents (56%) are also already deploying some of their Java applications into Kubernetes or serverless environments. Nearly two-thirds (63%) said they planned to move more Java applications to the cloud over the next 24 months, the survey also found.
Kim Weins, vice president of product and marketing at Vaadin, said the survey makes it clear that enterprise IT organizations are still highly committed to Java. Still, there is a clear shift underway in terms of where those applications are being deployed. More than a third of respondents (35%) said they have Java applications deployed on Amazon Web Services (AWS), while 22% have deployed them on the Microsoft Azure Cloud. Another 11% are running them on the Google cloud platform.
This shift, however, will take time. Almost half (47%) of Java applications still need modernization. As a result, 63% of respondents planned to increase their investments in modernizing existing Java applications.
Maintainability is the top-ranked motivation for modernizing Java applications (32%), followed by security (20%) and ongoing maintenance costs (10%), the survey found.
The top three challenges in developing Java applications are building an intuitive and simple user interface (81%), upgrading the tech stack (81%) and ensuring app security (78%).
There is also a shift underway in terms of the frameworks used to build and modernize applications using a more cloud-native approach. A full 70% of respondents use Spring today, but 50% also noted they are planning to increase their use of Spring Boot. Other Java frameworks used include Vaadin Flow, Quarkus, Hilla and React. While derivatives of Spring are the dominant framework, it appeared more organizations are at least evaluating other options, noted Weins.
Most organizations are also integrating Java applications with modern tools for logging (72%), observability (61%) and single sign-on (53%), the survey found.
The shift to Java 17 is also well underway, with nearly three-quarters of respondents (73%) using or planning to use it over the next year. More than a quarter (26%) are already on Java 17 or a later release. Another 21% are currently upgrading, while 26% plan to update in the next 12 months.
Overall, the survey found Java is being widely used for both internal (64%) and customer-facing (62%) applications. Java is most often used to build full-stack Java apps (70%) and backends (69%), the survey found
Finally, the survey found more than a third of respondents (38%) expected that finding and retaining developers would be a significant challenge in 2023.
There are, of course, no shortage of options when it comes to deploying Java applications. Most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a venerable programming language that itself has been modernized.
Quali today announced enhancements to its Torque automated infrastructure platform to add support for security scans and Open Policy Agent (OPA) software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).
OPA enables organizations to implement cybersecurity policies as code. The challenge many organizations have encountered is that not many developers have mastered the programming language required to implement OPA. Quali is embedding OPA in a platform that enables IT teams to implement it using a graphical tool that enables central management and application of those policies.
David Ben Shabat, vice president of research and development at Quali, said the overall goal is to implement scans and policies in a way that reduces the number of misconfigurations that are made when organizations provision infrastructure-as-code (IaC).
As part of that effort, Torque now flags any policies that fail validation. In addition, administrators can pick and choose which OPA policies to import, including both out-of-the-box and existing custom policies. Those policies then enable Torque to automate approvals or denials of deployments based on compliance with those policies after scans and other health checks have been run.
Quali has been making a case for policy-based triggers for cost controls, automated start-up, shut down and pausing of IT environments to give IT teams more control over infrastructure using a software-as-a-service (SaaS) platform. That approach enables IT teams to provide a set of guardrails for provisioning infrastructure that prevent mistakes from being made, noted Ben Shabat. Those controls can be applied using the graphical tool Quali provides or programmatically via an application programming interface (API) that Quali exposes, noted Ben Shabat.
It’s not uncommon for a port to be left open, for example, which cybercriminals later exploit to exfiltrate data. Quali is offering a DevOps platform that allows for central application of policies that act as guardrails to prevent developers from making these types of mistakes as an alternative to scripts created using tools such as Terraform. That approach also provides more visibility into how infrastructure resources are being consumed.
Every minute a developer spends managing infrastructure is one less minute they could be spending writing code. As application environments become more complex, it is becoming more challenging for developers to manage infrastructure-as-code. The issue is that DevOps teams who could provision infrastructure for developers are overwhelmed by the number of projects they need to manage. As a result, DevOps teams are becoming bottlenecks. Naturally, that only encourages more developers to provision infrastructure on their own, leading to more mistakes.
It’s not clear whether IT organizations will look for an alternative to provision infrastructure in a way that doesn’t require developers to have as much infrastructure expertise. However, as organizations look to lock down software supply chains, the way infrastructure is provisioned using code will, in many cases, need to be reconsidered within the context of a larger DevSecOps workflow.
A survey found that modernizing existing Java applications is a higher priority than other projects for 87% of respondents, with more than 80% of these applications expected to be re-engineered over the next five years. The survey polled 450 IT professionals working in organizations in the U.S. and United Kingdom that have more than 500 employees.
Conducted by the market research firm Vanson Bourne on behalf of Diffblue, a provider of a generative artificial intelligence (AI) platform for refactoring applications and generating unit tests, the survey also found enterprises plan to invest nearly half (45%) of their software development resources on modernization of existing applications versus developing new ones. A full 90% of respondents expected to rely on automation to accomplish those tasks, the survey found.
Specifically, survey respondents reported they planned to rely on automation to improve security (50%), increase development velocity (45%) and improve developer experience (42%). Well over half of respondents (58%) said they had already been working on these projects for more than 12 months.
If organizations don’t modernize Java applications, more than half of respondents (51%) said too much time would be spent on unproductive coding, while 50% said development velocity would be adversely affected. The biggest obstacles cited are choosing the right technical approach (45%) and securing budget (42%).
More than half of organizations (59%) have created a dedicated modernization budget to support their efforts. Nealy half (48%) said funds are being provided by business teams for projects, while 49% said general operating budgets have increased.
Diffblue CEO Matthew Lodge said it’s clear there is a huge commitment to application modernization. The reality is the majority of work IT teams do involves applications that have already been deployed. The challenge they face is that the effort required to modernize these applications is still far too dependent on manual processes, he added.
Overall, the survey found 96% of respondents considered Java applications extremely or very important to their organizations. On average, 65% reported additional Java applications are still being developed. Only 4% said they planned to migrate away from Java as part of a modernization effort.
Over half of the respondents expected to use Java 11 (53%) or Java 17 (56%) in their applications, compared to 19% using Java 8. More than a quarter (27%) expected to use a forthcoming Java 21 release. A full 100% expected to use the Spring framework to build these applications, with more than half (54%) planning to upgrade to the latest version that supports Java 17. A full 97% said unit testing is an “extremely” or “very important” element of their application modernization effort.
After experiencing something akin to a mid-life crisis, Java has itself been modernized with the release of Java 17, noted Lodge. The Java community is now adopting many concepts that may have been pioneered in other programming languages, he added.
Regardless of whether organizations are modernizing existing Java applications or writing new ones, the one thing that appears certain is the venerable programming language isn’t about to disappear any time soon.
Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey. Join us on May 4, 2023, to learn how to get started with DevOps—and how to do it right.
You’ll learn:
As organizations face increasing pressure to adapt faster and become more agile, getting DevOps right and adopting a DevOps mindset is crucial to deliver high-quality software faster and increase business value. And that opens up great opportunities for anyone looking to start a new career or pivot from an existing role in technology.
DevOps has become the standard of software development methodologies and it’s critical for successful digital transformation. Adopting DevOps—and doing it the right way—can benefit not only your organization but also your customers and end users by fostering innovation, reducing time to market, increasing development productivity, improving product quality and reliability and reducing costs.
That’s why many big companies, such as Amazon, Netflix, Facebook and many others have adopted a DevOps mindset—and DevOps practices. And as more businesses are looking to move to the cloud and transition into DevOps, there are plenty of job opportunities available for DevOps engineers at various levels.
DevOps is a growing field with a lot of opportunities for professional growth. According to a research study by Global Market Insights Inc., the DevOps market is expected to surpass $30 billion by 2028. Due to the high demand for skilled DevOps engineers and the shortage of qualified DevOps professionals in the industry, there is no better time to upskill than now.
Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey.
At DevOps Onramp Virtual Summit, taking place on May 4, 2023, you’ll get all the knowledge you need to get started with DevOps —and how to do it right. Join us to learn about DevOps best practices, processes and tools and get tips and tricks from experienced practitioners sharing their real-world experiences. We’ll go through the basics of DevOps, how to choose the right technologies, common challenges and the benefits of DevOps.
One thing is for sure: The future of DevOps is very promising. The rush has started—don’t be left behind!
If you’re interested in becoming a sponsor, please contact us. For more information, please visit the DevOps Onramp website.
Lineaje this week unfurled a platform for creating and managing the software bills of materials (SBOMs) that are increasingly mandated by enterprise IT organizations and government agencies.
Fresh from raising $7 million in seed funding, Lineaje CEO Javed Hasan said the SBOM360 platform provides a simpler way to manage all the SBOMs that will soon inundate organizations.
The SBOM360 platform makes it possible to use a search engine to discover all the components of an application and all the dependencies that exist within it, including vulnerabilities, and indicators of compromise (IOCs) in seconds, said Hasan. The company then adds fingerprinting technology that enables the platform to attest to the authenticity of the entire software supply chain, he added.
While there is no shortage of tools for creating SBOMs, there are not as many platforms that enable DevOps teams to both create and manage them. In the wake of an executive order issued by the Biden administration requiring federal agencies to have an SBOM for all the software they use, interest in SBOMs to better secure software supply chains has significantly increased. However, very few organizations have a process in place that enables them to operationalize all the SBOMs that might be created.
More challenging still, the pace at which software is being updated has accelerated to the point where many SBOMs are likely to be outdated. The only way to keep pace with that rate of change is to rely on a platform designed from the ground up to dynamically create SBOMs in seconds, noted Hasan.
Finally, IT organizations are now being held more accountable for legacy software often polluted with vulnerabilities that need to be remediated, he added. As such, organizations need a tool that makes it simpler to identify vulnerabilities within the context of an SBOM.
It’s not clear whether greater awareness of the need for SBOMs is translating into concrete action, but the expectation is that more organizations will soon be following the lead of the federal government by requiring them. That shift will naturally bring a lot of additional pressure to bear on DevOps teams. Historically, organizations tended to allow developers to aggregate software components without always checking to see if they are compromised. Cybercriminals are becoming increasingly more adept at injecting malware into software components in the hope that malware will find its way into any number of downstream applications.
Regardless of the approach an organization takes to better secure software supply chains, more rigor is being applied to how software is built and deployed. The days when developers were free to aggregate software components as they saw fit by, for example, relying on open source software downloaded from a repository, are now at an end. The expectation now is the developer will be held accountable for the integrity of all components used within an application as organizations move to implement additional processes to more rigorously review code before it is deployed in a production environment.
This week, flox launched a more opinionated implementation of the open source Nix framework that programmatically automates package management and system configuration.
Fresh from raising an additional $16.5 million in funding, flox CEO Ron Efroni said the company will also make an enterprise edition of its namesake flox framework available later this year.
The Nix framework has been available since 2003 and provides DevOps teams with a portable, fully isolated development, test and production environment along with a catalog and tools for managing software packages. There are more than 5,000 contributors to the platform, but Nix is based on a unique programming language that many DevOps teams have found challenging to master.
The flox framework provides a higher layer of abstraction for invoking Nix, and provides a set of guardrails to make the framework more accessible to a wider range of DevOps teams, said Efroni.
That approach will make it easier to share development environments and packages across teams, machines, individual developers and entire organizations. The framework also provides visibility into the software bill of materials (SBOM) for applications used in production environments to enable real-time vulnerability management and detection without scanning, noted Efroni. That capability makes it easier to discover dependencies spanning multiple architectures; many organizations today still try to track dependencies using spreadsheets and tools that don’t serve to make DevSecOps processes simpler to manage, he added.
It’s not clear how many organizations are using Nix today, but Efroni said that as software development management continues to become more complex across multiple platforms and architectures, there is a clear need for a different approach to enabling portability at scale. The biggest obstacle is overcoming the psychological biases many DevOps teams have developed toward Nix over the last two decades, he noted. A more opinionated framework should reduce the overall fear factor associated with Nix, noted Efroni.
Regardless of the frameworks employed, it’s become apparent that DevOps teams are struggling under the weight of all the code they must manage, much of it written in multiple programming languages. Many organizations that embraced DevOps early are now finding the platforms they deployed have become challenging to manage and maintain. As application environments become more complex, there is a need to modernize DevOps workflows. Less clear is whether those efforts might be focused on, for example, containers and serverless computing frameworks versus a framework such as flox that is designed to span multiple architectures and platforms.
It might be a while before IT organizations develop a unified approach to application development and deployment, given all the preferences of individual development teams. However, with the rise of platform engineering, it’s apparent more organizations are trying to strike a balance between developer freedom and the need to reduce the total cost of DevOps. That cost continues to rise as additional software architectures and platforms are employed.
In the meantime, flox plans to contribute to both Nix and its own more opinionated version of the framework in the hopes of one day making it easier to achieve that goal.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Alleged theft of GPL code, and Amazon will run its data centers on gas. (more…)
Cisco today announced a technology preview of a Cisco Full-Stack Observability Platform based on instances of open source OpenTelemetry agent software being advanced by the Cloud Native Computing Foundation (CNCF) to collect metrics, event, logs and distributed traces. The Cisco Full-Stack Observability platform will be available in June 2023.
The platform, announced at a Cisco Live EMEA event in Amsterdam, Netherlands, will combine the capabilities of multiple Cisco platforms and technologies into a single offering.
At the same time, the company also announced the bidirectional integration between its existing Cisco AppDynamics application life cycle management (ALM) tool and the Cisco ThousandEyes network monitoring platform beginning in April.
Finally, Cisco is making available a Business Risk Observability offering to provide business risk scoring. Business Risk Observability combines capabilities of its Kenna Risk Meter tool—gained when Cisco acquired Kenna Security in 2021—with the ability to monitor business transactions through Cisco AppDynamics to provide better visibility into application security. In addition, Cisco has integrated its Panoptica application programming interface (API) management security tool and the Talos threat intelligence platform within the Business Risk Observability Platform.
Carlos Pereira, a Cisco fellow and chief architect for strategy, incubation and applications at Cisco, said Cisco is moving to narrow the historic divide between application development and cybersecurity teams to enable organizations to adopt DevSecOps best practices and make it simpler to prioritize the remediation of vulnerabilities that are likely to have the most impact on the business.
Like most providers of observability platforms, Cisco is betting that more applications will be instrumented as OpenTelemetry software continues to mature. Cisco is now the single largest contributor to this project, noted Pereira.
OpenTelemetry will also play a critical role in improving application security as more applications become instrumented, he noted. In fact, a recent Cisco AppDynamics survey found more than three-quarters of respondents (76%) believed that DevSecOps is essential for organizations to effectively protect against a multi-stage security attack. However, only 43% reported their organization had started implementing DevSecOps workflows.
Observability, of course, has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that make it simple to investigate anomalies indicative of an issue that could disrupt an application environment. Most of those observability platforms are infusing those platforms with machine learning algorithms to surface those anomalies as part of an effort to augment the capabilities of a DevOps team.
Regardless of the approach to observability, many organizations will soon be trying to determine whether to rely on existing monitoring tools that make it possible to track pre-defined metrics. In some cases, there may still be a need for that legacy approach to managing IT. Still, in other instances, it may be possible to rationalize some of those platforms in favor of a more advanced approach that relies on a more advanced approach to achieving observability.