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: Redmond SaaS keeps failing, RISC-V is RISEing, and Meta is enforcing hybrid work. (more…)

PagerDuty has signaled its intention to add generative artificial intelligence (AI) capabilities to its cloud platform for managing IT operations via integrations with large language model (LLM) providers that it will disclose at a future date.
These capabilities will make it possible to invoke natural language via PagerDuty Operations Cloud to automatically generate status updates, create drafts of incident postmortem reports and even co-author workflows in any programming language to automate remediation of an issue.
Damon Edwards, senior director of product for PagerDuty, said as AI continues to evolve, the goal will be to minimize the need for human involvement as much as possible. That doesn’t mean there won’t be a need for humans to be involved, but it does mean that many rote tasks associated with managing an IT incident can be automated, he added.
For example, the reports that are run to determine the root cause every time there is an incident can be automated, noted Edwards. In addition, summarizations of status reports or postmortems after incidents were resolved can be made readily available to any member of an IT team on demand, he added.
Those capabilities will also make it easier to onboard new members to an incident management team as required, said Edwards. Today, it’s difficult to add new members to a team after an incident has unfolded because it takes time to bring them up to speed, he noted.
In addition, generative AI also makes it easier to capture a lot of the tribal knowledge within an IT organization that would otherwise disappear when staff either leave the company or shift roles, said Edwards.

The generative AI additions to the PagerDuty platform extend an artificial intelligence for IT operations (AIOps) capability that PagerDuty made available this spring. The PagerDuty AIOps platform leverages the data model embedded in its incident management software to reduce the amount of time required for an AI platform to learn how an IT environment operates and begin surfacing valid recommendations to optimize workflows.
It’s not clear at what pace AI will be adopted within enterprise IT organizations, but it is rapidly becoming pervasive. Each DevOps team will need to decide the degree to which they can rely on AI to manage IT processes, but as IT processes become more complex, there is a clear need for AI to navigate all the dependencies that exist in an IT environment. As more routine tasks are automated, however, there will also inevitably be a realignment of roles and responsibilities within an IT organization. The overall goal is not so much to eliminate IT staff as much as it is to enable them to manage IT environments at a much higher level of scale.
In the meantime, DevOps teams need to plan for not only what is possible using generative AI today but also tomorrow. After all, there’s not a lot of point in training someone to take on a new task if that task is automated a few months from now.

The DevOps sector is still in urgent need of new talent, with 38% of tech companies stating that they struggle to find skilled developers in 2023. These same respondents named DevOps as the number-one area where they are feeling the pinch. Because of this, businesses must ensure they prioritize and nurture the right set of core skills when building DevOps teams.
Below, we discuss the key qualities that businesses should look for when taking on new DevOps engineers and what leaders can do to get the most out of existing employees.
Tech companies that prioritize the development of these skills will be rewarded with an intelligent, inquisitive and high-performing DevOps team, setting themselves apart from competitors.
The DevOps sector is constantly evolving, so the talent organizations hire should be similarly open to evolution in the way they work.
Emil Krawczak, DevOps engineer at STX Next, said this is a key trait necessary for success. “To be successful as a DevOps engineer, you need to have a natural thirst for knowledge and desire to develop, and also be highly persistent when faced with challenges. This area of IT is developing so quickly that it’s difficult to keep track of everything new. It is not enough to learn at work; you need to take steps to grow your capabilities outside of the day-to-day, as well.”
System administration and development skills are essential, but they aren’t enough if developers don’t keep the bigger picture in mind at all times. Therefore, the ability to think strategically and the ability to apply analytical skills are invaluable for DevOps engineers.
Piotr Pawłowski, DevOps specialist at The One Question, explained how these traits made it easier for engineers to tackle a DevOps project. “Being successful in DevOps means having an analytical mind and taking a strategic approach. First and foremost, you should be to analyze the project and decide the right tools and approaches. You might know a lot about different tools and cloud solutions, but if you don’t know how to use them, you will not be successful in the world of DevOps.”
The ability to put theory into practice is where true progress is made. With that in mind, what DevOps employees glean from training, education, books and research has little relevance unless it is supplemented by practical experience.
Versatility is an integral skill in the industry, and successful DevOps pros should be able to use—or at least have working knowledge of—a broad range of tools. They should also specialize in at least one area of Dev or Ops. Python is a great example; Python is highly effective in the automation process and the language should be viewed as a key stepping stone in growing DevOps engineering skillsets.
Employers searching for new talent should look for relevant skills in other IT disciplines that could help a candidate make the switch to DevOps. For example, experience in SysOps or a specific programming language can be extremely useful when opting for a change of focus.
“DevOps unites the world of admins (SysOps) with the world of programmers/developers (Dev). The easiest way to get into DevOps is to have experience in both of these areas,” Krawczak said. “As an admin, you can build on your experience in scripting, and as a developer, you can leverage your experience in setting up local infrastructure for testing.”
Marcelo Grebois, senior DevOps Engineer at Toptal, said businesses should keep things as simple as possible when establishing their DevOps approach. “Try to make things easy. Always think about automation, keep all infrastructure ‘as-code’ and stay up-to-date on tools and technologies.”
Roman Kamiński, cloud system architect at Atos, agreed. “Using automation tools such as Ansible and Terraform, for example, stops developers from getting left behind while helping them adjust to an ever-changing industry.”
It’s important that tech companies invest in the growth of DevOps engineers and help them focus on the skills that will maximize their potential. The organizations that put time and resources into nurturing the next generation of talent will benefit from a larger pool of well-trained engineers. In the long term, this will ease the DevOps skills shortage and make for a more prosperous IT department.

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: Nvidia’s CEO grabs headlines by saying your career is toast, and Intel is still fighting. (more…)

