Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: The EU wants to put servers in orbit, a GDPR penalty for Discord, and Amazon has the hatchet out. (more…)

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: The EU wants to put servers in orbit, a GDPR penalty for Discord, and Amazon has the hatchet out. (more…)

We are excited to announce the finalists for the DevOps Dozen² Awards 2022, celebrating the greatest innovators and their achievements in the DevOps space. These individuals and companies have taken an active role in the DevOps community, demonstrating their leadership and commitment to the improvement of our industry in the past year.
Congratulations to every one of the finalists. All of your hard work and dedication are greatly appreciated.
Without further ado, here are the finalists for the DevOps Dozen² Awards 2022:
1. Best DevOps Industry Implementation
2. Best DevOps Survey/Analysis/Research
3. Best DevOps-Related Video Series (video)
4. Best DevOps-Related Audio Podcast Series
5. Best DevOps Book/eBook of the Year
6. Top DevOps Evangelist
7. Best DevOps Transformation (non-vendor)
8. Best DevOps Event of the Year
9. Most Innovative DevOps Open Source Project
10. DevOps Executive of the Year (non-vendor)
11. Best DevOps Presentation of the Year
12. Best DevOps.com Article of the Year
1. Best End-to-End DevOps Tool/Service
2. Best DevOps Repo/GitOps Tool/Service
3. Best CI/CD Tool
4. Best Value Stream Management Tool
5. Best Observability Solution
6. Best DevSecOps Solution
7. Best Testing Service/Tool
8. Best Kubernetes Platform/Service
9. Best Cloud-Native Security Solution/Service
10. Best DevOps for Mainframe Solution
11. Best DevOps for DataOps/Database Solution
12. Best New DevOps Tool/Service Provider
Finalists were picked by the judges and based on which entry had the most nominations. All finalists will receive a badge to display on their website and social media with a link to the voting/survey site.
Voting for the winners in all 24 categories is now open to the public. To vote for the leaders, tools and companies you think are truly deserving of an award for their exceptional service to the DevOps community, please visit the DevOps Dozen² website.
Winners will be chosen from among the finalists, with general public voting weighted for 40% of the final score and our judges’ selections for 60% of the final score. The deadline for public voting is December 31 at 5:00 p.m. ET.
The winners will be announced at the Predict 2023 Virtual Summit on January 12, 2023, and will receive both digital badges and physical trophies celebrating their achievements.
Thanks to everyone who has supported the DevOps Dozen² Awards by nominating candidates and voting. Good luck to all the finalists!

Effective collaboration within developer teams is key to creating and improving any product, so who you choose to put on the team—and how it’s structured—can make a huge difference. There are many considerations that go into these decisions, and the challenge is even greater thanks to the widespread movement to a hybrid work environment. To make the process a bit easier and more transparent and to set teams up for success from the outset of each project, it can be helpful to use a visual approach to staffing.
When a general manager is assembling a team in professional sports, they must take into account personalities, abilities and leadership styles to make sure the team functions smoothly and can win games. There are similar considerations necessary when putting together a developer team.
For example, a team must have the right balance of expertise. Having a team that is loaded with frontend experience but little to no backend experience will likely prove problematic. Also, a team full of interns or entry-level engineers with few or no senior engineers won’t have the leadership and expertise needed to succeed.
Coding styles are also a major consideration when assembling teams. Some engineers may be “cowboy coders”—coders who aren’t afraid to take risks when developing a product. Other engineers, however, may suffer from “analysis paralysis,” spending too much time making sure the code is as perfect as possible. It’s important for teams to have a mix of these styles so the development process doesn’t lean too far in either direction and so the overall team has the right balance for the project at hand.
As a development team leader, I’ve found staffing our teams using a visual approach—and visually collaborating within those teams—is invaluable. It makes it much easier to ensure we have the right expertise and coding style on the right teams while managing the fast-paced changes that are a reality in today’s business environment. And with the staffing for each project visualized, leaders and team members can easily see who leads the projects and how many people are on each team within those.
Managers or project leads should be able to see all of the relevant factors of staffing before making an informed decision on who should be on the team or if they need additional support. To begin visually staffing your teams, start with a diagram that—in addition to displaying which team each person is on—clearly shows each individual’s responsibility and flags if they’re new to the team. When decision-makers are able to see each of these factors at a glance, it helps them quickly determine if a team has a gap and needs additional support.

