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: The first silicon for Wi-Fi 7, Google’s search quality “is” failing, and what Severance tells us about The Great Resignation. (more…)
If you’re just getting into site reliability engineering (SRE) or platform engineering, you’ve probably come across a bunch of new terminologies, like SLI, SLA and SLO. These benchmarks are commonly referenced in the day-to-day life of an SRE but may seem foreign to outsiders. So, what are the differences between these abbreviations?
Well, one of the hallmarks of the SRE approach is to gauge performance and set targets for application metrics. These targets can be thought of as reliability thresholds. If a site’s latency reaches a certain point, for example, it may break the agreement the software provider has with its consumer.
SREs create and monitor service-level performance benchmarks for all sorts of metrics, such as uptime, latency, error count, mean-time-to-recovery and throughput, among others. But not all these performance goals are part of public agreements. Companies usually take a more proactive approach to setting more internal targets to stay far away from breaking external agreements and user trust. It’s become a best practice to set these baselines to retain functional, reliable systems.
As mentioned, the type of targets range from firm partner commitments to more internal goals. Below, we’ll attempt to define, in simple terms, the differences between service-level agreement (SLA), service-level objective (SLO) and service-level indicator (SLI). While these concepts share many similarities, it’s important to understand how they are applied in practice. Keep in mind that each company may have a nuanced understanding of these terms and may conceive and apply them differently.
First off, service-level indicators (SLIs) refer to the actual metrics produced by software services. This is a direct measurement of a service’s behavior. These are the real numbers that indicate overall performances, such as error rate and latency over time.
One example of SLI would be the number of successful requests out of total requests over a one-month period. Say an engineer used an application monitoring tool that ingests data from production logs. This data showed that out of one million requests made, ten requests failed. An SLI for availability would thus be 99.999% uptime.
Second, most technologists are familiar with service-level agreements (SLAs). Even if you’re not, you’ve likely agreed to many throughout your history as a digital user. SLAs are like a pact between the software provider and the software user or client. These binding commitments often note availability expectations that must be upheld. SLAs may also include responsiveness to incidents and bugs. It depends on the contract, but if an SLA is broken, some kind of penalty may be incurred such as a refund or a service subscription credit.
These days, the average business relies on many cloud-based SaaS, PaaS and IaaS. Just to initiate something as simple as an online payment might require hitting multiple remote servers. But if all these services just went offline whenever they felt like it, our digital operations would come to a grinding halt. SLAs are thus necessary for enterprise software contractual agreements to ensure both parties meet specific standards.
Once an engineer tracks SLIs and has an idea of typical behavior, they can then set an SLA that makes sense. If we take the example above, an SRE may consider guaranteeing a lower threshold than what is being actively monitored. This would ensure that application performance, at its current pace, doesn’t break any legal or contractual obligations. In this scenario, perhaps the SLA mentions an availability objective: No more than 100 requests fail per one million requests made. This would essentially equate to 99.99% uptime.
Lastly, service-level objectives (SLOs) are similar to SLAs but explicitly refer to the performance or reliability targets. An SLA may refer to specific SLOs. Or SLOs may be tracked just for internal purposes. As Google described, “the availability SLO in the SLA is normally a looser objective than the internal availability SLO.”
You don’t want the end users to be the first people clamoring about a 400%+ latency rise in your mobile web apps. Thus, SRE teams typically keep a close eye on performance to ensure they never even get close to breaking SLAs. Some do this by setting and monitoring internal baselines that are more ambitious than the SLA threshold.
If we take our example above, if an SLA guarantees a service uptime of 99.99%, the business may set an internal target of 99.995%. In other words, for every one million requests, no more than 50 should fail. If software systems aren’t hitting these marks, it’s a sign that the company must reevaluate designs and search for bottlenecks. Or, perhaps engineering teams have goals to improve the average downtime for the next quarter—an internal objective could be set at a higher standard than the currently perceived performance.
As the Google Cloud blog described, “every service should have an availability SLO—without it, your team and your stakeholders cannot make principled judgments.” It’s a good reminder to be modest in your reliability commitments, they added, as consumers will come to expect this level of performance. On the other hand, setting more ambitious internal performance targets has the benefit of delivering a better result than the agreement on paper, increasing a software service’s competitiveness.
Keep in mind that the above numbers are simply for demonstration purposes. One interesting resource for real-world figures is API.Expert, a service that queries popular APIs and posts weekly performance statistics. Since APIs are the heart of many UI-based platforms (and our digital economy at large), these benchmarks stand as a good indicator of average uptimes and latencies in the industry.
For example, at the time of writing, API.Expert’s Enterprise APIs collection ranked Microsoft Office365 and Pivotal Tracker at the top, both with a 100.00% pass rate and a 220 ms and 248 ms latency, respectively. On the other end of the spectrum, Docusign is at 99.93% with an 877 ms latency and Box is at 99.99% with 414 ms latency.
Although it may sound good to an unpracticed ear, an SLA of 99.99% still equates to 52 minutes and 36 seconds of downtime per year. That’s nearly an hour of downtime in which customers are left scratching their heads or, worse, searching for other options. For traumatic health care situations, a loss of connectivity could be a matter of life and death.
Although creating SLAs and SLOs is important to gauge system health, the reality is that it can be challenging to track and enforce them. “These agreements—generally written by people who aren’t in the tech trenches themselves—often make promises that are difficult for teams to measure,” according to the Atlassian knowledge center.
In summary, SLIs demonstrate the real behavior of software systems. These metrics inform the creation of SLAs, which must be met to ensure B2B agreements. These SLAs often reference particular service-level objectives (SLOs) that must be met, which usually give more breathing room around SLIs. Lastly, in a digital economy with accelerating digital expectations, it makes sense to monitor internal SLOs and improve baselines over time.
Checkmarx, a provider of a platform for testing application security, this week disclosed it has discovered a malicious instance of a PyPi repository for Python code that has been downloaded more than 70,000 times.
Tzachi Zorenshtain, head of supply chain security, said this discovery represents another instance where cybercriminals have made available a malicious copy of a popular open source software package that contains malware that is destined to find its way into downstream applications. Cybercriminals, via a tactic known as starjacking, create a web page that includes bogus statistics, such as GitHub stars, to make it appear a software package that a developer might download is from a legitimate open source project, he noted.
Cybercriminals are combining starjacking with typosquatting to set up web pages to mimic a legitimate open source project, noted Zorenshtain.
Starjacking represents yet another effort to compromise the integrity of software supply chains that rely on a wide range of open source software components to build applications. The only way to thwart starjacking is for either developers or DevOps teams to validate components before incorporating them within applications, noted Zorenshtain. Otherwise, it’s possible malware will only be discovered after it has already found its way into downstream applications deployed in a production environment.
The challenge, of course, is remembering to take the time to validate the source of any software component. Developers that are typically trying to build applications as fast as possible don’t always stop to make sure that all the components they are employing are from a legitimate source.
It’s not clear how pervasive fake sites through which developers are encouraged to download malicious software have come to be. However, as cybercriminals expand their efforts to compromise software supply chains, it’s clear their tactics are evolving in ways that exploit the trust developers have in open source software. It’s not likely these attacks will disrupt the open source ecosystem, but they do add additional urgency to make open source software more secure.
The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has raised more than $10 million to build tools and define best practices for securing open source software projects. Google has pledged to ultimately spend $10 billion to improve open source security. The Biden administration has also made improving the security of open source software that is widely employed both inside and out of government agencies a priority by expanding compliance mandates. The White House is also clearly trying to pressure IT vendors and larger enterprises to contribute more to the effort to secure open source software.
The trouble is many open source projects are maintained by a small number of programmers that contribute their time and effort to building components that others are free to use. Many of them argue the onus for making sure that software is secure is on the organizations that decide to deploy that software. Nor is their responsibility to track down cybercrimimals that employ Typosquatting techniques to distribute malicious versions of their software.
Many of the IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or just helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are now also assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may now be only a matter of time before a long-simmering open source software security issue erupts into a major crisis of confidence.
As an IT professional with decades of experience at every level of technology and organizations—from cell phone prototyping to banking enterprise architecture, from entry-level to CTO—I can state definitively that I have spent an inordinate amount of time dwelling on and dealing with security. And I know I’m not alone. This is a common theme. You could almost make a sitcom out of it. “What are your developers doing?” Uhhh … writing code? “That’s security!” I could go on, hitting on everything from users to cloud instances and you could fill in the “That’s security!” punchline every time.
That’s a problem. But not in the way you might think. I spent many years thinking I was somewhat unique in that I always rose to the occasion and approached security issues head-on. Most of the organizations I’ve worked for didn’t have dedicated security (I’ve probably written about that before), so some of us rose to the occasion. Nowhere near all of IT, but enough to feel like we were protected.
I now realize that I’m not all that unique; that more of us are doing the “learn security to be secure” thing than are not. I see it in modern organizations all the time. And I think that the real problem is this: Most of these people, like me, did not see themselves as security staff—but they are. Most organizations don’t recognize them as security staff—but they are.
We’ve long harped on cultivating security recruits from this pool, and I’m now going to suggest that you go even further. Make these people part of your planning. If you know that person X on the ReallyCoolApp team is ferreting out security stuff, ask them to just send an email to update InfoSec once a week. Don’t make it a huge burden, and don’t try to force them into a pure security role if they don’t show the aptitude and interest (you really don’t want unwilling security staff) but make use of their talents and drive. Certainly, if this person is doing a good job of making certain ReallyCoolApp is mostly locked down and DevSecOps tools are running against it for a secondary validation, then your limited InfoSec resources can be directed elsewhere.
Replicate this throughout the organization, and “That’s Security!” becomes a benefit rather than a hassle to try to lock down. You already do some of this—since the automation of passwords, most identity management is handled by operations staff, with security merely providing policy and being available to ops if needed. I’m simply suggesting that you expand this type of approach to include every IT department (and some non-IT departments in distributed environments). Don’t recruit everyone to be InfoSec, but recruit them to do a little bit of InfoSec in their area of specialty.
People have always said “Security is everyone’s problem,” which is true, but it’s far too vague to be useful. This is a workable intermediate. “Security is every team’s problem” and recruiting the people on each team most interested in InfoSec to formalize their involvement is a better approach.
And keep rocking it. We need security everywhere, because ne’er-do-wells have made everywhere a part of the InfoSec battleground. So recruit people everywhere without moving them from their current roles/responsibilities. Don’t let the sweet systems you’ve nursed through the years get whacked by attackers when a little recruiting and nurturing will fill the gap.
Encore has made generally available a namesake backend development engine for rapidly building scalable distributed IT environments across multiple cloud platforms.
Fresh off raising $3 million in seed funding, Encore CEO André Eriksson said the Encore platform analyzes source code to eliminate the need to manually configure, connect and set up portable cloud computing environments.
In addition to being able to automatically setup and manage cloud infrastructure based on the metadata surfaced by static analysis tools, Encore provides access to a built-in continuous integration/continuous delivery (CI/CD) platform, previews of environments, live reloads of cloud environments, authentication, secrets management and automatic distributed tracing capabilities.
Eriksson said the development of the Encore environment was, in part, inspired by how developers of games today routinely use an engine to build application environments rather than presenting developers with a set of text-based editing tools to build those environments using low-level boilerplate code that has to be written by developers for each application instance.
Written in the Go programming language, Eriksson said Encore platform is based on an open source Encore Go Framework that prevents IT organizations from becoming locked into an Encore platform that today can be deployed on Amazon Web Services, Google Cloud Platform and Microsoft Azure cloud services.
The building and deploying of distributed applications has always been a major challenge. Encore is designed to automate most of the routine tasks that DevOps teams today need to manually perform for each distributed application they support. As the number of applications being deployed across various cloud computing platforms increases, the challenges associated with managing those environments increase. Encore is designed to enable developers to easily build and deploy application code in a way that can be centrally managed by a DevOps team, noted Eriksson.
It also takes advantage of the concurrency capabilities that the Go language enables to make it simpler to build and deploy distributed applications in a cloud-agnostic manner, said Eriksson. DevOps teams can also employ Go to extend the Encore environment within the boundary of certain limitations, he added.
Essentially, Encore is making a case for an opinionated distributed computing environment that, in return for less flexibility, promises to make it simpler to deploy complex applications. Eriksson said Encore doesn’t see many DevOps teams looking to deploy distributed applications that span multiple cloud services, but they are being required to deploy more applications on different cloud platforms. Each cloud platform a DevOps team needs to support only serves to make the overall IT environment that much more complex to manage, he noted.
It’s not clear to what degree IT organizations are ready to embrace a more opinionated approach to managing cloud computing environments. However, the concept of relying on one is hardly new. Platform-as-a-service (PaaS) environments have been employed for years. However, with the rise of microservices-based applications that are inherently distributed, the issue may soon be forced as IT organizations find simply no other way to keep pace with the rate at which applications are being developed and then continuously extended after they are deployed.
The extent to which software supply chains may be compromised in the wake of a security breach disclosed by GitHub may include thousands of organizations.
GitHub has revealed that unauthorized parties compromised OAuth user tokens maintained by Heroku, an arm of Salesforce that provides a platform-as-a-service (PaaS) environment, and Travis CI, a provider of a continuous integration/continuous delivery (CI/CD) platform. GitHub has since disconnected the third-party applications that were employing those tokens to access repositories but how much any code might have been exfiltrated or, worse yet, modified may not be known for weeks.
“There’s a lot of directions this could take,” said Mitch Ashley, principal researcher for Techstrong Research, an arm of Techstrong Group, which owns DevOps.com. “This is an attack against an authentication mechanism.”
In fact, the full extent of the blast radius of the breach may never be known unless every organization employing Heroku or Travis CI platforms discloses whether their software supply chains were breached. GitHub has also yet to provide any timeline for the extent of the breach, so no one affected yet knows how far-reaching an investigation should be launched or how long it could take to discover malicious code that may have been injected into applications, noted Brian Soby, CTO at AppOmni, a provider of a platform that provides visibility into platform configurations.
“We don’t know yet when this occurred,” he said. “This could have a big blast radius.”
In the meantime, the GitHub disclosure will only intensify security reviews of software supply chains, which have begun in earnest in the wake of a series of high-profile breaches that started with an incident involving an IT service management platform provided by SolarWinds.
In the case of the latest GitHub breach, security professionals are surmising that developers hard-coded tokens into applications accessing GitHub to make it easier to access repositories. “Developers are lazy,” said Demi Ben-Ari, CTO for Panorays, a provider of a platform for evaluating third-party security risks. “They like to take shortcuts.”
Some organizations in the wake of the attack may move to distribute source code across repositories from multiple vendors as part of any effort to better secure their intellectual property, noted Ben-Ari.
Organizations also may decide to rely on code repositories that are not accessed via the cloud. However, given the need to integrate disparate services across a software supply chain, there is no guarantee that an organization with a repository running in an on-premises IT environment wouldn’t be affected by a similar attack.
On the plus side, as more organizations become aware of the threat vector employed to compromise the GitHub repositories, the level of awareness for implementing best DevSecOps practices should increase. The challenge, of course, remains bridging the technical and cultural divides that often result in developers not following best security practices when building and deploying applications. However, as the number of incidents continues to mount, more organizations are beginning to appreciate just how easy it is for the code they are relying on to engage customers and suppliers to be tampered with or outright stolen.
Quali has added a control plane to its Torque platform to give DevOps teams the ability to consistently provision and orchestrate infrastructure across a heterogeneous distributed computing environment.
Amir Rosenberg, vice president of product for Quali, said the control plane allows DevOps team to centrally manage the provisioning of infrastructure via reusable blueprints accessed via a self-service portal, which individual developers can access. That approach eliminates a bottleneck that occurs when DevOps teams manually provision infrastructure on behalf of development teams, he said.
The latest release of Torque also adds enhanced visibility and cost control capabilities such as the ability to set limits for maximum duration and number of concurrent environments and limits for the total cost of an environment. Also included are cost reporting tools for Kubernetes clusters and improved forecasting and resource consumption policies that can be applied to blueprints, sandboxes and spaces.
Security enhancements include new customizable role-based access to blueprints, API Token Controls and integrations with secrets management platforms.
Through its software-as-a-service (SaaS) platform, Quali makes it possible to access Torque via either a cloud account or a user interface that connects to a GitHub account where blueprints are stored. The goal is to enable DevOps teams to maintain some control over how infrastructure is provisioned without impeding developer productivity, said Rosenberg, noting at a time when more organizations than ever are launching multiple application development projects, there is more sensitivity concerning developer velocity than ever.
It’s a fact that infrastructure misconfigurations happen because developers make mistakes. 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 makes it possible to centrally apply policies that act as guardrails to prevent developers from making provisioning mistakes. An alternative to scripts created using tools such as Terraform, the blueprints can deploy complete application environments automatically. That approach also provides more visibility into how resources are being consumed.
Every minute a developer spends managing infrastructure theoretically is one less minute they could be spending writing code. As application environments become more complex, Rosenberg noted it’s becoming that much more challenging for developers to cope with managing infrastructure as code. The issue is that DevOps teams who could provision infrastructure for developers are being 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, which, Rosenberg noted, leads to more mistakes being made.
It’s not clear when or even whether IT organizations will look for an alternative to provision infrastructure in a way that doesn’t rely on developers as much, but most seem to agree that developers have far better things to do with their time.
The interest in Web3 is heating up. We’ve seen major excitement around blockchain and new Web3 protocols that are poised to reinvent the web as we know it. But it’s hard to hide the skepticism and the suspicion that there are ulterior motives behind large cryptocurrency coin fundraisers. There’s no doubt that there are benefits to the Web3 movement — the decentralized nature of Web3 brings innovative forms of shared ownership. Yet, both the marketing hype and investment fervor could get in the way of actual progress in the industry.
I recently met with Netlify CEO Matt Biilmann to discuss the missing piece of Web3. For those who don’t know, Netlify has been a big proponent of the JAMstack movement, a design style incorporating JavaScript, APIs and Markdown (hence, JAM). The headless approach decouples the frontend and backend, enabling easier multi-platform support and other benefits.
According to Biilmann, the theory behind Web3 is exciting and sound and it fits into the headless movement quite well. Yet, in practice, Web3 will require more emphasis on interoperability and open standards, said Biilmann. Without inter-chain portability and better data control, the trend will likely fall victim to the same walled gardens and centralization that underpins the current web. There are some other concerns to keep in mind about Web3 and blockchain, which we’ll explore below.
First off, what exactly is Web3? Well, Web3 is a broad term with loosely-related phenomena, but it can be summed up as a new web designed with decentralized technology and built on blockchains with distributed ownership. “There’s a general sense behind the Web3 movement that goes back to roots of the web as a non-centralized entity,” explained Biilmann.
Whereas in Web2 users were participating in someone else’s walled garden, the concept behind Web3 is that it’s fundamentally open. But how do we make more pieces of the stack a collaborative standard with no single owner? According to Biilmann, this is the aspect that the industry should expand upon.
There’s a lot of speculation. One big issue Biilmann foresees with Web3 is the rampant speculation. The long-term success of new Web3 projects founded on a blockchain is muddled by the fact that the creators wanted people to buy in so tokens rise in value. “How much of the underpinnings of Web3 are actually solving real problems and how much is pure speculative investment?” he asks. It’s not always apparent whether, behind their flashy, chic facades, blockchain solutions solve real problems.
A lack of inter-chain interoperability. A lack of interoperability between the many emerging flavors of blockchain could also pose a risk to this fledgling space. “To what degree are they actually building things around standards with the possibility to move from one player to the other?” asked Biilmann. “We need open standards where you can migrate from one to the other.”
Centralization still exists. No matter what the copy around decentralization said, there will still be players who hold more control and power in a capitalist economy. According to Biilmann, it will be important to make platforms fundamentally open and extendable to avoid creating more walled gardens. He admitted that having strong central providers is not a huge problem as long as these open platforms provided interoperability.
A lack of identity portability. When a person owns a web domain, they can move content around freely from server to server. In a similar vein, Biilmam believes that comparable freedom is necessary for identity within Web3. The ideal is to increase ownership and portability of one’s digital identity. Yet, Biilmann questioned whether blockchain is the best vehicle for that goal, especially as competing blockchain protocols could interfere with portability.
Blockchain will still hinge on the authority of an external source. Another issue is how blockchain will interface with reality. Often, a smart contract will point to a URL for an off-chain context without a strict guarantee of what’s happening outside of the chain. If blockchain must depend on the authority of an external source, this is somewhat counter to the ideals of an interdependent network. “Most of the time, you have to trust a provider between what happens in blockchain and what happens in the outside world,” explained Biilmann. In this scenario, the integrity of the blockchain could end up revolving around a single entity.
Connecting blockchain to the outside world is hard. On that note, the exact process for interfacing with off-chain constructs is still being developed. This usually relies on a third-party oracle model, although some headway has been made to eliminate the oracle concept in favor of a more modern standard for integrating off-chain computations.
Every operation incurs high processing costs. Blockchain requires excessive processing power to accomplish simple tasks, which can be wasteful at scale both in monetary and resource terms.
The benefits of NFTs are greatly exaggerated. NFTs won’t likely help the majority of creators. As Kimberly Parker explained, NFT platform sales data showed “an acutely minuscule number of artists making a vast amount of wealth off a small number of sales while the majority of artists are being sold a dream of immense profit that is horrifically exaggerated.”
NFT scams are common, and since minting an NFT requires exorbitant platform fees, the likelihood of an artist recouping their upfront investment is minimal. “I think that people who stand to gain the most are people like the Winklevoss twins, who are already mega-rich and own an NFT platform,” Cat Graffam said on Time.com. “The biggest losers are the vast majority of unestablished artists that are attempting to break into NFT sales.”
“Let’s not jump to the conclusion that cryptocurrencies and blockchain are the solutions,” said Biilmann. As he noted, people have been tinkering with ways to open up identity and data for decades now. These thinkers may also have relevant insights and alternative solutions that shouldn’t be dismissed or ignored.
For example, Tim Berners-Lee, inventor of the World Wide Web and the HTML programming language, has been spearheading a new initiative called Solid. Solid is a “proposed set of conventions and tools for building decentralized social applications based on linked data.” The project’s goal is to enable true data ownership and better privacy. “If we’re after the goal of an open web, we should be just as curious to know what they’ve been studying for years,” said Biilmann.
We may be seeing Web3 projects excel simply due to the underlying speculative interest in cryptocurrency, Biilmann said, not that they’re technically the best solution or have the best open ownership model. Other solutions include IPFS for high-volume distributed storage. Or, take DNS, the decentralized naming system at the core of the web—”that part of the existing web is already very open and user-owned,” said Biilmann.
“I’m excited about this—personally, I hold no grudge about the tech,” Biillmann clarified. “Making identity and underlying data fundamentally more open is awesome.”
But, at the same time, the space is too speculative and too far removed from building useful things for users, said Biilmann. There is also a pressing need for interoperability and portability in the blockchain industry. And with so much noise driven by the interest in tokens, it could be more beneficial for society to trust a more neutral party in architecting the fabric of our digital lives.
“It’d be a shame if people forget what we can build already,” said Biilmann, pointing to pre-existing technologies like IPFS and DNS. Although these open standards won’t make early stakeholders rich in the short term, they could help get us to that open state even faster.
Web3 is still in an early space. And if we separate currency from this ambition, it could deliver tremendous outcomes. “Let’s figure out how we make identity and data open and not tied to specific walled gardens,” said Biilmann. “That’s something we, as an industry, should work toward.”
ForAllSecure is investing to make open source software (OSS) more secure and is making available free, personal-use versions of its Mayhem application security testing tools infused with artificial intelligence (AI) capabilities to anyone using GitHub repositories.
Company CEO David Brumley said anyone who integrates Mayhem into a qualified GitHub repository being used to build open source software will receive $1,000 as part of the company’s Mayhem Heroes program.
There are now two free, personal-use editions of Mayhem that can be used to analyze code or application programming interfaces (APIs). Those tools are based on fuzz testing technology, which randomly injects data into applications to detect vulnerabilities as part of an effort to automate DevSecOps processes.
In the wake of the discovery of zero-day vulnerabilities in open source software that have impacted enterprise IT organizations, more attention is being paid to how open source software is created, maintained and secured. Many of the developers who build and maintain open source software don’t typically have a lot of cybersecurity expertise, and don’t have the time and resources required to continually remediate vulnerabilities as they are discovered. The Mayhem application security testing tools are designed to make it faster to discover vulnerabilities using AI technologies to reduce the number of false-positive alerts.
It’s too early to say how quickly open source software might be made more secure, but tons of resources are being made available. The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has raised more than $10 million to build tools and define best practices for securing open source software projects. Google has pledged to spend $10 billion to improve open source security. The Biden administration has also made improving the security of open source software used inside (and outside) government agencies by expanding compliance mandates. The White House is also trying to encourage IT vendors and larger enterprises to contribute more to the effort to secure open source software.
The pressure is rising on both developers and consumers of open source software to make sure open source software is secure. However, many open source projects are maintained by a small number of programmers who contribute their time and effort to build components that others are free to use. Many of them argue it is the responsibility of the organizations that deploy that software to ensure the software is secure Many IT vendors and large enterprise IT organizations that rely on that code aren’t contributing anything meaningful back to the project, in terms of either financing or just helping open source maintainers find and remediate vulnerabilities. The irony is many of those same organizations are now assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions.
Microsoft has teamed up with vFunction to make it easier to convert monolithic Java applications into a set of microservices that can be deployed on the Microsoft Azure cloud.
The Microsoft Services Industry Solutions group is making available the Java Refactoring Service, through which IT teams will be able to both lift and shift Java applications to the cloud and then convert them into a set of microservices using agent software and the vFunction Application Transformation Engine, which is infused with artificial intelligence (AI), to analyze Java code.
vFunction CEO Moti Rafalin said the goal is to eliminate the heavy lifting currently required to shift Java applications into the cloud. The vFunction Application Transformation Engine is required because most of the Java applications that were easy to move to the cloud have been, Rafalin noted. The remaining Java applications, he said, have levels of dependencies that make them too complex to move to the cloud without the aid of a static byte code analysis platform capable of parsing more than 10 million lines of code and thousands of Java class libraries.
Once those applications are converted into a set of microservices, it then becomes possible to achieve a level of scale that would otherwise be beyond the reach of any on-premises IT environment, he added, noting the same vFunction platform can be used also to help organizations continuously optimize microservices applications as they continue to evolve in a cloud computing environment.
Longer-term, vFunction is also looking to add support for Microsoft.Net applications that need to be migrated to the cloud, said Rafalin. Many complex Java and Microsoft.Net applications are still running in an on-premises IT environment because organizations are encountering inertia that arises from paralysis of analysis, he noted.
In general, Microsoft continues to gain momentum in its battle for cloud supremacy against Amazon Web Services (AWS). It’s not clear at what rate Java applications are being shifted to the cloud. However, most monolithic applications have components that would be easier to maintain and support as a distinct microservice. In general, organizations are embracing microservices to build applications that are more resilient. In the event a microservice becomes unavailable, requests for services are rerouted to another microservice to make sure the application degrades gracefully, rather than simply crashing altogether. The challenge, of course, is that over time the dependencies that can exist between hundreds of microservices can be more challenging to manage than those of the monolithic application being replaced.
It’s not likely that microservices-based applications with entire replace monolithic applications anytime soon, but the bulk of new applications are being built on top of a microservices-based framework. As such, many DevOps teams are now managing a broad mix of monolithic and microservices-based applications across an increasingly complex IT environment. Less clear is to what degree teams will be able to leverage existing DevOps tools and platforms to build and deploy both types of applications at the scale enterprise IT organizations require.