With the downward pressure of a global recession, inflation and general post-pandemic turbulence underpinning disruption to multiple facets of life, it seems only fair that we in the IT, software and security industry would eventually feel the winds of change, too. We have rolled with the punches of escalating cybercrime and data breaches; the collective, fragmented sheriffs of a digital Wild West, and it’s high time we updated our strategy for safeguarding software against bad actors who seek to do widespread harm.
The recently released National Cybersecurity Strategy signals the need for a seismic cultural shift for most companies and their developers and DevOps teams. The most glaring recommendation comes in the form of security accountability that falls primarily on software vendors. This is a positive step, though it is sure to cause teething problems, especially as many organizations struggle to accurately assess their security maturity across the board, particularly among the development cohort.
Since CISA Director Jen Easterly’s trailblazing speech on secure design principles, we have eagerly awaited formal guidelines on how, exactly, organizations can approach this significant restructuring of software development as we know it. Thanks to a collaborative effort between the cybersecurity authorities of seven countries, we have a rather comprehensive overview of how to drive down vulnerabilities in software.
This should be cause for celebration, but understandably, there is hesitation about how this will impact innovation, feature delivery and, ultimately, the bottom line as the pressure of security stewardship mounts for vendors. We’ve grown accustomed to dealing with cumbersome tooling that is ill-fitted with developer workflows, overwhelming them with a list of fixes in an information avalanche. Add SCA and SAST scanning, and you’ve got thousands of identified issues in a codebase that are just not practical to solve.
Despite this, in terms of our collective attitude towards code-level security, is it time we grew up and faced the music?
Back in March, the White House announced that one of its top priorities in the National Cybersecurity Strategy was to shake things up and start holding entities liable for sloppy software security measures:
“Companies that make software must have the freedom to innovate, but they must also be held liable when they fail to live up to the duty of care they owe consumers, businesses or critical infrastructure providers,” the White House noted in the strategy.
In the era of “speed at all costs” software development, my opinion may be unpopular, but I truly stand behind the idea that coding with security front-of-mind from the beginning is the only way we safely create our digital future. We were already facing insurmountable challenges with data breaches, nation-state attacks and infrastructure disruption, and that was before code-capable AI tools hit the mainstream. Until every person touching code cares more about the security implications of their actions, we will continue to see cybersecurity issues surge at a rapid rate.
I know this is easier said than done. I have a lot of empathy for those standing at the bottom of this steep mountain trying to change the conversation around security accountability and enable developers in their organizations to share responsibility. To adequately fulfill key secure-by-design principles in software development, it is going to require precision training that establishes a basic skillset before deep-diving into more advanced security architecture methods. Developer-led threat modeling is a golden opportunity for the AppSec and development teams to work together toward a common goal and explore access control and insecure design pitfalls that plague less mature organizations.
Still, the core issue has always revolved around a lack of ownership for security (until something goes wrong—then it’s the AppSec team left holding the bag) coupled with a low appetite for best practices to be established and executed across every part of the SDLC. The truth is, it was never acceptable for developers to start coding with so little security expertise, nor for us to focus on speed and functionality at the expense of safety and quality. Yet, here we are, and this is our crucible moment to accept shorter-term pain for longer-term ongoing success.
We should want to create the most secure, robust software possible, and the “radical transparency” called for by Jen Easterly is a boon to vendors and clients alike. It is definitely a mark of value to showcase the company’s security prowess; brand trust and reputation are everything in this hyper-competitive landscape.
The CISA guidelines pay particular attention to open-source and third-party components, both of which are widely used in most software development projects. It is imperative that developers are sufficiently security-aware to navigate potential inherent bugs with any preexisting code they use. However, in addition, they must be able to apply working knowledge of security fundamentals in the languages and frameworks they actively write in every day. Annual compliance videos played at 2x speed won’t cut it; they need training and a tech stack that is hyper-relevant, easy to access without context-switching from their workspace and that ultimately drives them to apply secure coding best practices as second nature.
They cannot do this alone, and they can’t be expected to upskill in their own time. The cultural shift required to make the development team a fundamental cog in a thriving security program takes courage, time and commitment. But the reward is cohesion between AppSec and developers that would have been virtually impossible a decade ago and software that stands above those who are, in one way or another, happy to let security slide despite the risks.
I guess this is what growing up looks like for all of us in the software industry, and it’s crucial if we want to stop the same old vulnerabilities that have plagued us for so long that they are old enough to drink.

