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: Translating legacy COBOL code to a slightly more modern language, and Arm will go public (again) next month. (more…)
Every once in a while, I think it is important to look at the available technologies and tooling and ask, “What are we trying to do?” In the case of information security, we need to ask, “What, exactly, are we trying to protect?”
The answers to that question are seriously limited. Availability, reputation, data. Since reputation is a business mapping of the other two, that leaves us with availability and data. Of the two, data is more important. Our systems being down absolutely costs us money, but leaking customers’ private data or our corporate secrets, like source code or technology designs, is worse in the long run.
The problem with these observations is that if we are here to protect the data, and data is the more important piece of security, then why do we have far better application security than data leak prevention? Almost all of you have policies and processes to run an application through the wringer and get an “as secure as possible” result at the end. But data? The purpose of applications is to expose it. And in the process, we risk exposing too much of it or allowing tons of it out of a valid endpoint. I remember in the early days of login-based websites, there was a spectacular leak that let an attacker get hundreds of valid user credentials per page submission (there were a surprising number of these for a couple of years there; this one was at a college). We are facing much the same thing via APIs these days or even via pages meant to make access easier for users.
Locking all of this behind logins is a useful step, but to use one of the many phrases we’ve stolen from military science, it is only a part of ‘defense in depth.’
Once it is agreed that data is one of the two key things we need to protect, then the focus should be on how to do so. There are some amazing DLP products, both standalone and integrated into other technologies, that are worth looking into. There are also some great advances in automated response under the guise of AI/ML that should be watched closely because they are changing rapidly. Limiting the maximum number of responses allowed from a query is almost mandatory for application stability and for data leak prevention. And it isn’t that hard to implement.
I assure you that ne’er-do-wells—particularly state-sponsored and corporate espionage hackers, but also amateurs—are using AI to make attacks more successful and less detectable. The least you can do is respond in kind, with some of the tools that can now do things like notify you about low-and-slow data leak attacks.
Keep focused on what the goals are. Reiterate them often, and keep rocking it. That’s a lot of data splashing around the organization that your team is responsible for; make sure it’s as safe as possible.
At its VMware Explore 2023 conference today, VMware previewed what will become a suite of intelligent assistants that use generative artificial intelligence (AI) to automate the management of a wide range of IT tasks.
Krish Prasad, senior vice president and general manager for cloud infrastructure at VMware, said VMware will eventually build out assistants for managing individual platforms such as VMware vSphere and the integrated VMware Cloud Foundation (VCF) platform through which the company aggregates those offerings into a single platform.
VMware is creating those assistants, also known as co-pilots, using multiple large language models (LLMs) that the company uses to train AI models using code written by site reliability engineers (SREs), said Prasad. That approach ensures that the recommendations being made along with the code generated are of the highest quality, he added.
That approach will enable IT teams to identify configuration drift that might be adversely impacting performance or that could create a cybersecurity risk, for example, noted Prasad. The first of those assistants is being made available in beta for VMware Tanzu, a platform based on Kubernetes. VMware is also building an assistant for its NSX virtual networking software that analyzes security events to generate policies and rules that can be applied to firewalls in real-time as threats are identified.
It will then be up to each IT team to decide whether to implement those recommendations. Over time, it’s clear that the management of IT infrastructure is going to become increasingly automated as confidence in those recommendations increases, he added. In fact, the ultimate goal is to fulfill the promise of ‘lights-out’ IT management, said Prasad.
In effect, advances such as these will lead to the democratization of DevOps workflows as it becomes simpler to manage IT infrastructure at scale. IT organizations will be able to invest more resources in building and deploying applications rather than hiring specialists to manage IT infrastructure, noted Prasad.
In fact, the pace at which applications are built and deployed should dramatically increase in the months ahead, Prasad predicted.
The rise of generative AI creates a unique opportunity for IT teams to become more relevant than ever to their organizations. It will soon be possible to build and deploy a wide range of distributed applications capable of processing and analyzing data at the point where it is created and consumed.
While generative artificial intelligence (AI) has captured the popular imagination, it’s becoming apparent that multiple forms of AI will soon be used together to automate DevOps workflows at levels of unprecedented scale.
Machine learning algorithms, of course, are already used by many organizations to automate everything from analyzing log data to identifying security issues to surfacing patterns in tests made using multiple regression, function and unit testing tools. With the rise of generative AI, it is now possible to automatically generate code and create summaries of reports that multiple stakeholders can more easily understand. Generative AI doesn’t replace the need for previous use cases involving machine learning algorithms. Instead, generative AI makes use of a form of deep learning algorithms to create different types of AI models.
As a result, DevOps workflows will soon be invoking multiple classes of AI models to automate workflows in ways that should enable IT teams to automate processes at unprecedented levels of scale.
SmartBear announced today it plans to acquire Stoplight, a provider of tools for editing and governing application programming interfaces (APIs).
Sean Butler, vice president of product management for SmartBear, said the deal, once finalized, will add a set of complementary tools and open source software that extends the core API catalog platform that SmartBear provides to manage APIs. The open source software provided by Stoplight includes Prism, an HTTP mock server that emulates API behavior; Spectral, an API style guide enforcer and linter; and Elements, an API Documentation tool.
The governance capabilities are especially critical as organizations begin to deploy hundreds, even thousands, of APIs that are used to integrate the microservices that are at the core of modern cloud-native applications, noted Butler.
As those applications are deployed, the management of APIs is naturally becoming more challenging. Organizations, for example, might have a different set of rules for APIs that are externally facing than they do for internal APIs. However, it’s not uncommon for internal APIs to be made externally facing without updating them when a new use case is discovered.
SmartBear is advocating a “design first” approach to the building of APIs that ultimately serves to make them simpler to manage, said Butler. In fact, good governance provides the foundation upon which API security can be achieved and maintained at a time when the number of cyberattacks seeking to exfiltrate data via API endpoints is starting to increase, noted Butler.
Unfortunately, too many developers are still prone to building and deploying rogue APIs, many of which turn into zombie APIs that developers forget to remove long after the function they were designed to enable is no longer required.
It’s not clear how many organizations are adopting a design-first approach to building APIs before they write application code, but as more APIs are deployed, the way IT is managed is rapidly changing. Application services are essentially becoming more disposable, so long as the APIs used to expose them to other applications remain stable. In fact, it’s now only a matter of time before most organizations fully appreciate the degree to which their entire IT strategy now revolves around their APIs.
The challenge is that it’s not always clear who within an IT organization is responsible for API management. Although an API is created by a developer, that developer eventually moves on to other projects. Therefore, responsibility for managing and updating APIs often winds up shifting to DevOps teams that were not part of the API development process.
One way or another, the management of APIs will need to improve once legislation that holds organizations more accountable for how data is managed becomes law. The issue that many organizations will soon discover as they move to address those requirements is: A general lack of visibility into both the number of APIs they have and, just as importantly, how they are being employed.
Hopefully, advances in artificial intelligence (AI) will one day soon make it simpler to manage APIs. In the meantime, however, a modicum of governance applied today should go a long way to preventing a problem that otherwise is all but inevitable.
At its VMware Explore 2023 event, VMware today unveiled an orchestration tool, dubbed VMware Edge, that promises to simplify the management of edge computing services at scale.
At the same time, VMware has launched a Project Keswick initiative through which it will work with customers to define additional use cases for VMware Edge based on zero-trust principles and GitOps workflows for deploying applications. The company also unveiled a VMware Retail Edge platform based on VMware Edge and is planning to add additional offerings aimed at specific vertical industry segments.
Finally, VMware is making available a managed connectivity service through which it will provide private 4G/5G wireless services.
VMware Edge Cloud Orchestrator is based on a tool that VMware created to orchestrate the management of its secure access service edge (SASE) platform. That has now been extended to support a wider range of software running on edge computing platforms.
Sanjay Uppal, senior vice president and general manager of service provider and edge for VMware, said the goal is to streamline the management of software-defined edge computing platforms via a single console. Achieving that goal requires the ability to identify and programmatically manage workloads distributed across a mix of networks, he added.
VMware is betting that as more workloads are distributed to edge computing platforms, there will be a greater need to centralize the management of workloads running on platforms that are not always easy to physically access. Less clear, however, is to what degree those edge computing platforms will be managed by IT teams versus operational technology (OT) teams that are usually embedded within a department that manages a specific business process.
However, regardless of who manages those platforms, they will be relying more on GitOps workflows to programmatically provision infrastructure and deploy applications that will need to be regularly updated. In fact, because these platforms are often dispersed across hundreds of physical locations, the need for a pull-based orchestration tool that works asynchronously is critical, said Uppal.
In the longer term, IT teams should also expect artificial intelligence (AI) capabilities to be applied in a way that makes edge computing self-healing, he added.
No one can say exactly how many organizations have adopted GitOps to manage the provisioning of both infrastructure and the delivery of applications, but it’s conceivable that edge computing will force the issue. The tricky part will be finding a way to manage those GitOps workflows at the necessary level of scale. Most DevOps teams already struggle with implementing DevOps workflows at scale, so if more workloads are to be distributed across hundreds of edge computing platforms, there will be a much more acute need for automation to consistently deploy, secure and update applications.
Regardless of approach, however, there may come a day when the number of workloads deployed at the edge far outnumbers the number of workloads deployed in the cloud or in a data center. The challenge and the opportunity now is to get ahead of edge computing issues before they inevitably create a set of management issues that will be more difficult to address after applications have already been deployed.
VMware today integrated its console for managing cloud instances with its VMware Cloud Foundation to streamline the deployment of its software in on-premises IT environments.
Announced at the VMware Explore 2023 conference, the latest edition of VMware Cloud will make it simpler to manage multi-cloud computing environments by combining VMware Cloud Foundation Software and VMware Cloud Services into a single platform.
VMware also announced early access to an ESXi life cycle management cloud service for VMware vSphere+ that enables IT teams to centrally manage upgrades across a distributed vCenter environment. Additional updates to vSphere in the upcoming release include doubling GPU capacity per virtual machine.
Krish Prasad, senior vice president and general manager for cloud infrastructure at VMware, said the goal is to improve the overall pace of innovation; in addition to deploying workloads in on-premises IT environments, organizations are also deploying workloads on multiple cloud computing services.
VMware Cloud is being made available in five editions that can either be managed by an internal IT team, an external services provider or by VMware. In addition, a VMware Ransomware Recovery service based on VMware Cloud is also generally available. Following a breach of an on-premises IT environment, VMware Ransomware Recovery will enable organizations to run production workloads in the cloud until forensics are completed. The company also unveiled a technology preview of cybersecure storage that will integrate recovery workflows with native vSAN snapshots and add support for Google Cloud VMware Engine.
In addition, VMware is adding a managed NSX service delivered via the cloud, dubbed NSX+, that manages instances of the virtual networking software that runs on top of its virtual machine software. There is also now an NSX+ virtual private clouds (VPCs) option that isolates instances of the virtual networking platform.
Finally, VMware is adding a VMware Cloud with VMware vSAN Max, which will make 8.6 petabytes of disaggregated capacity and 3.6 million IOPS per cluster available on demand later this year.
VMware appears to be streamlining the number of platforms IT teams need to acquire to support and manage IT infrastructure at a time when more organizations are trying to navigate increasing economic headwinds.
One way or another, IT teams will need to reduce the cost of IT at a time when IT environments are becoming more complex. VMware is betting that, given its dominance in on-premises IT environments, there will be a natural inclination to deploy more of its software in the cloud to create a more homogenous IT environment that is less complex.
However, it’s not clear whether organizations are willing to pay extra for the privilege. Many organizations are now supporting multiple classes of virtual machines and associated software despite the fact that each additional platform raises the total cost of IT.
In the meantime, many IT organizations are also awaiting the outcome of Broadcom’s effort to acquire VMware before deciding how to centralize the management of multi-cloud computing environments.
In my recent blog, Revolutionizing the Nine Pillars of SRE with AI-Engineered Tools, I indicated that AI can assist work-sharing and incremental technical debt. For example, AI can help analyze code and infrastructure changes to assess their impact on technical debt. In this blog, I explain in more detail how AI-engineered tools can be used to improve the SRE work-sharing and technical debt pillar of practice.
Sharing Wisdom of Production: AI tools like Splunk and Datadog can analyze log files and telemetry data to uncover hidden patterns and trends, improving system understanding and enabling knowledge sharing. Challenges include integrating these tools into existing infrastructure and managing the vast amount of data generated. Clear data governance policies and proper tool configuration can help overcome these.
Collaboration with Development, QA and Security: AI-powered platforms like GitHub and GitLab can automate code reviews, identify security risks and even suggest code improvements, fostering collaboration. Integrating these tools into existing workflows can be challenging, but this can be mitigated by providing proper training and phased integration.
Backlog Grooming: Tools like Atlassian’s Jira, powered by machine learning algorithms, can prioritize the backlog by predicting issue impact, allowing SREs to focus on higher-priority tasks. The challenge is to integrate these tools seamlessly into the workflow, which can be achieved through comprehensive onboarding and training sessions.
Participation in Sprints: AI tools like Tara.AI can predict sprint velocity based on historical data, helping teams adjust their workload. The challenge lies in adjusting to the predictions and estimates provided by these tools, which can be managed by slowly incorporating AI guidance into sprint planning and review processes.
Participation in Testing: AI in testing tools like Testim.io and mabl can automate test cases and intelligently adapt to changes in the system, reducing the time and effort required for manual testing. The challenge lies in selecting and configuring the right AI testing tools for your specific context, which can be mitigated by conducting a thorough needs and gap analysis before tool selection.
Participation in Automation of Environments: AI tools like Hashicorp Terraform can help automate infrastructure provisioning and management. The main challenge is understanding and defining infrastructure-as-code (IaC), which can be overcome with training and leveraging IaC best practices.
Participation in Release Management: Tools like UrbanCode Velocity harness AI to provide insights into the release management process, enabling better decision-making. However, integrating these insights into existing release management workflows can be challenging. Slow, phased integration of AI tooling supported by training can help.
Sharing On-Call Duties and Incident Response Activities: AI tools like PagerDuty and xMatters use machine learning to automate incident response, helping reduce on-call burnout. The challenge is ensuring the AI doesn’t overlook critical incidents due to false positives or negatives, which can be mitigated by continuous tuning of the AI model and maintaining a human in the loop.
Here is a practical roadmap an organization can follow to implement AI tools for SRE work-sharing and technical debt:
Identify the Need and Set Goals: The first step involves identifying the specific areas where AI tools could help in work-sharing and technical debt management. It’s essential to set clear, measurable goals for what you hope to achieve with AI.
Conduct a Gap Analysis: Understand your current tooling and processes and identify where the gaps are. Evaluate how AI could fill those gaps and improve your processes.
Select the Right Tools: Some tools that could be helpful include Splunk or Datadog for data analysis and sharing production wisdom, Jira for backlog grooming, Tara.AI for sprint planning, Testim.io or mabl for automated testing, Terraform for automating infrastructure and PagerDuty or xMatters for incident response. However, the exact selection will depend on the specific needs and context of your organization.
Phased Implementation: Start by introducing AI tools in the areas where they can provide the most immediate benefit. A phased approach helps manage the transition and reduces the risk of disruption.
Training and Support: Ensure your team is trained in using the new tools and understands how to interpret the insights they provide. This may involve external training or bringing in experts to provide in-house training and support.
Measure and Adjust: Continuously evaluate the effectiveness of the AI tools against your initial goals. It’s likely that you’ll need to make adjustments along the way, either to the tools themselves or to the way you’re using them.
Iterate and Expand: Once the tools have proven their effectiveness in one area, you can start to expand their use into other areas of work sharing and technical debt management.
Transforming the way we approach work-sharing and technical debt management within SRE practices through AI can propel teams toward increased efficiency and better outcomes. By leveraging intelligent tools, we can automate routine tasks, predict and manage technical debt more effectively, enhance our decision-making in sprints and deployments and create a more collaborative and insight-driven environment. AI tools such as Splunk, Datadog, Jira, Tara.AI, Testim.io, mabl, Terraform, PagerDuty and xMatters provide an arsenal of capabilities that can revolutionize how we handle everything from backlog grooming to sharing production wisdom and incident response.
Embracing this transformation requires a well-thought-out strategy. A roadmap that begins with identifying needs and goals, conducting a gap analysis, selecting the right tools, implementing in phases, training teams and continuously measuring and adjusting for effectiveness can guide the journey. It’s about ensuring that AI serves its purpose in empowering SRE teams, fostering a culture of shared responsibility and knowledge and, ultimately, improving the reliability and efficiency of our systems. This evolution holds immense potential, and we are just starting to tap into it.
DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.
Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.
Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.
The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.
We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:
Dice.com
FICO
New York, New York
Senior Director of DevOps Enablement
$140,000 to $220,000
Indeed.com
Cisco Systems
Research Triangle Park, North Carolina
DevOps Engineer
$139,000 to $176,000
SimplyHired.com
Candid Health
San Francisco, California
DevOps/Infrastructure Engineer
$121,000 to $154,000
CareerBuilder.com
CACI
Springfield, Virginia
DevOps/Cloud Engineer
$110,000 to $180,000
Cox Communications
Atlanta, Georgia
Lead DevOps Engineer
$105,700 to $176,100
A segment of the community that has embraced open source Terraform software, originally developed by HashiCorp to provision infrastructure as code (IaC), has published a manifesto calling on the company to reverse recent changes made to licenses that determine how the software can be used.
If that demand is not met, the group plans to launch its own fork dubbed OpenTF under the terms of the previous license that governed the usage of Terraform.
Pawel Hytry, CEO of Spacelift, a provider of a platform for orchestrating the management of multiple IaC tools, said the issue comes down to restrictions that Hashicorp has put in place restricting use within platforms that have embedded it, in addition to limitations on how Terraform can be used in production environments.
HashiCorp is shifting from a Mozilla Public License v2.0 (MPL 2.0) to a Business Source License (BSL) v1.1 in all future releases of its software including Terraform, Vault, Consul, Boundary, Nomad, Waypoint, Packer and Vagrant, as part of an effort to maintain maximum control over its intellectual property.
This shift will have a chilling effect on Terraform innovation because fewer individuals and organizations will want to contribute to advancing the tool, said Hytry.
However, Hytry added, historically HashiCorp has not been perceived as not being overly receptive to contributions from external developers, so the bulk of the code used to create Terraform has come from developers working for HashiCorp.
It’s not clear to what degree this firestorm impacts DevOps teams, but the fragmentation of open source projects stemming from issues that come down to revenue streams is increasing as it becomes more difficult for vendors that create open source software to continue to increase the number of subscription services for the support they provide. Red Hat, for example, recently decided to no longer make the source code for the Red Hat Enterprise Linux (RHEL) edition of its operating system available. The decision led to Oracle, SUSE and CIQ pooling their resources to create a fork of RHEL that they promise will be compatible with future updates to RHEL.
It remains to be seen how many vendors might throw their weight behind OpenTF. HashiCorp, in addition to having partners that built the business on the open source edition of Terraform, also has plenty of rivals that offer IaC tools.
It may be a while before this conflict is resolved, but for now, the situation remains fluid, said Hytry. DevOps teams that make extensive use of Terraform will need to monitor events to make sure any future usage of Terraform complies with BSL terms that supporters of the manifesto claim are at this point too vague.
In the meantime, organizations that rely on open source software should brace themselves for any abrupt changes to licensing terms that may be forthcoming in more challenging economic times. In fact, one of the hidden costs of using open source software is the different terms and conditions under which it is licensed. Resources to monitor each additional instance of open source software for compliance, with terms and conditions that are not always as simple or clear cut, need to be dedicated to a task that doesn’t make any meaningful contribution to return on investment.
