Walter Capitani, director of technical product management for GrammaTech, said version 3.0 of CodeSentry leverages the algorithms the company uses for binary software composition analysis to enable organizations to better address software supply chain concerns in the wake of a series of high-profile vulnerabilities.
The tool can be applied to both commercial software and open source components via integration with Risk Based Security’s VulnDB database, created to track security issues.
There is more focus than ever on creating SBOMs in the wake of the Biden administration’s recent executive order that will require federal agencies to only use software that comes with an SBOM. However, most organizations are not provided with access to the source code used within the applications they employ. GrammaTech enables organizations to address that issue by analyzing the binary code within an application to generate an SBOM.
That report not only identifies all the components in an application, it also lists all known vulnerabilities associated with the version of the components being employed, said Capitani. CodeSentry will also list other common software products and the versions that may be impacted by the same vulnerabilities, along with versions of the software that have remediated the issue or versions of a component that have not been impacted by those vulnerabilities.
Almost all software applications include third-party and open source components that create blind spots within software supply chains. In fact, that issue is what makes remediating zero-day application vulnerabilities so challenging; especially when they are discovered in, for example, a log management tool like Log4j that is widely used in Java applications.
GrammaTech is making a case for a binary software composition analysis (SCA) tool that enables DevOps teams to address vulnerability issues prior to an application being deployed in a production environment. At the same time, however, security and compliance teams can now use the same tool to determine the level of risk an organization might be incurring once an application is deployed in production. That latter capability is especially critical because zero-day vulnerabilities are often not discovered until long after an application is deployed in a production environment, noted Capitani.
Regardless of approach, the need to better secure software supply chains is now a major IT issue that should ultimately encourage more organizations to adopt DevSecOps best practices to better secure applications. The challenge, of course, is not just espousing the need for those practices but also providing developers with tools they will actually use to implement those practices. The success or failure of those efforts comes down to not just the efficacy of the tool but also how well it fits within the overall developer experience. After all, the greatest tool in the world will still languish if it’s too difficult for the average developer to employ.
The use of APIs and microservices is increasing—a recent study from F5 estimated that the industry is approaching 200 million total APIs. As organizations expand their use of APIs and microservices, they inevitably require some form of service management architecture. There are primarily two major design options for implementing this: An API management system or a service mesh.
The key distinction between API management and service mesh can be framed using the four cardinal directions. API management is typically adopted for REST services that face external developers—referred to as north-south traffic. On the other hand, service mesh is more commonly used by internal suites of microservices to help control lateral, or east-west, communication. There are more nuances between each, as we’ll cover below, but this is essentially how they’re adopted in practice.
I recently chatted with Mark Cheshire, director of product at Red Hat, about the emergence of both API management and service mesh. According to Cheshire, both approaches accomplished similar goals but evolved very differently. Below, we’ll revisit why these two paradigms emerged and compare and contrast them. In a separate article, we’ll consider when it’s best to integrate them both.
What is API Management?
API management is most often associated with north-south traffic. By exposing your API to the outside world, you enable other developers to connect it to their systems and leverage your data and functionality like building blocks.
API management arose in response to the rise of web APIs. API management is a broad concept encompassing many functions required to expose an API endpoint to the outside world. This can include authentication, authorization, request routing, documentation, rate limiting, monitoring, logging, monetization and life cycle management. A key goal is to make integration easier for the developer consumer. Architecturally, API management follows a gateway pattern. Consumers issue requests to the gateway which then performs routing to the underlying services.
For APIs, the big catalyst was the emergence of Web 2.0, Cheshire explained. Numerous startups began consuming RESTful APIs to connect their web properties and partner ecosystems. Companies also found REST APIs to be a much more straightforward integration approach than SOAP and SOA. They also saw the ease-of-use benefits and adopted API-first designs within their internal infrastructure.
As of 2021, over 70% of APIs are built for internal use. So, do all these services need API management? It depends. “If you communicate externally, you need API management,” explained Cheshire. But, it’s a grey area for services within an enterprise, he says, though inter-domain traffic often could benefit from API management.
A diagram of API management capabilities, from 3scale
Strengths
Can enable north-south traffic
Protects the boundary of an application
Designed to ease external developer consumption
Potential for monetization, subscription plans
Typically plug-and-play; easier to support
Many solutions on the market
Developer experience and docs
Analytics and reporting
Weaknesses
May be heavier than service mesh
Fewer open source options; vendor lock-in
Analysis paralysis in comparing solutions
What is Service Mesh?
Service mesh is most often associated with controlling east-west communication between internal services. Service meshes like Linkerd, Istio and Kuma make it easier to reimplement similar logic—such as networking, observability, traffic management, security policies and routing—across many microservices from a single control plane.
Service mesh was born to address slightly different challenges than API management. “The transition from monolithic to microservices is all about east-west traffic,” Cheshire said. Companies found it slower to innovate monolithic applications and thus broke them up into microservices that communicate via APIs. But these microservices all needed similar operational capabilities, which would be cumbersome to repeat over and over for each service.
“For one monolithic app blown into microservices, you may not even need a service mesh,” said Cheshire. “However, when you have hundreds or thousands, that’s when applying service mesh becomes critical.”
Istio service mesh architecture
Architecturally, service mesh is typically divided into a data plane and a control plane. The service mesh deploys a sidecar proxy that sits alongside each individual service. Istio, for example, utilizes the Envoy proxy. Other meshes like Linkerd use their own proxy.
Strengths
Fits the microservices architecture paradigm well
Good for traffic routing; improving resiliency
NIST-recommended architecture for achieving zero-trust
Requires filter chain add-ons for north-south abilities
Comparing API Management and Service Mesh
API management is predominantly aligned with externalizing APIs to partners. When you do so, maintaining the contract with a consumer is more important to meet SLAs. Thus, API management commonly delivers life cycle management abilities, such as versioning. API management is necessary even if you are exposing a single API, as this service needs to be adequately documented and secured. That being said, these tenants can also be relevant to developers reusing software within an organization—there’s something to be said for adopting a product mindset when dealing with internal APIs.
On the other hand, service mesh is more aligned with controlling internal networks. Microservices are rarely deployed alone; typically, multiple microservices make up an application. And, many more might exist throughout an organization for unique purposes. Service mesh thus helps maintain consistency throughout large networks of decoupled microservices. Service mesh is also a rapidly growing field, experiencing an explosion of new development and production use. A Cloud Native Computing Foundation (CNCF) report found that service mesh use rose in production by 50% in 2020 alone.
To put the comparison another way, William Morgan, CEO, Buoyant described how API management is more about business logic, whereas service mesh handles intra-cluster operations:
“API gateways typically handle ingress concerns, not intra-cluster concerns, and often deal with a certain amount of business logic, e.g. ‘User X is only allowed to make 30 requests a day’. By contrast, a service mesh like Linkerd is focused on operational concerns (e.g. instrument these calls and report their success rate; secure this communication between these pods) and purposefully avoids the mixing of business and operational logic; and focuses on communication between the services on the cluster.”
Though service mesh and API management achieve slightly different aims, both layers make it easier to reuse web-based services. And, they certainly can be used in conjunction. For example, you could build API-first microservices with service mesh and simultaneously use API management to expose certain domains. In another article, we’ll consider when it’s best to integrate the two technologies.
In 2022, federal agencies are estimated to spend $7.8 billion on cloud computing. While this spending on cloud computing is necessary, it’s imperative that the government uses its allotted funding appropriately to leverage the cloud’s full potential and avoid common pitfalls.
Avoiding Common Cloud Adoption Pitfalls
I’ve frequently witnessed government agencies get locked into a cloud reseller that doesn’t give them the full capabilities offered by AWS, Google Cloud or Microsoft Azure. Most people outside of the federal market don’t realize that the government does not buy cloud directly from the cloud providers—apart from some very large contracts like the upcoming JEDI replacement contract vehicle, JWCC. They buy through a network of reseller partners that offer volume discounts and try to bundle managed services to help with cloud management.
This approach gives the reseller, not the customer, the power to hold the keys to their kingdom—and can make it difficult for the customer to easily switch between cloud providers in the event of poor performance, lack of access or billing transparency. The federal government would benefit from keeping a small, but purposeful, cloud project management office (PMO) in-house. Thus ensuring that root access is available to all the accounts, subscriptions and projects to provide freedom to the agency to more easily change partners as their cloud maturity evolves.
I’ve also seen government customers unfocused on the holistic end-user experience of actually using the cloud. The result is fragmented collections of different systems, processes and steps that cause engineers to be frustrated and inefficient. Customers must transform the end-to-end cloud provisioning process so that self–service is paramount and existing technology investments are seamlessly and transparently integrated to the end-user. When done correctly, innovation will be the byproduct, because focus can go towards developing the next generation of mission systems and tools—rather than trying to determine how to get a cloud account to begin a project.
Three Steps Government Agencies Can Take to Get Value from Cloud Infrastructure
Challenges exist, but there are proven steps the government can take to get the most value from their cloud infrastructure.
Define purpose: First and foremost, understand the purpose the cloud infrastructure intends to serve. Are you looking to reengineer cloud architecture, become more cost-efficient, or transform the innovation potential within your organization by introducing new services that can take you farther, faster? Understanding this purpose and your goals will go a long way towards success.
Quantify ROI: To get the best return on your investment, understand what resources are already available and which are necessary for your operations. To fully take advantage of the cloud, it is important to make sure basic costs are under control, such as ensuring AWS EC2 or Azure VM instances are not overprovisioned or underutilized. It’s equally important to make sure you take advantage of reserved capacity reservations for your predictable workloads; these can save you 30% or more. Last but not least, keep a focus on fully leveraging technology solutions to help bring all the pieces together in an integrated user-friendly experience across cloud providers.
Consider the outsourcing approach: Bringing in cloud resellers and contractors can provide guidance to your organization and help you make better choices. Just like building or renovating a house, agencies need general contractor-type companies that can help to manage and orchestrate the process of migrating to the cloud and all of its moving pieces. These contractors can also help to locate the various specialists required to get the job done for each unique situation. Long term, having a small, efficient cloud PMO is something every agency should strive to have in-house; however, given the demand for cloud engineering talent, the near-term focus should be to ensure flexibility into engagements with partners, so that they don’t hold back the potential of the organization.
As digital transformation and cloud migration continue, it’s important for the government to stay on pace with its adoption. As of now, most agencies are still relying on manual steps to validate controls and get Authorizations to Operate (ATOs) approved. Making the simple swaps to more automated processes, learning how to leverage cloud resources to their full ability, and outsourcing operations to contractors can make acceleration easy. There has never been a greater need for cloud enablement. The time to scale up is now.
Faster integrations. Accelerated software delivery. Elevated user experiences. These are only three of the benefits organizations gain by incorporating low-code platforms, apps and solutions into software development and business process management.
Low-code platforms aren’t new, but demand for the technology soared in the last two years as companies were challenged to meet stakeholder demand for more digital transformation. With low-code tools, companies find they can expand digital transformation efforts through faster business application delivery. In addition, the time it takes to innovate is dramatically reduced with low-code tools.
Low-code solutions are no passing trend. In their recent report on global cloud revenue, Gartner predicted that by 2025, the use of low-code and no-code will “nearly triple,” adding that “70% of new applications developed by organizations will use low-code or no-code technologies, up from less than 25% in 2020.”
Low-code solutions give organizations the ability to produce working solutions and integrations with more speed and agility than more traditional on-premises development. Integration used to be a labor-intensive IT process requiring custom development on both sides of the integration. As more organizations adopt a “buy versus build” approach to software development, they are turning to self-service and other solutions with “out of the box” functionality to increase speed and efficiency. In addition, the vendor-developed components of low-code tools also offer a better user experience.
Rising Demand for Low-Code, Platform-based Solutions
As organizations expand their product and service offerings, the demand for low-code, platform-based solutions will increase. SaaS and PaaS solutions with a low-code focus can be effective for organizations looking for accelerated functionality. Often these tools include pre-built models and templates that businesses can quickly implement and easily duplicate for flexibility and versatility.
The ability to create seamless integrations with other applications is a must. Best-of-breed low-code platforms enable intelligent integration between multiple applications using graphical user interfaces (GUI) as well as industry-standard interfaces such as JSON and APIs within vendor-supplied environments. Intuitive visual user interfaces and drag-and-drop features allow businesses to customize the solution to meet their needs and preferences.
But along with ease of use and rapid functionality, organizations must look for low-code tools with security built-in.
Security: A Priority for Low-Code Tools
Security must be a top priority for organizations using low-code tools in any capacity, from using a low-code platform for application development or using a no-code SaaS solution for business process automation.
Anytime an organization introduces outside applications or any third-party API integration to an environment, the organization is entirely dependent on the vendor’s security implementation. This is especially true when combining various solutions to create a unified product or service. If the vendor doesn’t take security seriously, other parts of a solution could be exposed to risk because of a weakness in another area.
Problems can get in either intentionally or unintentionally, as demonstrated with the recent Apache Log4j vulnerability. The bug in this commonly used routine was found to have massive potential for cybersecurity attacks. As CNET cautioned, “The vulnerability in the widely used software could be used by cyberattackers to take over computer servers, potentially putting everything from consumer electronics to government and corporate systems at risk of a cyberattack.”
Ways to Remedy Security Risks of Low-code Tools
Organizations can’t make assumptions about the security of every tool, solution or platform they bring into their environment. They must complete their own due diligence for security in the software development pipeline or any time a 3rd party app or tool is introduced.
One critical step to addressing security is incorporating DevSecOps and shifting security left in the software development pipeline. The Log4j vulnerability put the need for DevSecOps in the spotlight. Taking a shift left approach and implementing security earlier and more often in the DevOps process can help to catch more potential vulnerabilities. It’s critical to introduce DevSecOps early in the development cycle, or organizations risk missing a bug or vulnerability. In the development cycle, security isn’t an antivirus scenario; all code must be scanned for vulnerabilities.
Organizations also need to employ due diligence when exploring options and solutions to bring into their environments. Look for solutions with security at their core. Before integrating any low-code solution, examine the vendor’s approach to security.
Some security measures to look for when considering vendors or solutions include:
All communications should utilize at least TLS 1.2 (transport layer security) and comply with industry standards for certificates and encryption keys.
All hashing should be using current accepted standards with HMAC, they should be enforcing security rules on passwords such as only storing password hashes and requiring 2FA if they interact directly with customer accounts.
Low-code platforms and tools have the ability to accelerate digital transformation efforts without having to rely on hand-coded, on-premises solutions. The potential for time savings and cost savings is significant, but it’s important for organizations to ensure they’re not compromising security when choosing solutions.
It is difficult to find a single area of the technology landscape that isn’t incorporating artificial intelligence (AI) into products and services. As we move into a world where distributed computing is the norm for business operations, AI is a requirement given the increasing level of complexity in computing environments. While there are many different ways AI is penetrating computing, I think that there are a few specific areas where we will see a huge amount of growth in terms of innovation and investment.
AIOps will be at the forefront of monitoring and managing distributed computing environments.
2022 will be a busy year for AIOps vendors and product offerings. Expect that, in 2022, you will see a massive number of large enterprise software companies bringing AIOps offerings to market—either as part of distributed computing management suites or as individual tools. In addition, there will be a flurry of well-funded startups entering the space. One of the first areas where AI models are productized is in the area of AIOps. AIOps provides the ability to apply machine learning models and automation based on data about the patterns and anomalies within IT operations. AIOps is an implementation of observability and helps businesses monitor and manage their IT environment based on collecting and managing data about operational patterns that are expected and correct. It also determines when there is an action that is outside of the norm, and provides either an automatic correction or offers IT operations management the ability to correct errors before they impact business operations.
Expect a year of consolidation in advanced analytics, security and solution clouds.
We’ve already seen 2022 kick off with a flurry of acquisitions. While we haven’t seen blockbuster buys, we have seen smaller acquisitions by big vendors that need more to sell their existing customer base. One exception is Alteryx, which purchased cloud-native analytics vendor Trifacta for $400 million in cash. In contrast, IBM recently purchased Envizi, an Australian data analytics firm focused on analytics for environmental, social and governance (ESG) requirements. This is just the beginning. We expect there to be a flurry of acquisitions in the hot observability market (solutions focused on analyzing how well the internal states of a system can be inferred from knowledge of its external outputs).
As security continues to grow in importance, key emerging security vendors also will be hot commodities in the acquisition space. For example, Microsoft has acquiredRiskIQ, a security software vendor focused on gathering threat intelligence about a wide range of cyberattacks across multiple public and private clouds. We also predict that many of the large cloud vendors will move aggressively to buy cloud business solutions.
Looking Forward
It is easy to get caught up in the flurry of announcements and acquisitions coming at us fast and furious. However, the reality is that businesses need to know that whatever new shiny objects are introduced, these solutions need to be able to solve real customer problems that impact revenue and growth. It may sound obvious, but I think that vendors need to pay a lot more attention to customer pain.
Change is constant and inevitable. While some changes are welcome, others are just a necessary evil.
Continuous calls for digitalization combined with a pandemic-prompted emphasis on transforming business operations, force organizations across industries to modernize their legacy systems. The emergence of cloud computing has shrunk organizations’ on-premise IT footprints. However, with 96 of the world’s largest 100 banks, 90% of the world’s largest insurance companies, 23 of the 25 largest retailers in the U.S. and 71% of the Fortune 500still using mainframe systems, any modernization efforts—resulting in increased risk of downtime or defects—will frequently lead to disastrous consequences.
So, while making changes can be expensive, uncertain, and lead to customer loss and/or embarrassment in the marketplace, modern business demands that systems change to continue to deliver value. The problem with mainframe modernization, however, is that today’s code search tools, linters and program analysis tools are deficient when it comes to mitigating the risks associated with maintaining and improving systems.
Modernization: A Knowledge Problem
With10,000 mainframes in active use globally, the average organization annually spends anywhere from60% to 80% of its IT budget just on maintenance. But, as experienced and proficient programmers retire or move on, many companies are realizing that the specialized domain knowledge of the industry and institution that those developers used to create and update these complex critical systems is walking out the door with them.
As the developers who originally wrote the code have long since moved on, and documentation leaves a lot to be desired, developers new to a system are unable to acquire comprehensive knowledge of the system’s functionality, at a detailed or fast enough level, to become adequately productive and proficient. That lack of speed comes with significant risk and cost to any organization.
Recognizing the full and true intent of the functionality written in code is not simple. Developers today spendroughly 75% of their time searching through source code, to identify the code representing the functionality that needs to be changed. Complicating matters further, understanding the code is not enough. To effectively and efficiently maintain and support any system, software developers must know precisely what an application actually does—and how altering code in one part of the system impacts it as a whole. But since the code representing a behavior that needs to be changed can be littered throughout the system, developers might think they’re making a simple tweak, when really they may be breaking the entire system (and not even knowing it). The risk of change resulting in unintended consequences is real.
All of that being said, how can developers improve their efficiency and effectiveness?
The Shortcomings of Today’s Tools
With code repositories growing unchecked over time to extraordinary sizes, those responsible for maintaining and preserving a system’s functionality say it’s becomingincreasingly challenging to find bugs in code without machine assistance. And with debugging being an arduous, time-intensive endeavor, developers are increasingly turning to code search tools, linters, and static and dynamic analysis tools to analyze millions of lines of code, flag errors and suggest fixes.
Whether the tool excels at bug localization, code visualization or “error” detection, entirely too many tools are insufficient when it comes to actually identify the specific lines of code that require attention. Program analysis tools only illustrate code in ways that developers still have to interpret (potentially incorrectly) and draw their own conclusions. While code search tools might speed the rate at which developers can build a mental model of the code, such tools are notorious for false positives, and developers still have to undergo the mentally challenging endeavor of piecing that mental model together to identify the code, and then safely make changes. Worse yet, code completion tools—tools that less-experienced developers disproportionately rely on—can actually propose imprecise changes (one prominent tool offers incorrect code 71% of the time), and that introduces risk.
The cherry on top of this problematic sundae is that today’s tools don’t have any way to effectively validate the scope and accuracy of a proposed change. The influence of a suggested change can be tough to identify, so testing for comprehensive validation is frequently next to impossible.
Ideally, there has to be a better way to mitigate risk while making changes to legacy systems. Enter artificial intelligence. By employing a unique approach to AI, the code repository truly becomes a knowledge repository, enabling many capabilities unrealized before now.
A Developer’s AI-Enabled Accessible Knowledge Repository
By leveraging AI to automate the identification of the specific lines of code that require attention, developers can simply ask this AI-driven knowledge repository where behaviors are coming from—and quickly identify the code associated with that behavior. This puts AI squarely in the position of intelligence augmentation, which is key to leveraging its capabilities.
This novel approach of AI reinterprets what the computation represents and converts it into concepts, therefore “thinking” about the code in the same way humans do. The result is that software developers no longer have to unearth the intent of previous developers encoded in the software to find potential bugs. Even better, developers are able toovercome the inadequacies of automated testing by using AI to validate that they haven’t broken the system before they compile or check in the code. The AI will forward simulate the change and determine whether it’s isolated to the behavior under change. The result is the bounds of the change are confined to the behavior under change so that no unintended consequences arise.
While AI is not yet advanced enough to safely make changes on its own, it can serve as a knowledge repository with the added capability of directing developers precisely where to make any needed changes. With AI, programmers—even on their very first day on the job — can make any necessary fixes with confidence that they won’t break the entire system.
Unlike its code search, code navigation, code completion and program analysis tool counterparts, AI fundamentally empowers developers to safely, efficiently and effectively make any necessary changes. With AI — that is fortified by a knowledge repository that understands source code the same way a human does — developers can truly do more with less.
As 2022 kicks off, it’s becoming apparent that the major DevOps challenge organizations will face is mastering best practices that enable continuous delivery.
A global survey of more than 19,000 software development professionals conducted by the Continuous Delivery (CD) Foundation found 44% of respondents use either continuous integration or deployment. However, less than one in five (18%) use both practices to automate the entire software delivery life cycle. Continuous integration is currently the most popular DevOps-related activity (32%) followed by continuous deployment at 29%, the survey found.
The survey also found that only 14% of respondents said, on average, that they can go from code checked-in to successfully running that code in production in one day. Just 10% said they routinely deploy code to production each day. Nearly a third of respondents said they still manually approve code deployments to production.
Tracy Miranda, executive director for the CD Foundation, said it’s clear there is a need for a better understanding of continuous delivery as a distinct DevOps discipline that stands apart from continuous integration processes. While the two DevOps practices are complementary, she noted that continuous delivery requires a level of engineering expertise that many developers either lack or are simply not interested in gaining.
In fact, the survey found more than a quarter of respondents (26%) are not involved in DevOps-related activities at all. At the same time, however, the survey revealed that 80% of respondents that work for companies with two or more employees are involved in DevOps to some degree. Nearly 60% of enterprise developers that participated in the survey employ a continuous integration/continuous delivery (CI/CD) platform, as opposed to 48% of developers working in small businesses and 42% of contractors. However, it’s clear from the survey results that much of that activity is focused on continuous integration rather than continuous delivery.
The survey revealed, for example, that less than a quarter of respondents (23%) are involved in infrastructure provisioning and management at all. That compares to nearly a third (32%) that are involved in application and infrastructure monitoring. Only 20% are involved in creating automated tests, Collectively, the survey results make it clear there is still a long way to go in terms of shifting responsibility for DevOps practices further left toward developers.
One reason continuous delivery is so challenging is that automating deployments across platforms has never been especially easy. Each platform tends to be customized to the point where it is difficult to automate application deployments. In effect, each platform is its own unique type of “snowflake.”
However, with more attention focused on the integrity of software supply chains in the wake of a series of high-profile breaches, Miranda noted that automating software delivery will play a major role in achieving automation goals by reducing the need to rely on manual processes that are more easily compromised.
At the same time, more organizations are starting to embrace Kubernetes clusters—this can simplify automation of software delivery across a set of platforms that all share a common application programming interface (API), she noted.
The growing complexity of application development projects, coupled with increased reliance on software to drive digital business transformation initiatives, will also accelerate the adoption of continuous delivery best practices, added Miranda.
One way or another, application deployment in 2022 is shaping up to be a lot more automated than it was in previous years. The only thing left to be determined now is the degree to which that goal can be achieved.
Almost all companies are modernizing their IT infrastructure to remain competitive, with the focus firmly on migration to the cloud and the use of dynamic infrastructures. In a recent Trends in IT Ops 2021 survey, more than 160 IT professionals were asked how the implementation of IT strategies affected their day-to-day work. The results provided an impressive insight into the current work priorities of system administrators and IT Ops in general.
According to the survey, most administrators believe that monitoring cloud (79%) and container (73%) environments will take on a more important, or much more important role for them in the future. Additionally, 59% of those surveyed agree that their job role has evolved over the years due to cloud computing and containerization.
Not all IT Teams are Equal
However, the data also shows that the changes are not affecting every IT team equally. For example, 37% of all respondents say that cloud solutions are not relevant—or less relevant to them on a day-to-day basis. This response shows that on the one hand, system administrators see cloud computing as an essential topic. However, on the other, the impact in practice is not felt to the same extent by every administrator. These responses show that not every administrator has to deal with cloud platforms on a day-to-day basis, with some being ‘siloed’ into dedicated teams that may not interact with the broader corporate cloud strategy. In addition, not every organization has fully committed to the cloud, with some finding their migration hindered by applications that are not suited to cloud migration.
In the survey, 45% of respondents also said they believe the importance of monitoring physical infrastructure will not change in the next few years. However, 43% believe that monitoring physical systems will become more important or much more important. Conversely, a mere 1% replied that they thought physical infrastructure monitoring was less critical.
Taken together, these responses demonstrate that, despite the excitement around the cloud, many organizations take a hybrid approach to infrastructure. IT Ops and administrators recognize the importance of monitoring cloud systems and dynamic assets while, at the same time, the monitoring of local systems remains relevant or is even expected to gain in relevance.
Network Management and Automation
Cloud and containers enable faster growth of IT environments and promote digitalization. However, they also lead to a sharp increase in data traffic and more complex networking of systems. As a result of these changes, the demands on local networks are growing. This increasing demand demonstrates the importance of network management tools. 81% of respondents said that solutions in this area are relevant, or very relevant to them in their day-to-day work.
This year, the move to a home office joined the trend towards migration to the cloud, containers, and network monitoring. In the wake of the COVID-19 pandemic, many IT departments had to adapt their infrastructure to allow employees to work from home offices. However, most administrators were relatively stress-free, with 54% saying they had no trouble adapting infrastructure to meet remote work requirements.
Automation is also a key issue. For example, 81% of all respondents say projects that deliver deployment and configuration automation have been relevant in their organizations in the past 12 months. In addition, 92% say that automation tools are relevant, or very relevant to them on a day-to-day basis.
Cloud, Containers and COVID
The Trends in IT Ops 2021 survey shows that system administrators are concerned with cloud computing and containers and several other topics. In addition, most administrators recognize the increasing importance of monitoring cloud environments and containers. That said, administrators continue to see monitoring networks and other physical infrastructure assets as critical, and some system administrators see increasing importance in monitoring this vital area.
In addition to the topics outlined here, respondents also provided feedback on topics such as virtualization, application performance monitoring and network management.
Colors.js is an npm that has been downloaded more than 3.3 billion times, with more than 19,000 projects depending on it. Faker, meanwhile, has been retrieved 272 million times, with over 2,500 projects depending on it. Colors.js enables organizations to print colorful text messages on the console, while faker is used to generate fake data for testing applications. Developers that pulled a recently published Colors.js version found their applications caught in an infinite loop, printing ‘LIBERTY’ ‘LIBERTY’ ‘LIBERTY’ followed by a sequence of gibberish non-ASCII characters. Functional code, meanwhile, was also removed from Faker.
Ax Sharma, senior security researcher for Sonatype, a provider of an open source software security platform, noted these actions occurred in the wake of the series of zero-day vulnerabilities that impacted the widely used Log4j logging tool for Java applications. Sharma first reported the update issues with Color.js and Faker.
The small team of contributors that work on the Log4j project found themselves creating multiple updates to the package to address vulnerabilities of varying severity on the common vulnerabilities and exposures (CVE) list. There is some debate, however, over how many of those vulnerabilities warranted a CVE listing given their severity, said Sharma.
That issue has now emerged as a flashpoint for contributors to smaller open source projects. These contributors contend that larger organizations are taking advantage of their efforts without making any substantial contributions to a project in return, much less compensating any of the contributors for their time and effort. The recent updates made to the npms are, essentially, a protest statement, explained Sharma.
It’s not clear whether other contributors to small open source projects might follow suit, but the debate over the sustainability of these projects has become heated. Many contributors to open source software assume that the organizations who use the free software they created should assume responsibility for securing it. That “user beware” approach to security is understandable for contributors that are not compensated for their efforts. However, when asked to patch open source projects used by billion-dollar organizations—and do so on an urgent, emergency basis—the resentment among those volunteer contributors rises sharply.
Fortunately, some effort is being made to address these issues. The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, raised $10 million to help maintainers embrace best practices and better protect open source projects from malicious code. Google has pledged $1 million to help open source developers adhere to National Institute of Standards and Technology (NIST) guidelines in response to the Biden administration’s recent executive order on cybersecurity. Administered as a pilot program by the Linux Foundation, that effort is part of a larger $10 billion commitment that Google previously made to open source security.
White House national security adviser Jake Sullivan also recently sent a letter to major software companies and developers inviting them to discuss initiatives to improve open-source software security. The first step is a one-day discussion this month hosted by Anne Neuberger, the deputy national security advisor for cyber and emerging technology. In the letter, Sullivan specifically noted that while open source software has accelerated the pace of innovation, much of it is maintained by volunteers. This is now a key national security concern, he noted.
It’s not clear how this emerging open source sustainability crisis will play out. However, DevOps teams might want to consider how dependent they are on open source projects whose contributors might have issues with how their work is being exploited.
LitmusChaos is a chaos engineering platform donated to the CNCF by ChaosNative in 2020. Since then, it has seen adoption within production environments by more than 25 organizations, including Intuit, Lenskart, Orange, Red Hat and VMware.
ChaosNative CEO Uma Mukkara says LitmusChaos was developed to provide DevOps teams with a chaos engineering platform built using containers that makes it easier to scale up and down than existing monolithic alternatives. The platform itself, however, can be used to test both monolithic and microservices-based applications.
The platform consists of a Chaos Operator based on a software development kit (SDK); a ChaosHub for hosting and sharing experiments; Litmus Workflows that declaratively chains experiments (either in sequence or parallel) to build a chaos scenario; a centralized control plane, dubbed ChaosCenter, to design, schedule and monitor Litmus Workflows; Litmus Probes for creating chaos scenarios that automate steady-state validation and remediation actions and a Chaos Observability tool to export Prometheus metrics.
In total, there are now more than 400 contributors to the LitmusChaos project and more than 4,000 pull requests have been made. Mukkara said since the beginning of this year, Litmus operator installations have grown to more than 2,000 per day. Going forward, the goal for 2022 is to significantly increase the number of LitmusChaos integrations there are for a wider range of DevOps platforms, added Mukkara. Additional sets of experiments for Kubernetes and non-Kubernetes targets, improved observability and integration with other platforms—via the open source OpenTelemetry agent software also being advanced by the CNCF—is also planned.
In general, it’s still early days as far as the adoption of chaos engineering with DevOps workflows is concerned. However, Mukkara said that as more organizations embrace observability to better understand IT processes, the number of organizations that also use chaos engineering to test IT resiliency should also increase. In fact, as IT environments become more complex—thanks mainly to the rise of microservices-based applications—chaos engineering approaches to testing may someday be required, noted Mukkara.
In the meantime, there are still a lot of IT professionals that are uncomfortable with chaos engineering approaches to testing that deliberately break underlying services to test the resiliency of an application. The core idea, however, is that no application should have a single point of failure that could lead to it becoming unavailable. In theory, a microservices-based application won’t fail because when a service becomes unavailable calls are automatically rerouted to another service. The performance of that application will degrade, but it won’t go offline. The challenge is that building an application that achieves that level of resiliency using microservices requires a significant amount of DevOps expertise.
Regardless of how an application is constructed, the one thing that is clear is how dependent organizations are on applications to drive revenue. As such, the tolerance for application failures—or performance degradation—has never been lower.