Caption: Here, team leaders can see team breakdowns, responsibilities and if someone is new to the team (Lucidchart)
To make visual staffing even more effective, you may want to get more granular in detail when viewing team structures. This could include labeling team members with relevant attributes such as title, seniority, location, etc. Therefore, if a team needs a senior engineer or someone who’s worked on similar projects, it’s possible to quickly drag their name on your diagram and place them on another team. With this method, teams can see how a new assembly of talent can work together and how this adjustment affects other teams.

Caption: Team leaders can identify personnel, job title and the reporting structure (Lucidchart)
We’re also able to diagram reporting structures. It’s important to know to whom each person reports and how many direct reports each leader has. This helps prevent burnout and ensures each manager has the bandwidth to lead their direct reports and be in touch with the needs of the team.
Once teams are created, work sessions, such as program increment (PI) planning meetings, will also benefit from a visual collaboration solution such as a virtual whiteboard. Before the recent predominance of hybrid and remote work, many planning meetings included in-person discussions in front of a physical whiteboard. Also, voting on decisions included physical, color-coated sticky notes which each person would place on the whiteboard to indicate their vote.

Caption: Developer teams can participate in virtual PI planning meetings for more seamless collaboration. (Lucidspark)
Using visual collaboration will help not only recreate this experience in a hybrid environment but also make it more effective and efficient. For example, working with a virtual whiteboard solution could improve a team’s experience with common project management tools, such as Jira. The right visual collaboration solution can allow teams to pull stories and display the latest project information for everyone to provide input directly within a collaborative space. The result is an ability for team leaders to create high-level plans with both real-time collaboration and asynchronous input from teams around the world—all while massively reducing the slow, manual steps that are so common with collaboration in front of a physical whiteboard. Those slow manual steps could include transferring stories from project management software onto physical cards, moving those cards around as discussions continue and then—once decisions are final—manually uploading new information back into Jira or another project management tool. With the amount of dependencies on developer teams today, removing these steps in favor of more efficient processes is invaluable.
Staffing teams and enabling collaboration can be a smooth experience, even in a hybrid environment. I’ve found that visualizing how teams work together provides the clarity needed to make the best decisions. It also allows easy changes to team composition should it be necessary. Visually staffing teams allows team leaders to start developers off on the right foot and consistently work toward project goals from start to finish.

