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: CSS-Tricks gets bought by DigitalOcean, Peloton pedals while its business burns, and Arm lays off up to 15% of staff. (more…)
Measuring and mitigating the security risks in open source software is becoming a major issue in the software development community. Attacks on open source software (OSS) are on the rise; open source supply chain attacks grew 650% in 2021—a staggering number.
2021 and early 2022 saw significant attacks which impacted more than 1,000 organizations. The most prominent recent OSS attack was the Log4Shell vulnerability disclosed in December 2021. Attacks on the OSS supply chain and on OSS impacted nearly every single software organization on the planet. Everybody is scrambling to continuously patch systems as new vulnerabilities continue pouring in.
To properly navigate this environment and keep our systems safe, we as a community need to understand the security risks of OSS and be better prepared to handle them, collectively and individually.
There are a number of risks that make OSS more vulnerable without proper security measures.
To start, we must recognize that open source software may be free to download and require no payment, but it comes with a massive security cost.
A significant portion of open source software is developed by volunteers in their free time. Most of the prominent open source volunteers actually have full-time jobs, and the code they contribute to projects like the Log4j logging libraries are written on nights and weekends; on their own time and not on the company dime. Not surprisingly, security isn’t high on their priority list. They don’t have the resources to invest in a secure development life cycle or have the time and bandwidth to maintain their code. This may mean that security vulnerabilities remain unaddressed for long periods of time, sometimes indefinitely.
In software development, Linus’s law states “…given enough eyeballs, all bugs are shallow.” However, this is only true if those eyes are looking in the right place. In the case of open source, all code is open but there aren’t enough eyes paying attention to it to spot all the bugs. In addition, organizations may not consider the security consequences of their decision to consume a particular piece of open source software and adding it as a dependency. Dependency trees become more and more complex; harder and harder to monitor and secure, as you keep adding more third-party components to a core codebase. Each new dependency might bring additional nested dependencies—perhaps hundreds or thousands, depending on the size of the library added or the role it plays in the application architecture. For example, the Kubernetes project—one of the most successful and widely adopted OSS projects—has several thousand dependencies, many of which have additional secondary and tertiary downstream dependencies.
The beauty of the open source ecosystem is that there is a solution for everything. The problem with the open source ecosystem is that there’s not just one solution, but several dozen. For example, if you need a JSON parser for your application, there are several to choose from. If your application is running a critical service or infrastructure, then picking the right JSON parser—one that is secure and comes from a responsible project or maintainer—becomes very important. A JSON parser will serve as a critical component for your application, so it will impact the security of your entire system. If you chose the wrong JSON parser, you might pay a big price down the road in security risk and subsequent breaches.
One potential solution to enhance OSS code security is the creation and implementation of a security risk assessment gate as part of your OSS ingestion pipeline. Putting this process in place will help you understand whether consuming a certain piece of software is high risk and avoid software that does not meet your risk criteria.
Here is an example of how this might work. Consider five different JSON parser libraries in GitHub, all of which have a high number of stars and appear to be highly rated. How can we assess the risk of these libraries and quickly and easily eliminate ones that are too risky? One of these JSON libraries is hosted under a user account. Most of the commits are done by a single developer without reviews. This alone indicates that using this library in a critical system presents a high risk. This lone developer could commit malicious code without review. The maintainer’s token access could be leaked, allowing attackers to insert malicious code. The developer might also turn over committer control of their library to a malicious actor without notifying users (who might not pay attention to the notification anyway). Identifying this risk required no more than a few minutes of review of the repository and cost little in time or effort.
More broadly, we need to understand the full security posture of an organization or developer and their open source code prior to adding it to critical systems. Because OSS is a complex ecosystem and many pieces of OSS are complex, the risks they generate are similarly complex. Our traditional, myopic view of these risks is that we just need to find all the security vulnerabilities in our codebase and fix them. This does not resolve all risks and may lull us into a false sense of security.
We need to understand the full comprehensive security posture of an open source project. That involves understanding a broad range of risks beyond code vulnerabilities. Here are some of the key risks to consider beyond ensuring that your codebase is well-secured and patched.
Supply Chain Attacks on the Build Pipeline
Attacks like SolarWinds and CodeCove taught us that supply chain risk is a very big deal and that tools are just as much at risk as code. Attackers have found it much easier and much more reliable to attack build pipelines, rather than finding vulnerabilities in code.
Security Risks Revealed by Continuous Security Testing
Continuous security testing is critical to maintaining the security of a codebase. There might not be code vulnerabilities today, but as developers continuously modify code and iterate on applications, vulnerabilities may be introduced. This can mean testing code as part of the CI/CD process with every new code push. For example, we have found numerous critical bugs in OpenSSL libraries. All were caught on a master or main branch and never made it to a production release.
Project Maintenance and Capabilities
One of the really big risks with open source is the quality and frequency of project maintenance. Issues raised may not be addressed in a timely fashion. Maintainers of a project may have a long backlog of issues, indicating that they are not actively maintaining a project. It is not uncommon for critical open source projects used in millions of applications and comprising a significant dependency to the global software supply chain to not have been updated in a year or more. In addition, maintainers of OSS projects may not know how to respond to security incidents and fix security vulnerabilities. This is particularly true if the maintainers do not work at a large organization, do not have cybersecurity or secure development experience or have never suffered through the toil and trauma of addressing a major vulnerability in their code on short notice.
A number of efforts are underway to create free tools to help developers and application security teams better measure and address supply chain risk programmatically and analytically.
As a tool to help organizations better address software supply chain risks, Google created a novel framework that we call Supply Chain Level for Software Artifacts (SLSA). The project has been underway at Google for more than a decade and has been open sourced as part of the OSSF. Contributors include VMware, Citibank and Datadog, among others. Google hopes to standardize SLSA and make it an industry benchmark for evaluating supply chain risk. Right now, SLSA is focused primarily on build process risks but the hope is to expand it in the near future to other areas, such as vulnerability and maintainer risks.
In order to scale the process of assessing, identifying and mitigating risks in OSS, we need robust automation. In 2020, as part of the OSSF, Google released a new project called Open Source Security Scorecard. The project aimed to automate the analysis and trust aspect when evaluating the security posture of open source code. Further, the Scorecards can provide specific security recommendations. The Scorecard process can incorporate many other automated tools, including checking against vulnerabilities using the Open Source Vulnerability (OSV) database and running dependency checks using open source dependency trackers like Dependabot. The scorecards project also makes it easier to report new vulnerabilities and get those to the right people in a project.
No one denies that OSS has become crucial to the vast majority of applications running the world’s technology foundation. The span of OSS continues to grow, as more and more languages and frameworks emerge and specialization increases. No one wants to reinvent the wheel and rewrite fresh code to perform the same tasks with every new application. The model of reuse, dependency and distributed software development works and speeds innovation. That said, the open source community and the supply chain used to build OSS need a more rigorous approach to reducing risk. Given the scope of the problem, automation and standardization are helping to scale toward the stated goal. We are in the early stages of creating the tools and infrastructure to automate the risk identification, measurement, assessment and mitigation processes. Security frameworks like SLSA and new processes like entry gating new OSS code with security scorecards will direct organizations down that path and move us toward a more secure open source future.
About Secure Software Summit
The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.
https://go.shiftleft.io/secure-software-summit-2022-replay
Last year, the Linux kernel turned 30. If you’re someone who’s been immersed in the Linux world since Y2K like I am, it may feel a bit surreal that so much time has passed since the kernel’s inception.
As a training architect at A Cloud Guru (ACG), I teach courses about all things Linux and specialize in hands-on lab-based learning. Before joining ACG, I worked as a Unix systems engineer at GE and IBM as well as a technical account manager and customer advocate for Red Hat. I’m hugely passionate about Linux, just as so many other engineers and enthusiasts are, not just because of its importance to our careers but its impact overall.
In its 30 years of existence, the Linux kernel has had a massive impact on the modern computing landscape—revolutionizing what’s possible for operating systems and allowing countless tinkerers to get their hands dirty in the process. Linux has also become the foundation of paradigm-shifting innovations over the years due to its ever-evolving nature.
Here are some of the key reasons why the kernel is so valuable and why it will continue to be a major player in the computing landscape for years to come.
My first exposure to Linux was in college in 1999. I took an introductory Unix Shell Scripting class and Fedora was installed on the lab servers because it was free and easily scalable. I view Linux as my entry point into customizable operating systems. After learning basic Unix commands on Linux, I ultimately went on to pursue a career supporting multiple commercial Unix vendors.
As Linux made its way into larger enterprise-level companies, I quickly returned to working with Linux distributions. Something I’ve always loved about Linux is the capacity to fine-tune your system to support the applications and distros that work best for your projects. Linux improves the functionality of whatever applications you’re running. The Linux kernel has literally changed how the world processes information, which is why I’m so invested in the software.
Now, it’s my job to share my knowledge and passion for Linux with other technologists. At ACG, I develop courses to help aspiring Linux experts learn how to optimize their systems. Additionally, I contribute to Linux this Month, an ACG-hosted web series that provides monthly updates from the global Linux community.
The fact that I am able to build a career around teaching Linux and staying up-to-date with Linux news shows the vast use cases and applications of the kernel. What makes Linux so unique and evergreen is its open source nature—Linux innovations are only limited by the creativity of the technologists who use and adapt it.
When Linux first arrived, it was mostly a hobby for enthusiastic engineers and computer science students who could contribute by developing code. The steep learning curve associated with fitting Linux to your machine was a barrier to entry for more novice programmers.
Over time, this has changed considerably. Online forums, workshops and classes have made Linux more accessible to the average internet user. The free sharing of ideas has come to epitomize the open-source community, and for software engineers, Linux is at the heart of this community. This democratization of Linux has had incredibly positive impacts on the computing world.
Now, Linux is everywhere. Enterprise-level companies use Linux distributions to process the biggest production workloads in the world. It has replaced proprietary commercial Unix operating systems in very large companies with better stability and less downtime. Because Linux systems can be as small or as large as you want, it’s also now being used in our homes for smart and mobile devices as well.
The open source nature of Linux is incredibly beneficial for these enterprise-level companies. Linux distributors leverage the contributions of the entire open source community. This wide range of contributors produces a more stable product with more features but also ensures that the OS keeps growing and solving real-world problems that are beneficial to a wide range of users.
Potentially the most impactful outcome of the kernel is its importance to the infrastructure of modern cloud computing. Linux’s scalability has paved the way for supercomputers and server farms to function efficiently while requiring relatively lightweight computing resources. In fact, Linux supports about 90% of the public cloud workload.
Without Linux, the cloud as we know it would not exist. This is, in part, because Linux has become so ubiquitous—its use cases are nearly limitless. Because it has been time-tested, many engineers and IT professionals have a solid grasp of Linux fundamentals, making it an attractive choice for enterprise companies dealing with the cloud.
Cloud-based software and products are increasingly becoming the norm in the engineering world. Unsurprisingly, major cloud providers such as AWS, Azure and Google Cloud are all supported by Linux as well. Linux is unique because it is a shape-shifter that can conform to the needs of any given engineering environment, and it’s incredibly stable because of the army of contributors that fortify weak points in the software.
The concept of Linux is just as important as the Linux product. The concept allows a free and open source operating system to be refined, reinforced and replicated across an endless web of contributors. Thirty years is a long time for software to be relevant, especially with the ever-shortening tech product cycles. Because it was designed with the intent to be changed and updated by an open source community, Linux has no foreseeable expiration date.
Had Linux not achieved the prominence it has today, we would see more commercial Unix vendors attempting to solve some of the problems that Linux addresses, but none would address them all. Additionally, customers would have to choose which OS to invest in based on which addresses some of their use cases, but none would be as beneficial as the Linux OS.
Linux is always growing and will become even more popular within the next few years. As more people become familiar with Linux and learn to use it, I see major potential for growth in the mobile computing space, within personal computers, and across small and large companies. In fact, we are already seeing it filter into home gaming systems and Raspberry Pi projects. With Linux, the sky’s the limit!
The open source software (OSS) supply chain is under attack. As evidenced by the recent Log4Shell vulnerability, the OSS supply chain is increasingly a focus for attackers seeking to exploit weak links in security. A number of research reports have recorded a significant increase in so-called ‘next-gen software supply chain attacks‘ over the past decade. These attacks look to compromise key links in the software supply chain including source code, build systems, CI/CD tools and code testing tools, among others. Next-gen attacks are happening across all languages, all types of software and are increasing in their frequency. Common forms include typosquatting, malicious code injection and tool tampering (like the CodeCov incident). In 2021, 64% of organizations reported they were affected by software supply chain attacks, according to container security company Anchore.
The increasing wave of next-gen attacks has driven new regulations mandating specific steps to inventory and make more transparent the content of software applications and the software supply chain. Specifically, executive order 14082, issued by U.S. president Joseph Biden, mandated a long list of security practices, including the inclusion of a software bill of materials (SBOM) with every application run by the U.S. federal government. The National Institute of Standards and Technology (NIST) is creating reference architectures and templates for application security as a result of the executive order. In other words, software security regulations will likely impact every company that produces code or sells products running on code (including SaaS products).
To be clear, some of the problems experienced by the OSS software supply chain are not exclusive to open source. The recent supply chain attacks on Microsoft Exchange Server and the SunBurst attack on the SolarWinds network management tool targeted proprietary code bases. That said, OSS is produced and maintained very differently than proprietary software. This does result in some unique risks. Here, we will cover those risks as well as some promising initiatives underway to address them.
There are two primary reasons OSS supply chains are a tempting target. One is its omnipresence and the other is its weakness. It is not an exaggeration to say that OSS is omnipresent. According to Sonatype, 98% of all codebases contain OSS. This is likely an underrepresentation. You simply cannot build code from scratch today without using OSS components. It is too labor-intensive and expensive. The ubiquity of OSS makes the supply chain that creates, distributed and manages it an obvious target. At the same time, that widespread use translates into an increasing burden on companies to maintain, update and patch all OSS dependencies in their applications.
This is an impossible task; it is far easier to insert OSS code to solve an immediate problem than to, over time, make sure that code is updated and not vulnerable. For this reason, Sonatype estimated that 92% of all applications contain outdated or vulnerable code. We have seen the impact of this inability of organizations to maintain their OSS code through attacks like the one perpetrated against Apache Struts software run by credit reporting company Equifax, a breach that exposed the sensitive personal and financial information of hundreds of millions of Americans.
In recognizing that OSS is a fruitful channel for attacks, attackers have focused more specifically on the supply chain because it is often the weakest link. Elements of the supply chain reside in the gap between responsible organizations and may be less strictly policed or less actively secured. Continuous integration/continuous deployment (CI/CD) tools, OSS libraries that can easily access other systems, package managers and open source developer tooling are all components of the supply chain that are widely used but which are often the sole responsibility of many part-time maintainers who write and maintain code as an unpaid avocation.
The three key benefits of OSS each create unique security and supply chain challenges. Specifically, OSS is open, free and transparent.
Linus Torvalds said that many eyeballs make all bugs shallow. To a degree, this is true. But what if those same eyes are looking for bugs to exploit rather than fix? Not everyone on the internet is nice and many seek to exploit the fact that anyone with a GitHub account can contribute code to critical libraries. This attracts a lot of great contributors, but also a lot of bad actors and bad behavior.
That behavior is often hidden or delayed. For example, we often see bad actors ask to contribute to projects or libraries run by single maintainers that are relatively popular and used by big applications. Often, maintainers struggle to keep up with the demands of these projects. A bad actor will offer to help, submit a handful of good PRs and gain commit privileges to the repository. At this point, the bad actor will then stealthily insert malware, such as a cryptojacking script.
Free is a good price. There are no purchase orders. This makes it super easy to use. Free also serves as a great distribution strategy. However, sometimes free is not worth it. If an organization depends on an application and it becomes critical, they might require fast patching, better compliance and official support relationships. Free OSS comes with no guarantee, and this can be a major liability. An application’s maintainers might be writing the code and applying fixes in their spare time on weekends because they already have a full-time job. In fact, research has shown that a significant percentage of the critical software powering the internet is maintained by volunteers; this was the cause of the Heartbleed vulnerability in the OpenSSH encryption libraries.
Free code also may not be updated for years. If a vulnerability is disclosed, you may not be able to get permission to merge fixes you write. If the code is abandoned and the author no longer checks comments or requests, then you are stuck and may have no choice but to fork the project. A hard fork on short notice can cause chaos and its own problems. This is what happened with a popular Golang library called JWT Go, which made its way into dependency trees across the Golang ecosystem. JWT Go was even included in Kubernetes, one of the most popular and important open source projects. When a vulnerability to JWT Go emerged, everyone realized the maintainer had abandoned it. Multiple forked versions emerged with different patches for the same bug. Chaos ensued.
It is a common refrain to ask companies to fund volunteer maintainers. There are numerous programs for this, including GitHub Sponsors, Open Collective and Tidelift. These programs are helpful but not sufficient. You can’t just hand people a small amount of money and get more secure code and professional-grade maintenance. Even if you offered full-time salaries, it might not translate into well-supported, secure code.
The transparency of OSS is real, but the idea that this code is getting audited and reviewed constantly is an illusion. Yes, the source code is distributed and open. But the sheer quantity makes it impossible to review all the code you use. If you are using millions and tens of millions of lines of code, you don’t have time or sufficient eyeballs. Even if you are spending considerable resources on code review, it is still easy to miss problems and vulnerabilities and relatively simple for malicious contributors to projects to hide malware or other bad inclusions. Reviewing the source code also does eliminate all risks. When most OSS code is consumed, it is running as a package compiled by another entity or developer.
Further, there is no guarantee that the contents of the package comes from the same source code you audited. We have actually seen this attack often with package repositories like npm and Maven, where malicious actors insert tampered builds or take over packages and insert code that is not listed as part of the package.
The CodeCov incident is one of the more recent and egregious examples. This free service for checking the code coverage of unit tests used BASH script running inside of a CI server for installation. The script was compromised and attackers inserted malware that could steal code secrets and export them. Those secrets might be tokens used to publish packages in npm or Maven and exposing those secrets allowed attackers to then compromise those packages. In another example, a PHP server managing source code distribution for the PHP project was compromised and multiple commits injected malicious code into the source code repository. The incident was caught quickly, but it demonstrated how attackers could tamper with source code directly, bypassing code review and security processes.
Innovative efforts to better secure open source and its supply chain are gaining momentum. The SBOM is gaining acceptance and it is getting easier to automatically generate SBOMs from CI/CD pipelines or build systems. A new initiative to make it easy to cryptographically sign code, called Sigstore, aims to remove barriers to code signing; ubiquitous code signing would make it much harder to compromise the supply chain by attacking the source code provenance problem at its root. Lastly, the Open Source Security Foundation has garnered tens of millions of dollars in funding from major technology companies and is in the process of spinning up mechanisms to issue grants and otherwise provide a more robust financial support mechanism for OSS. These developments point to a brighter future where the OSS Supply Chain is far more robust and companies can more easily audit, track and trust all the OSS dependencies in their applications and the full supply chain that moves OSS code from developer boxes up into production environments.
About Secure Software Summit
The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.
https://go.shiftleft.io/secure-software-summit-2022-replay
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: ByteDance restricts TikTok in Russia, Unified Patents escalates the fight against trolls, and Google Chrome beats the magic 300.
First up this week: Russian TikTok users won’t be able to view or upload new content. For users in Russia, TikTok has frozen its catalog of cringe.
Putin’s vague new “fake news” law is concentrating minds in Beijing’s ByteDance. Is your organization exposed too? To protect its employees—and perhaps its users, too—it’s hitting the Safe Mode button.
Dan Milmo: TikTok restricts service in Russia
Chinese-owned TikTok said it would block livestreaming and uploading of new content in Russia after the Kremlin criminalised the spreading of what it deems to be fake news about its invasion of Ukraine. … The BBC, CNN and other global media outlets have temporarily suspended reporting in Russia to protect their journalists.
…
TikTok spokesperson Hilary McQuaide said the app in Russia now appears in “view-only” mode and won’t let people post or see new videos or livestreams. They can still see older videos, but not if they came from outside the country.
…
She said, “The safety of employees is our top priority,” … adding that the video-sharing service—part of China-based tech company ByteDance—did not want to put either its Russian employees or users at risk of severe criminal penalties.
With more on that head-scratching law, here’s Aimee Chanthadavong:
Russian President Vladimir Putin signed a new law on Friday that bans what the country calls “fake” news about the military. This law will target any statements referring to the invasion of Ukraine as an “invasion”, any attempt to discredit the armed forces, or calls for sanctions on Russia. Those found to be spreading so-called fake news could face up to 15 years in prison.
…
TikTok’s in-app messaging service will not be affected. … “We will continue to evaluate the evolving circumstances in Russia to determine when we might fully resume our services with safety as our top priority,” TikTok added.
And Scott Nover thinks about the effects on Russian citizens:
Russia’s fake news law is a severe step for a country whose government is already antagonistic to … a free press. … The country has blocked Facebook, Twitter, and YouTube proactively, but TikTok beat Russia to the punch. The result is the same, however: The people of Russia … will be locked out from another window into the real-life consequences of Putin’s war.
“Patent assertion entities,” also known as “non-practicing entities,” are organizations that don’t produce anything, but simply acquire and hoard patents—later asserting them against unsuspecting organizations. The aim is to extort money from those they claim are infringing.
The problem? Many of those patent claims are as weak as a sickly kitten.
You might think you’re safe, but trolls also go after the users of the disputed technology. Examples include podcasting, JPEG images, order-confirmation emails, geo-locating a car and even caching data.
Steven Vaughan-Nichols: Open Source Zone grinds away at patent trolls
Patent trolls, aka Patent Assertion Entities (PAEs), have plagued … software for ages. … The attacks keep mounting up. The reason is simple: It’s profitable.
…
[But] Unified Patents, an international organization of over 200 businesses … brings the fight to the trolls. It deters patent trolls from attacking its members by making it too expensive for the troll to win. … With United Patents’ high success rate in knocking out bad patents, slowly but surely the patent trolls are being driven back.
…
For example, an Accelerated Memory Tech patent 6,513,062, was used by the troll IP Investments Group to claim … Redis, which manages cache resources on the cloud, violated the patent. [The troll] went after Hulu, Citrix Systems, Barracuda Networks, Kemp Technologies, and F5 Networks for their use of Redis software. IP Investments Group gave up rather than fighting it out. Everyone who uses Redis wins.
Ban software patents? Beware of throwing out the baby with that bathwater, thinks WierdUncle:
Patents themselves are a good idea: … Inventive people should be rewarded for their contributions to the economy.
…
[But] patent trolls are parasites who contribute nothing to the prosperity of citizens. … The patent troll business plan is unfortunately quite viable. You don’t invent anything, or fund new developments. You have sufficient funds to clobber anybody who challenges you, by having better lawyers.
The underlying issue is weak patents. Here’s nzkbuk:
Start suing the patent office for damages against wrongly issued patients. It would then be in their best interest to set up this sort of thing as an alternative where the patient can be investigated first.
Google Chrome on macOS boasts a better benchmark score than Safari on an M1 MacBook Pro. Hilariously, this is using Apple’s own Speedometer benchmark tool.
Great PR, and popcorn-worthy Cupertino trolling. But aren’t there better optimizations Google could be making?
Frederic Lardinois: Chrome on macOS is now faster than Safari
Version 99 of Chrome on macOS manages to score 300 points on the Speedometer benchmark, which was originally developed by Apple’s WebKit team. This, Google points out, is the fastest performance of any browser.
…
It’s been a while since competition in the browser market focused on speed. … When a new chip comes along, though, there’s always room for optimization. Originally, Chrome on Apple’s M1 chips had passable performance, but … Chrome now runs 43% faster on them.
…
Speedometer 2.0 tests for responsiveness, which makes it a good proxy for user experience. … It doesn’t take much to make software feel more responsive, so the 43% on M1 Macs will surely make you feel more productive.
How? Try not to gloat, Max Christoff:
Building on many performance changes over the last year, we enabled ThinLTO in M99, a build optimization technique that inlines speed-critical parts of the code base, even when they span multiple files or libraries. … Two of the other recent major contributors to Chrome’s speed are the V8 Sparkplug compiler and short builtin calls. Sparkplug is a new mid-tier JavaScript compiler. … Short builtin calls are used by the V8 JavaScript engine to optimize the placement of generated code inside the device’s memory [which] boosts performance by avoiding indirect jumps when calling functions.
…
We know that benchmarks are just one of many ways of measuring the speed of a browser. [But] combined with recent graphics optimizations (namely, pass-through decoder and out-of-process rasterization) … Chrome is now 43% faster than … 17 months ago.
Benchmarks/schmenchmarks, thinks codedokode:
Browser developers are optimizing the wrong thing. … Optimizing for speed usually causes increased memory consumption, and this increases the chance of invoking swapping. If the system starts swapping, it becomes orders of magnitude slower.
…
If the browser could use [half the] memory while using twice amount of CPU time, that would be perfect. Just think how many laptops with 2 or 4 GB of RAM would become usable again.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Rostislav Artov (via Unsplash; leveled and cropped)
Lately, new ESG initiatives have come front-and-center as companies seek to contextualize and limit their business’s impact on the environment. This is especially true for the built world—a term that refers to the human-made environment that provides the setting for human activity, including homes, buildings, zoning, streets, sidewalks, open spaces, transportation options and more—where monitoring energy efficiencies is becoming more commonplace and even required by law. For example, a New York City law now requires buildings of a certain size to post an energy-efficiency score at their entrances. Yet, calculating such a score isn’t that straightforward—there’s a lot of legacy technology in use within most large commercial and residential buildings, and pulling data from these systems is notoriously difficult.
A building manager may seek greater visibility into these systems to not only determine a building’s energy score, but to program optimizations, inform building security or enact new digitization. But the answer isn’t to hastily rip out and upgrade old hardware—old equipment like AC units and elevators were built to last 50 years or more and could be functioning seamlessly. Instead, this is another area where REST APIs are set to accelerate by uniting legacy integration software and disparate hardware with a standard layer.
I recently met with Shaun Cooley, CEO and founder of Mapped. According to Cooley, API-driven standards for built environments could open up transparency into hardware component behaviors and the interrelationships between systems within a building. Below, we’ll briefly consider the history of building protocols and look to standards like Brick Schema that aim to unite legacy and modern physical infrastructure. We’ll consider the competitive advantage APIs bring to the built world and how increasing data accessibility could assist operations.
The built world consists of various digital communications standards. Most buildings have many older on-premises protocols for lighting, HVAC, elevators and other systems. For example, many elevators and fire safety systems were installed by systems integrators in the 1970s and adopted connections using Modbus, a communication protocol based on serial connections. BACnet is also commonly used to control HVAC systems and is a step forward from Modbus in that it can more easily connect to IP networks.
Fast-forward a few decades to the dawn of the cloud; many companies overlaid sensors onto these old systems, explained Cooley. These power-over-ethernet (PoE) or battery-powered systems relay data immediately to the cloud and often speak in proprietary protocols. A single commercial building could easily be juggling a bundle of these various communication protocols, all originating from installations that occurred at different time periods. These nuances mean that you are “constantly dealing with chaos across your portfolio,” Cooley said. There’s so much data, but getting it normalized and usable is very challenging, he said. One must integrate with many sensors and protocols, which he describes as “the dirty plumbing” that no one wants to build.
There’s bound to be differentiation from building to building, too, which could place a further strain on managing multiple building operations. Without a window into building data, it isn’t easy to know things like the current occupancy of the lobby or how occupancy affects energy consumption. Unless managers can connect the dots between systems, it’s impossible to understand the relationships between components.
For example, take an AC system in a commercial building. Such a unit isn’t as simple as a single-family home’s typical thermostat and furnace. It’s often a mix of a rooftop chilling unit, pipes, pumps and a VAV damper that controls the air. While protocols are good at describing how individual components are performing, the composition of components is really what defines a building’s system and its efficiency, said Cooley.
According to Cooley, instead of adopting a vertical data schema, buildings require a graph data model to adequately represent hardware interconnections. This is why he’s rallying behind Brick Schema, an open source uniform metadata schema for buildings. Instead of a vertical data schema, Brick Schema is built on a graph data model, which enables more descriptive relationships in a system.
Pulling unstructured data from 20 different data lakes into a clean API could allow easier access to new solutions. “We want to make it very simple to build applications for these sorts of environments,” said Cooley. Typically, system integrators must reverse engineer and connect to legacy building hardware, which can become very expensive very quickly, he said. He recommended using a sandbox based on open standards that can easily be rolled out to any building to reduce those hurdles. A more consumable layer with common endpoints could increase developer usability when creating innovative building applications.
Similar to how Twilio made SMS easy, Cooley said he hopes for a similar proliferation in the built world. Many applications could be built with such an abstraction layer. For example, managers could better understand energy usage to reduce consumption, meet regulations and save money. Or, such an abstraction layer could inform predictive maintenance to create automated alerts before failures occur. There are also plenty of ways to improve occupant experience or intelligently optimize the lighting and temperature in a space.
“Entirely new business models and concepts emerge that we hadn’t considered previously,” said Cooley. For example, he described a “tailgating app” that uses Brick Schema for a security use case. The app prevents building occupants from letting other people “tailgate” into the building behind them after someone swipes their badge. To do so, the app interfaces with many separate building systems (the elevator system, surveillance system, telepresence systems and other sensors) to ensure the number of people in the building matches the number of occupants that swiped in. A lingua franca helps to connect the disparate hardware involved.
This is by no means the first attempt to standardize building data. For example, the Green Button Initiative provides a standard API through which to download utility use data for electricity, gas and water and share it with solution providers. However, according to Cooley, this information only goes so far. Building owners will require more contextual data on-site.
For example, perhaps a building’s window glazing is causing specific rooms to overheat in the sunlight. Thermal sensors would spot this condition, but bulk energy consumption readings wouldn’t ascertain the root cause. Access to real-time granular data such as current occupancy count is also necessary for developing on-site applications that better refine exactly how human involvement impacts energy consumption.
Of course, as building systems become more intelligent, there is the growing possibility of privacy infringement. For example, systems that use facial monitoring and recognition could end up storing personally identifiable information. In that case, you “need to give data owners the control to decide what applications can’t or can’t access PII,” said Cooley.
While this field has many read-only applications, Cooley predicts future write operations will enable more automation with building hardware. This could allow applying ML/AI to anticipate elevator floor calls. Or, a predictive system could cool a room only when a meeting is scheduled. When such data is readily accessible and available for developers, it presents many innovative opportunities to optimize and interact with the built world.
The Linux Foundation today published a report that provides access to eight lists of the top 500 open source libraries being used by organizations as part of an ongoing effort to help better secure software supply chains.
The Census II of Free and Open Source Software—Application Libraries report is based on usage data from providers of software composition analysis (SCA) tools such as Snyk, the Synopsys Cybersecurity Research Center (CyRC) and FOSSA. The report itself was compiled by the Harvard Lab for Innovation Science.
The eight lists are made up of four that include version numbers and four that are version agnostic. The lists are separated into npm and non-npm packages because npm packages would dominate any ranking created. The top non-npm packages being employed include maven, nugget, Go and cargo.
Frank Nagle, assistant professor at Harvard Business School, said the report is intended to provide organizations with some guidance in terms of knowing what open source packages are used in the wake of recent vulnerabilities discovered in the widely employed Log4j software used to manage logs within Java applications.
Many of the organizations impacted by that vulnerability were unaware of just how widely deployed Log4j was within their enterprise IT organizations. IT organizations should evaluate the sustainability of those projects in terms of the number of contributors and maintainers that are working to ensure the security of those libraries.
One of the biggest challenges is to find a way to standardize naming schema for software components and the overall management of versions of different libraries, noted Nagle.
Ultimately, the goal is to convince more enterprise IT organizations—and the vendors that support them—to make more resources available to secure those libraries, noted Nagle. Much of the most widely used open source software is developed and maintained by only a handful of contributors. Many of those contributors argue that, while they made that software available for free, it is the responsibility of the organizations employing it to secure it.
The Linux Foundation is moving to become a conduit through which it will make available additional resources to help better secure open source software. The Open Source Security Foundation (OpenSSF), a consortium hosted at the Linux Foundation, earlier this week announced that 19 additional organizations have joined OpenSSF to help identify and fix security vulnerabilities in open source software and improve tooling, training, research, best practices and vulnerability disclosure practices.
Brian Behlendorf, executive director at OpenSSF, said in addition to making resources available, it’s clear there is a need for some form of a third-party audit of open source software as organizations are more broadly employing that software across their software supply chains.
New premier member commitments to OpenSSF are now coming from 1Password, Citi, Coinbase, Huawei Technologies, JFrog and Wipro. New general member commitments are being made by Accuknox, Alibaba Cloud, Block, Inc., Blockchain Technology Partners, Catena Cyber, Chainguard, DeployHub, Gravitational Inc., MongoDB, NCC Group, ReversingLabs, Spotify and Wingtecher Technology. New associate members include Institute of Software, the Chinese Academy of Science (ISCAS), MITRE and OpenUK.
Other efforts led by the OpenSSF include an Alpha-Omega Project to better secure open source security posture, scorecards that identify risks of the dependencies within more than one million projects, multi-factor authentication tokens and a Project Sigstore initiative to sign, verify and protect open source code.
It may be a while before open source software achieves the level of security the IT industry strives for. On the plus side, however, there have never been more resources allocated to achieving that goal.
Welcome to Ukraine Week here at 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: Censoring the Russian internet, Snap fears for hundreds of Ukrainian employees, and Eugene Kaspersky acts like a ****.
First up this week: Ukraine has asked ICANN to drop Russia from the DNS. Andrii Nabok, the Ukrainian representative of ICANN’s Governmental Advisory Committee argues a DNS blockage would “help users seek for reliable information in alternative domain zones, preventing propaganda and disinformation.”
Given today’s confirmation that Muscovite K12 students had been arrested for laying flowers at the Ukrainian embassy, this goal seems all the more laudable. But frankly, a moment’s thought says it’s a bad idea.
John Gilmore was right. Such a move would inevitably fail. And there’s a real risk of undesirable, unintended consequences.
Kat Bouza and Noah Shachtman: Ukraine Pushes to Unplug Russia From the Internet
Ukraine’s request to the Internet Corporation for Assigned Names and Numbers (ICANN) seeks to revoke domains issued in Russia and shut down primary Domain Name System (DNS) servers in the country. [It] would send a strong message to a regime pumping out digital propaganda.
…
The DNS root zone is a crucial element of the overall functionality of the internet, responsible for handling queries to top-level domains — such as .com, and country-specific domains like Russia’s .ru. Removing Russia’s access to this cluster of servers would prevent Russian internet-service providers from communicating.
…
But … the unprecedented request has the potential to do more harm than good. … Representatives for ICANN … declined to comment.
But the request is pretty naïve, thinks this Anonymous Coward:
All they would have to do is get the ISPs to add a zone to their DNS that says “ru. IN NS x.x.x.x” and then for all their users, any requests for a .ru domain would be directed to x.x.x.x
OK, the rest of the world would miss out, but I doubt that they would care.
Is there a better way? ArmoredDragon breathes fire:
A better way … is to ask western certificate authorities to revoke all [Russian] certificates. Then ask the major OS and browser vendors to remove any CAs that don’t comply.
That would really **** with them because there’s nothing [Russia] can do about that. And it would even **** with Russia’s ability to do business with Chinese companies and Chinese customers.
Snap, Inc.—formerly Snapchat—owns the Ukrainian company that created the technology used in the real-time video shenanigans behind “I’m not a cat.” It has hundreds of employees in Kyiv and Odesa.
This very human DevOps story is but a footnote to the wider picture of tech companies acting to echo Western governments’ sanctions. It’ll cause us a little pain, but that’s nothing compared to the suffering felt by Ukrainians. And it’ll be worthwhile if it shortens the war.
J. Clara Chan: Three hundred Snap employees are from Ukraine
In a public note, … Snap — the parent company of Snapchat — said … that 300 of Snap’s “most creative and talented team members” are from Ukraine, … the birthplace of Looksery, the augmented reality platform that Snap acquired in 2015. … Snap said it has pledged over $15 million in humanitarian aid to support Ukraine. … The company is also providing emergency assistance to employees who need help safely relocating.
…
“We stand in solidarity with our Ukrainian team members and the people of Ukraine. … This is a devastating conflict with far-reaching consequences. … It is a direct threat to many of our team members and their families.
…
“Over many years working with our Ukrainian colleagues and friends, we have gotten to know the inventiveness, strength, and resilience of the Ukrainian people. … We will continue to work tirelessly to help our Ukrainian team members and their families, support our Snapchat community, and determine how we can help make positive contributions to the immense humanitarian efforts underway.”
It’s bang on trend, reports Corinne Reichert:
Snapchat has followed suit after Facebook, Twitter and YouTube began pausing ads on Friday, saying it has now stopped all advertising running in Russia, Ukraine and Belarus following the Russian invasion of Ukraine. … The Snapchat app remains live in Ukraine, Russia and Belarus, [but] Snap is monitoring the platform for misinformation or other misuse.
…
Apple has also halted sales of its products in Russia, as well as online transactions, Apple Pay and some Apple Maps features. Google [is] temporarily disabling some live Google Maps features, adding an SOS alert to Search and blocking Russian state-controlled media. It said Google Pay “may become unavailable.”
But don’t hang up on Dade “+++ATH” Hayes: [ask your parents]
In terms of any financial sacrifice from the foregone advertising opportunities, it isn’t clear that all that much is at stake for Snap. … While the company’s stance on the Russia-Ukraine situation clear and emphatic, it is also an easier one for for Snap to take than for many of its tech rivals.
The figurehead eponym of AO Kaspersky Lab is being publicly shamed for comments he made about the war in Ukraine. In stark contrast to Snap’s statement, he is accused of overt neutrality, minimizing the war’s severity—and even of shoehorning in some marketing.
Desmond Tutu was right. But, while it’s tempting to “cancel” Eugene, dial down the emotion and think instead about your security posture. If you use Kaspersky products internally, what risks are you exposing your organization to? How might the Russian government exert pressure on the company to compromise your network?
James Coker: Eugene Kaspersky’s Statement Provokes Controversy
Cybersecurity industry veteran Eugene Kaspersky has provoked a strong reaction from leading figures in the sector. … Kaspersky, CEO of the Russian-headquartered IT security vendor of the same name, broke his silence on the conflict:
…
“We welcome the start of negotiations to resolve the current situation in Ukraine and hope that they will lead to a cessation of hostilities and a compromise. We believe that peaceful dialogue is the only possible instrument for resolving conflicts. War isn’t good for anyone. … The main thing we can do in this situation is provide uninterrupted functioning of our products and services.”
…
His description of the conflict as a “situation” and apparent attempt to advertise his firm led to a number of furious responses. … Following Kaspersky’s tweet, the hashtag #BoycottKaspersky appeared.
With a balanced view, it’s Nick Farrell:
Kaspersky sits on the fence … in Russia it is not a good idea to have a view. [But] whoever is advising Kaspersky on PR might need to have a rethink.
…
After all a compromise is [not] always possible when one side is firing missiles into residential areas. If he applied the same premise with ransomware, he would be suggesting, … “It is better that you talk to the people who are holding your servers hostage.” … How much is Kaspersky, the company, influenced by the Russian government?
Does your shop use Kaspersky? Nick Lange cuts to the chase:
I would like to remind all readers that, in case of war, … software with access to companies and the capacity to be updated worldwide in matter of hours at the same time is a high class target to get forced to cooperate by a autocratic government.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Brandon Morales (via Unsplash; leveled and cropped)
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: Linode gets bought by Akamai, Firefox market share is “measly,” and Google brings staff back to the office.
First up this week: Why is Akamai buying Linode? Whatever the reason, it’s a big payday for its solitary shareholder: Not far off a billion dollars.
The 100 lb gorilla of edge computing and CDNs is promising not to mess with Linode’s winning open source cloud formula: No change, steady as she goes, etcetera. But how many times have we heard that before?
Here’s local scribbler Paige Gross: Linode’s $900M acquisition by Akamai is a ‘game changer’
A household name in the Philly tech scene … CEO Christopher Aker founded the company in 2003, and it’s been bootstrapped ever since, growing to about 250 employees. … Aker has owned 100% of Linode since he founded it.
…
Aker said the deal brings the company closer to solving evolving challenges “as cloud services become all-encompassing, including compute, storage, security and delivery from core to edge. … We’ve been talking about ‘alternative cloud’ — alternative to the big guy — and now we’ve sort of validated ourself in this market.”
…
The Old City company maintains “well over a million accounts” but has anywhere around 150,000 active users of its platform at any particular time. Linode’s HQ, the bank building at Third and Arch Streets, remains. … For clients and Linode employees, there won’t be too much noticeable change [Linode] says.
Why does Akamai want Linode? Jonathan Greig asked the CEO:
Akamai CEO Tom Leighton [explained] that Linode has great customer support and is already in 11 locations, which Akamai is going to “dramatically” expand. … Leighton also noted the September 2021 acquisition of Israel-based Guardicore, a cybersecurity company that offers a micro-segmentation solution to reduce the potential attack surface of corporate networks, secure applications, and meet compliance standards.
…
According to Leighton, the company is expecting the cloud compute category — which includes edge applications, its net storage business, and Linode — to reach “well over half a billion dollars in 2023. … We were pioneers in edge computing and now we’re taking a big step forward in cloud computing with Linode.”
But here’s a worried-sounding zoid.com:
Well good for them but I hope [Akamai] don’t screw it up. Linode is a great hosting company.
Last week, a journalist innocently asked, “Is Firefox OK?” And people lost their minds.
We need Firefox and Gecko. A Chromium monoculture is bad for the web and bad for DevOps. (Before you ask: No, the existence of WebKit doesn’t change things, thanks to Apple’s ridiculous policies). Much as I tried to say something nice about Firefox last month, its market share is, frankly, pathetic.
Matt Burgess: Is Firefox OK?
In the two decades since Firefox launched from the shadows of Netscape … the browser has slid to less than 4 percent of the market—on mobile it’s a measly half a percent. … Its fate also has larger implications for the web as a whole.
…
Each year Google pays Mozilla hundreds of millions of dollars in royalties. … In its 2020 financial results … Mozilla listed its total revenue as $496 million. … The Google-Mozilla deal was last renewed in 2020 and is expected to expire in 2023. … Mozilla and Firefox acknowledge that for its long-term future it needs to diversify the ways it makes money.
…
Firefox still matters: … The browser market is dominated by Google’s Chromium codebase and its underlying browser engine, Blink. … Microsoft’s Edge Browser, Brave, Vivaldi, and Opera all use adapted versions of Chromium. Apple [has] its WebKit browser engine [but] other than that, Firefox’s Gecko browser engine is the only alternative.
Firefox, how do we love thee? Let not_count_zero count the ways:
I still use Firefox because:
a) I remember Internet Explorer and the standards wars. …
b) I don’t trust Google. …
c) Most sites work well.
…
I do have questions though. … They’re currently getting around a half a billion‽ What are they doing with it? … This seems really off—really, really off.
But heed a deeply worried Thom Holwerda:
The decline and potential demise of Firefox is a massive problem that everybody seems to be kind of tiptoeing around—too afraid to acknowledge that if Firefox were indeed to disappear, we’d be royally screwed. We’d end up right back where we started 20 years ago, with Chrome being the new IE6.
…
The situation is especially dire for … Linux users, developers, and distribution makers. … Gnome Browser or KDE’s Falkon can barely be taken seriously, and … are based on Apple’s WebKit, which isn’t a great position to be in.
Google is planning “celebrations” to welcome back employees after being fully remote. And in practice—unlike at IBM—this doesn’t mean a vaccine mandate.
It was just three months ago that Google said it “firmly stands behind our vaccination policy.” What changed? It’s unlikely to have been due to a tiny minority of staff publishing a manifesto.
Jennifer Elias: Google relaxes mandates
The company will no longer require vaccination as a condition of employment … as it prepares to bring workers back to the office … at least three days a week for a “hybrid” work model. … The company [had previously] told employees that they must comply with vaccine policies or they’d face loss of pay and eventually loss of employment.
…
According to Google spokesperson Lora Lee Erickson … the company dropped the requirement … after removing the Jan. 18 deadline it had set for employees to either get vaccinated or get exemption approval. She declined to provide further details on the policy or the reasons for the reversal.
…
Google Real Estate and Workplace Services VP David Radcliffe [said Google] is preparing to begin its 30-day transition period to the hybrid work week if conditions continue to improve. He said his team is planning “celebrations” to welcome back employees. … Unvaccinated employees who are approved to enter offices will still need to follow additional protocols, including testing and wearing a mask.
It’s too simplistic to say the anti-mandate brigade are also anti-vaxxers. For example, raxxorrax:
I am vaccinated and HR knows this. … But if they officially demanded a certificate, I think I would have called it quits. Many people don’t have that option [but] there are consequences for such unreasonable demands.
…
I understand a mandate for vaccinations in certain occupations relating to health. It is something you have to personally accept if you want to work in the field.
Although a few others are way over at the end of the bell curve. Greg Jinkerson:
Don’t get excited, [Google is] still evil and stupid. … Now they’re backing down for some reason, [but] this is barely anything notable as far as a rollback of restrictions. [It] is not any kind of encouraging news.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Aleksey Kuprikov (via Unsplash; leveled and cropped)
Imagine a world without DevOps. Everything that could be automated isn’t. Any job you dream up isn’t possible and, instead, you have to dig 10 to 15 clicks deep into a friendly but oppressive software interface to make every single change. Oh, and there’s no way to run searches.
Picture that and you have a good sense for what managing most business systems (CRM, ERP, HCM, MAP and other three-letter acronyms) are like today. They’ve been designed to make things easy on users, not efficient for administrators and it forces admins to work out of a schematic island—the interface—where no-code conventions rule.
Yes, there are developer modes, but they aren’t the cure-all you’d imagine. Your business likely has 800+ business applications and whatever you build in one you have to rebuild in all. Not all have dev modes, and no two dev modes use the same language.
This is all to say that, unless business systems get a universal language that works across all of them, businesses will be in deep trouble. I talk to lots of companies about this and many already are.
If you think about all your business systems together, they constitute a sort of “product” upon which the entire business runs. When that product is built out of 800+ services that can only be governed individually, you have a lot of problems.
As examples, companies I talk to have experienced the following horrors: A minor change caused sales leads to go unrouted for six months. Those leads grew stale, and the company wasted both the money spent acquiring them and lost millions in potential business. Another found that changes in their CRM created an error in the ERP and invoices didn’t go out until after the quarter’s end. (You should have seen the investors’ reactions). Another had a minor error trigger a dormant email campaign that blanketed their database with out-of-date offers.
This list could go on and on, and the effects are real. From managers who lost out on rockstar candidates because the HR system was undergoing maintenance and they couldn’t send an offer to arcane DOS-based internal systems that have become so enmeshed they are irreplaceable—business systems are vital, and most of them are a mess.
In fact, business applications teams face all the same challenges that software developers do, but benefit from none of their tools. They can’t search through one formal representation of all their applications’ code. (To say nothing of searching across applications.) They can’t easily back up, save versions, collaborate or evaluate PRs except within each system’s frustratingly isolated dev mode.
As a result, they often can’t:
This would be all well and good if business systems were due for a sudden and rapid consolidation, but they’re not. They’re so not. The SaaS market is still growing at 19% year-over-year and some sub-markets are growing faster, like MarTech, at 25% year-over-year. It’s given rise to tragicomic diagrams like this one by Chiefmartec’s Scott Brinker. Companies are buying and relying on epic levels of SaaS.
Moreover, today’s business systems accumulate in vertical stacks. The financial applications team owns the ERP and other financial applications like Stripe and Zuora. The Salesforce team owns Salesforce. But business happens horizontally. Leads go from marketing to sales to finance to customer success. All those siloed applications aren’t really built to allow administrators to create a reliably error-free “product” out of all that. Unless, of course, we get a universal language.
I find it pretty unlikely that any one SaaS vendor is going to lead the charge for universal conventions for managing and configuring business applications. Each SaaS company views itself as the center of its own universe, with all other apps revolving around it. Their app stores reinforce that viewpoint.
It’s going to take an open source third party to build such a system, but here’s what having a universal language for managing your business systems can mean: You get DevOps across all your business applications.
To the Salesforce developer who couldn’t care less about NetSuite, that’s fair. But what if I told you that with this standardized language, everything you know about managing Salesforce could be applied to NetSuite if you were pulled into that project? Or vice versa? It’s a lot like suddenly being able to speak an entirely new language.
For the heads of departments whose purview spans applications and those who are already rearranging their teams to figure out how to be more agile and support the business, this is (potentially) for you. It doesn’t connect your applications (you’ll still need a Workato or a Boomi, for example), but it’ll give you and your team one view into how multiple applications are configured, and the ability to make changes and push them into production without going 10 to 15 clicks deep into the interface.
It allows you, in essence, to apply all of those DevOps practices you’ve been growing accustomed to in each dev mode across multiple systems. You can run searches, use a Git versioning tool, practice CI/CD, automate documentation, conduct impact analysis and scale your efforts.
Imagine a business systems world with DevOps. That’s possible, and I’d love for you to check it out and give us feedback.