CloudOps, short for cloud operations, refers to the processes, tools and strategies employed to manage, monitor and optimize the performance, security and availability of cloud-based infrastructure, applications and services. It encompasses a set of best practices and methodologies that ensure the smooth functioning of cloud environments, including resource provisioning, configuration management, automation, deployment, monitoring and incident response. The primary goal of CloudOps is to maintain reliable, scalable and cost-effective cloud solutions that meet the needs of businesses and their end-users.
A cloud operations engineer is a professional responsible for managing, monitoring and optimizing cloud-based infrastructure, applications and services within an organization. They play a crucial role in ensuring the smooth functioning of cloud environments by handling tasks such as resource provisioning, configuration management, deployment, automation and incident response.
Additionally, they collaborate with development and IT teams to design and implement scalable, secure and cost-effective cloud solutions that align with business objectives and end-user requirements. Cloud operations engineers must possess a deep understanding of cloud computing technologies, platforms and best practices, as well as strong problem-solving, communication and collaboration skills.
A CloudOps engineer plays a vital role in managing and maintaining cloud infrastructure and services. Their responsibilities and roles might include:
Becoming a CloudOps engineer typically requires a combination of education, relevant experience and certifications. The following steps can help you pursue a career as a CloudOps engineer:
In conclusion, a cloud operations engineer is an essential professional in today’s cloud-centric IT landscape. They play a critical role in managing, monitoring, and optimizing cloud infrastructure, ensuring that applications and services run efficiently, securely and cost-effectively.
With a deep understanding of cloud technologies, platforms and best practices, they collaborate with various teams to align cloud solutions with business objectives and end-user needs. As cloud adoption continues to grow across industries, the demand for skilled cloud operations engineers is expected to rise, making it a promising career path for those seeking opportunities in the ever-evolving world of cloud computing.

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:
Indeed.com
AT&T
Dallas, Texas
Software Engineer
$158,766 to $210,100
Northwestern Mutual
Syracuse, New York
Senior Systems Software Engineer – DevOps
$97,300 to $139,900
CareerBuilder.com
United Healthcare
Remote
Senior DevOps Engineer
$85,000 to $167,300
SimplyHired
GEICO
Remote
Azure DevOps Engineer
$82,000 to $185,000
Dice.com
Integrated Practice Solutions
San Diego, California
DevOps Engineer
$80,000 to $140,000