In the dynamic world of software delivery, an ‘if it’s not broke don’t fix it’ philosophy won’t get you very far—even when your software and systems are working as planned.
Software is more complex than ever and innovation is exploding across markets. To keep up with constant innovation from your competition in a global marketplace, you should always be thinking about how to improve your products and services.
The teams and organizations focused on continuous improvement simply outperform those who settle for the status quo and fear the unknown. Let’s look at why continuous improvement is important in IT organizations; how to avoid common mistakes when measuring success and tips for getting started. But first, let’s define what continuous improvement is.
Continuous improvement is incrementally improving a project or process several times based on feedback. Feedback can come from various sources, including users and automated testing.
Making small changes over time offers many benefits when compared to a “big bang” change. Often, a “big bang” change is made with little to no feedback until it is almost too late.
By making smaller changes, a team can try something, listen to feedback and adjust. If a change is poorly received by end users, little time was spent working on it, so it can more quickly be completely reworked or scrapped altogether. This encourages experimentation with the safety net of knowing nothing is permanent.
Think of it like swimming from one end of a murky lake to another. You could dive underwater and not come up until you hit land and, hopefully, you are in the right place. Or, you could periodically pop your head above water, check your bearings and adjust course.
Today, it’s hard to imagine a situation where IT teams wouldn’t benefit from adopting a continuous improvement methodology. Any IT team whose responsibilities include writing software and delivering it to users benefits from continuous improvement. Smaller, incremental changes generally mean a smaller risk of something going wrong. Making a small change to a piece of software or tweaking the software delivery pipeline to shave 30 seconds off the time it takes for each deployment environment adds up over time.
Continuous improvement is all about incremental changes over time to streamline workflows and cut back on waste. In the moment, those changes and improvements can be very subtle, making them harder to justify. When IT leaders don’t look at the big picture, it’s easy to miss how these small changes contribute to overall improvement.
For example, let’s say a team is completely focused on measuring deployment time. But the first fully automated deployment to production took just as long as a manual deployment. With a proper feedback loop, the team sees that it took just as long because there were a few misconfigured items. The next deployment takes less time, but only by a few minutes.
Each subsequent deployment takes less and less time. But it took several months and multiple attempts to go from two-hour manual deployments to 15-minute automated deployments. With an intensive focus on deployment time, this may not seem like a significant improvement given how long it took to get there. However, in this scenario, the team was so focused on deployment time that it missed other important measurements, such as the number of emergency fixes created after the team started automating the deployment.
If they examined those numbers before automation, they would have realized that they pushed out a handful of emergency fixes after a manual deployment—but, almost overnight, those emergency fixes stopped after introducing automation. Critical measurements and improvements like these are easily overlooked when leadership focuses too narrowly and avoids the “big picture” view.
When working in IT, there are many problems to solve with a finite number of people and limited time to fix them. It’s tempting to try and solve the problems at the same time. After all, you are only making small changes.
However, for real change to occur, you must make several small changes over time. Pick one or two problems to solve and focus on them until you reach a good stopping point; then, move on to the next problem.
Also, know what and where to measure. With data in hand, you can take an informed approach to designing improvements. Never settle for thinking there are no further improvements because, inevitably, you will be proven wrong when your competition does it better and faster.
Ensure that your organization or team is dedicated to lifelong learning, perhaps by experimenting with chaos engineering to see how the system responds. This will spark important conversations and justification for improvement, as well as invaluable feedback.
Every IT organization benefits from adopting continuous improvement and will find that it promotes innovation and helps maintain a competitive advantage. It is easy to take too narrow a view of the small changes. But with a high-level, strategic view of continuous improvement, leadership will see the benefits.

DevOps.com is now providing a weekly DevOps jobs report to highlight career opportunities for DevOps professionals as part of an effort 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
ApTask
Remote
DevOps Architect
$160,000 to $200,000
SimplyHired
FluentStream
Remote
DevOps Engineer
$150,000 to $200,000
The College Board
Remote
Senior DevOps Engineer
$144,000 to $150,000
ZipRecuiter
Ushur
Santa Clara, CA.
Senior DevOps Engineer
$130,000 to $140,000
Indeed
Element 84, Inc.
Remote
Senior DevOps Engineer
$119,000 to $140,000

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: People won’t shut up about Rustlang, and Musk mandates Twitter teams return to the office. (more…)

Catchpoint, in partnership with Blameless, today published an annual survey of 559 site reliability engineers (SREs) that found 59% of respondents didn’t view tool sprawl to be a major concern. Another 40% said tool sprawl is a moderate (33%) to serious problem (8%).
More than half of respondents said they build as much as 30% of the tools they use themselves, with more than half (54%) noting their organization tracks three or more different types of telemetry data to drive observability. The top three types of telemetry data collected are infrastructure (62%), application (58%) and network monitoring (55%) and, on average, the survey suggested the median toil level of SREs dropped 5% year-over-year.
Just under half of respondents (46%) also noted they saw no or low value from artificial intelligence for IT operations (AIOps) compared to 30% that have seen moderate to high value. Another 25% are still unsure.
Finally, the survey concluded that organizations that have adopted a “just culture”—where organizations ensure that incident reporting is not met with punitive measures—are 500% more likely to be Elite performers in terms of the DevOps Research and Assessment (DORA) metrics defined by Google.
Leo Vasilou, director of product marketing for Catchpoint, said that the survey results provided some insights into the challenges SREs face as they strike a balance between trying to achieve DevOps goals and the fact that hiring has become more constrained during an economic downturn.
That stress, however, has less to do with managing toolchains than it does ensuring that applications driving critical business processes are consistently available, he noted.
SREs have emerged as a distinct DevOps function in recent years, focused almost exclusively on programmatically managing the dependencies that exist between a wide range of applications and the underlying infrastructure upon which they depend. Optimizing applications in the cloud-native era has become more challenging because the number of dependencies that exist between the microservices that make up a modern distributed computing environment continues to exponentially increase. In many cases, applications are continually added to IT environments without a commensurate increase in the overall size of the SRE team.
Regardless of the economic climate, hiring and retaining SREs remains a challenge given the demand for IT professionals with those skills. Of course, there is no formal SRE certificate that is widely recognized so who qualifies to be an SRE tends to vary from one organization to the next. The one thing that is generally agreed upon is that SRE automate a wide range of tasks that would otherwise require multiple IT administrators to perform. Glassdoor also reports that, on average, an SRE makes north of about $125,000, which ranks among the highest salary level within any IT organization.
Each organization, depending on their geographic region, would need to determine how many IT administrators they could replace if they hired an SRE. That doesn’t mean IT administrators that rely on a wide range of graphical tools to manage IT tasks are going away any time soon, but as DevOps continues to evolve, the dynamics between SRE and IT administrators also will continue to evolve.

DevSecOps is having a moment in the federal government. With President Biden’s Executive Order on Improving the Nation’s Cybersecurity and federal agencies’ issuance of DevSecOps best practices based on the Enduring Security Framework, government organizations are shoring up and standardizing their DevSecOps processes to meet today’s cybersecurity challenges head-on.
Integrating security into the development process is particularly important for federal agencies that have invested significant time, effort and money in creating and running software development factories. These agencies are actively trying to balance security and innovation–and many are succeeding. The United States Air Force’s Kessel Run program is an example of a tightly run and innovative software factory.
The question is: How can they continue this success as the calls for standardized cybersecurity grow increasingly louder?
It’s tough to balance security and innovation and wrap them both in a standardized process. It’s certainly not impossible, as Kessel Run proves. But it does require a high level of rigor to ensure that applications are being developed at speed while taking the necessary time to mitigate and minimize security risks and vulnerabilities.
Projects like Kessel Run and others work well in part because they bake security into the development process from the outset. That core tenet of DevSecOps allows teams to integrate and standardize security throughout their development cycles without losing momentum.
But, there are challenges to these standardization efforts that are inhibiting DevSecOps practices.
First, many government agencies are still working with legacy systems and toolsets rather than the modern technologies that many commercial companies that employ DevSecOps have access to. These technologies can include everything from collaboration platforms, to messaging applications, to underlying platforms that tie all the work being done together.
Second, despite the government’s commitment to innovation, old ways of thinking still persist in many pockets of the public sector. Some important people still think, “Why change when email has worked just fine for all these years?” Those people fail to immediately see the value of modernizing their toolsets and practices.
But outdated technologies and processes won’t help government agencies balance security and innovation–and they won’t work with new cybersecurity policies and mandates. For instance, president Biden’s EO is filled with allusions to ensuring visibility into software development practices and the software supply chain. Doing both requires developers, security managers and operations managers to be on the same page and in constant communication at all levels of the development cycle.
Yet even in the most mature DevSecOps environments, this isn’t always possible. Because while DevSecOps is driven by collaboration, that doesn’t mean that developers, security managers, and operations managers always know who’s working on what, or what the status of a particular project is at all times. This is particularly true in a government setting where old processes, technologies, and siloed teams are still present.
But maintaining the balance between security and innovation is highly dependent on being able to have unfettered situational awareness throughout the development lifecycle. For example, a developer needs to know if a security operations teammate is working on fixing a vulnerability the developer discovered during testing. Likewise, an operations manager needs to know the status of the patch, as that might impact other factors important to the development process, including time to deployment.
High-level dashboards help all team members quickly ascertain the status of projects in development and are useful in helping individuals understand where things exist in the pipeline. They can provide a quick, at-a-glance take that leaders can use to plan their projects, discover backlogs or potential roadblocks to deployment, and more.
But even dashboards are not necessarily enough, because stakeholders need to be able to quickly and securely communicate status updates to each other.
The problem is that not all of these individuals will necessarily be using the same tools. Some might be using one messaging service. Others might be holding impromptu video meetings. Others might be posting updates to project management boards. Software development is a living and agile process, and communication is happening all the time through different channels.
That’s why it’s critical for agencies to pull all of these disparate threads together, especially if they are to properly manage security and maintain compliance with the EO. A single missed communication about a software vulnerability could end up becoming tomorrow’s SUNBURST attack. There must be a way for all DevSecOps stakeholders to interact with each other, regardless of their choice of tools or the channels they’re using.
This is where the choice of modern toolsets and platforms comes into play. Pulling disparate threads together to facilitate better communication and collaboration requires technologies with the ability to connect various services, automate task management and alerts, and break down any lingering communication silos. It requires an underlying architecture that connects all key stakeholders so they can collaborate and ensure the security of the applications they’re working on.
Older technologies and practices aren’t up to the moment government agencies are facing. They are unsuitable for today’s software development processes, and will not aid in the quest to stay ahead of today’s cyber threats.
To meet the moment, government agencies must embrace new ways of communicating and collaborating. They must use the tools that are available to keep innovating even while standardizing according to cybersecurity regulations. They must provide their DevSecOps teams with the ability to work freely yet securely and set them up for success.