A survey of 350 software developers found a majority (91%) of respondents are unhappy with the actual metrics leadership teams are measuring.
The survey, conducted by Atomik Research on behalf of Uplevel, an enterprise intelligence platform provider, found the top metrics developers say should be tracked include hours worked (52%), work allocation (49%) and the amount of time they have to focus on writing code (46%).
Unfortunately, the survey also revealed more than half of respondents (56%) reported that the CTOs that lead software development efforts make significant strategic decisions without realizing the negative impact on their team. They also often move people around on projects or tasks without knowing the full implications (51%) and overwork developers (44%).
Just under a third (30%) noted their engineering leaders rely solely on gut feelings to measure the effectiveness of their teams, while a third of respondents observed most engineering roadblocks go unnoticed by leadership.
Additionally, 96% noted that not knowing what their own leadership team is working on is detrimental to the larger team.
Christina Forney, vice president of product management for Uplevel, said many CTOs clearly need to be more engaged. Developers don’t mind being measured, but they clearly want to be evaluated based on metrics that matter, she added.
Managing software development teams has become a lot more challenging in an era where many developers are working remotely. IT leaders can no longer manage by walking around as easily as they once did, said Forney. Aligning workflows across a highly distributed team of developers is a challenge no matter how many communications platforms are used.
Surprisingly, the Uplevel survey found more than half of respondents (54%) said they feel more productive in the office. More than a third (35%) also said they preferred some form of synchronous communication to engage with other members of their team versus 27% that preferred some form of asynchronous communication. A total of 38% said they preferred a mix.
It’s no secret that despite long-standing commitments to automation, there are still a lot of manual processes in DevOps workflows that create bottlenecks. In an uncertain economy, however, there’s a lot more focus on developer productivity, so eliminating DevOps bottlenecks has become a major priority. The challenge is those bottlenecks are not as apparent to senior IT leaders, many of whom may have simply become inured to them over time.
Regardless of how bottlenecks occurred, DevOps teams would be well-advised to reevaluate the metrics they track. Mean-time-to-recovery (MTTR), for example, is not as important a metric to the business as the amount of quality code that finds its way into a production environment.
In theory, all the data required to track more meaningful metrics that could improve productivity already exists in the tools and platforms DevOps teams use to build and deploy an application. The challenge has been finding a way to automatically surface that data without adding yet another bottleneck to a DevOps workflow.

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: PyPI complies with a “string of subpoenas,” and LTO continues to grow, despite predictions of its demise. (more…)

Dell Technologies has quietly launched a training and education initiative to significantly expand the number of IT professionals that have DevOps skills.
Brad Maltz, senior director for DevOps and developer relations ecosystems for Dell, said the next era of IT will require IT professionals that understand how to automate the management of application development and deployment. Given its long infrastructure history, Dell is especially interested in helping IT teams to use a mix of graphical tools and command line interfaces (CLIs) to programmatically deploy software at much faster rates and at scale, he added.
Dell has already hired more than 200 specialists to provide that training as part of a DevOps Transformation Services consulting services engagement, said Maltz. The primary area of focus will be working with IT organizations that are embracing platform engineering to centralize the management of DevOps and GitOps workflows, he noted. Many of those teams are now relying on declarative automation tools that ultimately make DevOps more accessible to a wider range of IT professionals, added Maltz.
The number of IT professionals that employ graphical tools based on IT management frameworks such as ITIL still far outnumber the number of IT professionals that have DevOps skills. The ongoing debate between these two camps essentially comes down to the need to be able to consistently manage IT at scale versus being able to adroitly keep pace with the needs of organizations that are increasingly dependent on software. In the digital transformation era, it’s become clear that more of the organizations that hire IT professionals are placing a higher value on agility, said Maltz.
Bridging the divide between ITIL and DevOps to address that requirement is largely a psychological challenge that requires IT teams to address a range of cultural issues in addition to mastering different types of tooling, he added.
Regardless of whether organizations continue to manage IT infrastructure internally or rely more heavily on managed services provided by Dell, the need to continuously deliver secure software faster has become a business issue. The trouble is the level of DevOps expertise within organizations tends to vary widely. A recent survey published by the Continuous Delivery (CD) Foundation found only 22% of respondents are using both continuous integration (CI) and continuous delivery (CD) to automate all building, testing and deployment of code in a production environment. Most organizations that have adopted DevOps make extensive use of CI to build applications, but CD has proven to be more challenging to master. In fact, the CD Foundation survey found only 7% of respondents described themselves as DevOps engineers or specialists.
The bulk of the managed services that Dell provides are focused on managing infrastructure rather than deploying software, but the company does have a managed DevOps offering based on the application development and deployment platform that an internal Dell DevOps team built to construct and deploy applications. Naturally, Dell has a vested interest in accelerating the rate at which software can be deployed on IT infrastructure it provides and manages.
It may be a while before the overall size of the DevOps community expands, but the training initiatives such as the one launched by Dell will help. However, it may become a lot easier to find and retain that talent in the months and years ahead. In the meantime, organizations would be well-advised to invest in upskilling their own IT teams. After all, it’s less expensive to train someone that already works within an IT organization than it is to compete against thousands of other organizations willing to pay top dollar for the best DevOps expertise money can buy.