A survey found 83% of developers are working remotely more than half of the time, with more than three-quarters (76%) reporting they have maintained or increased the frequency of remote work in the last year. In fact, three in five respondents (62%) work remotely at least 90% of the time.
The survey, published by Netlify, a provider of a platform for building the front end of Web applications using the Jamstack framework, polled 6,544 developers in the Jamstack community and found more than half (55%) would quit their jobs if forced to return to an office.
It’s not clear how much remote work has become a de facto requirement for organizations to attract and retain developer talent, but it’s clear that, in the wake of the COVID-19 pandemic, the dynamic between developers and the organizations that employ them has completely changed.
Netlify CEO Mathias Biilmann said regardless of industry, it’s apparent that DevOps teams are going to continue to need to make adjustments to foster collaboration across distributed teams. Senior managers will find it increasingly challenging to manage workflows across a workforce that is also witnessing a lot of turnover, he noted. A third of survey respondents (33%) reported having changed jobs in the last year. It’s not clear how much a lack of interaction in the office might be impacting innovation, but at a time when demand for developer talent far exceeds the available supply, organizations will need to adjust to what appears to have become a permanent new reality.
At the same time, the Netlify survey noted the pace at which emerging technologies are being embraced continues to rapidly evolve—perhaps because of rather than in spite of remote work. For example, the survey found 70% of developers reported using a serverless computing framework in the last year. Nearly half (47%) are also experimenting with edge dynamic sites, the survey found. It’s clear that company culture, at least in terms of technology adoption, plays a large role in attracting developer talent.
Overall, 96% of survey respondents noted that JavaScript is their primary choice of programming language, with 21% of developers now specifically using TypeScript to build applications. The React framework for building applications, meanwhile, is being used by 71% of developers, with 47% reporting they employed the Next.js version of that framework. Other React frameworks gaining traction include Vite (32%), Sveltekit (15%), Astro (11%), Remix (10%) and SolidJS (6%).
However, emerging Web3 technologies have yet to gain traction. While 7% to 10% of developers have tried out technologies such as cryptocurrencies and NFTs, only 3% reported using these technologies regularly. A total of 42% of developers either didn’t know what Web3 was or didn’t care about it, while 31% felt negatively about it, the survey found.
Ultimately, the primary reason organizations invest in DevOps is to increase developer productivity. The challenge is that, as developers embrace more tools and platforms for building applications, the process of deploying those applications becomes more challenging to manage effectively. One way to achieve that goal is to separate frontend and backend software development processes to enable developers to focus more on writing code rather than managing the arcane processes required to deploy it.

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort 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:
ZipRecruiter.com
Comcast
New York City
Lead Software Engineer – DevOps
$190,950 to $225,278
Indeed.com
Divi Technologies
Remote
DevOps Engineer
$140,000 to $155,000
SimplyHired
Perimeter 81
New York City
DevOps Engineer
$130,000 to $175,000
Dice.com
OnDemand Group
Minnetonka, MN.
Senior DevOps Engineer
$120,000+
Gainwell Technologies
Remote
Senior DevOps Engineer
$92,500 to $115,600