Image: Thinkstock
By Scott Carey
Managing Editor, News, InfoWorld | Aug 22, 2022 3:00 am PDT
Developers are straining under the demands of ‘You build it, you run it,’ and operators are feeling more pressure too. Is it time for development and operations to be separated once again?
With the job of software development getting more and more complex, it could be time for dev and ops specialists to separate once again. But can that be done without repeating the mistakes of the past?
Devops emerged hand-in-hand with the rise of agile methodologies and cloud computing in the late 2000s, as software started to eat the world. A neat portmanteau of “development” and “operations,” devops sought to bring together the two previously separate groups responsible for building and deploying software. It also coincided with, or even inadvertently pushed forward, the need for software engineers to tighten their user feedback loops and push updates to production more frequently.
While many organizations grabbed this opportunity to bring together two sets of specialists to solve common problems at previously impossible speeds, others took the rise of devops as license for developers to take responsibility for operations tasks and sought to build a super team of semi-mythical full-stack developers.
“Devs don’t want to deal with operational concerns, for the most part,” tweeted Devops for Dummies author and head of community engagement at Amazon Web Services, Emily Freeman.
Freeman clearly hit a nerve, with hundreds of replies pouring in from developers who also did not want to do ops.
“I am a dev and I don’t want to deal with operation concerns,” Scott Pantall, a software engineer at the fast food company Chipotle, replied.
“Devs and ops should work closely while having differentiated roles. The empathy between teams is the real point,” Andrew Gracey, a developer evangelist at SUSE, weighed in.
While the concept of shifting more operational and security concerns “left” and into the domain of software developers clearly has its merits, it also has the potential to create a dangerous bottleneck.
“If you pull devs into too many different areas you end up shooting yourself in the foot. They are different skillsets,” James Brown, head of product for Kubernetes storage specialist Ondat, told InfoWorld.
Or as Nick Durkin, field CTO at Harness, put it, “People are beginning to realize we wouldn’t hire an electrician to do our plumbing.”
While the stock of enterprise software developers has never been higher, the specialized expertise of technical operations has somewhat faded into the background, even as their workloads have increased.
As devops engineer and former systems administrator Mathew Duggan wrote last year, while operators “still had all the responsibilities we had before, ensuring the application was available, monitored, secure, and compliant,” they have also been tasked with building and maintaining software delivery pipelines, “laying the groundwork for empowering development to get code out quickly and safely without us being involved.”
These expanding responsibilities involved a mass retraining effort, where cloud engineering and infrastructure as code skills became paramount.
“In my opinion the situation has never been more bleak,” Duggan wrote. “Development has been completely overwhelmed with a massive increase in the scope of their responsibilities (RIP QA) but also with unrealistic expectations by management as to speed.”
That pressure may be starting to tell.
“It’s incredibly challenging to build an organization that achieves this level of iterative harmony that lasts for a sustainable period,” wrote Tyler Jewell, managing director at Dell Technologies Capital in a research note. “As systems grow in complexity and the end user feedback increases, it becomes increasingly difficult for a human to reason about the impact a change might have on the system.”
The situation may not be as hopeless as Duggan and others believe, though it may require a significant realignment of engineering teams and their responsibilities.
“The intention is not to put the burden on the developer, it is to empower developers with the right information at the right time,” Harness’s Durkin said. “They don’t want to configure everything, but they do want the information from those systems at the right time to allow operations and security and infrastructure teams to work appropriately. Devs shouldn’t care unless something breaks.”
Nigel Simpson, ex-director of enterprise technology strategy at the Walt Disney Company, wants to see companies “recognize this problem and to work to get developers out of the business of worrying about how the machinery works—and back to building software, which is what they’re best at.”
It’s important to remember that devops is a continuum and its implementation will vary from organization to organization. Just because developers can do some ops now doesn’t mean they always should.
“Developer control over infrastructure isn’t an all-or-nothing proposition,” Gartner analyst Lydia Leong wrote. “Responsibility can be divided across the application lifecycle, so that you can get benefits from ‘you build it, you run it’ without necessarily parachuting your developers into an untamed and unknown wilderness and wishing them luck in surviving because it’s ‘not an infrastructure and operations team problem’ anymore.”
In other words, “It’s perfectly okay to allow your developers full self-service access to development and testing environments, and the ability to build infrastructure as code templates for production, without making them fully responsible for production,” Leong wrote.
As Brown at Ondat sees it, container orchestration with Kubernetes is emerging as the layer between these two teams, separating concerns so that developers can focus on their code, and operations can ensure that the underlying infrastructure and pipelines are optimized to run it. “Let’s not rewind to those teams not speaking to one another,” Brown said.
In fact, according to VMware’s “State of Kubernetes in 2022” report, 54% of the 776 respondents said that better developer efficiency was a key reason for adopting Kubernetes, and more than a third (37%) said they want to improve operator efficiency.
“Don’t fall for the fallacy of trying to make everybody an expert,” Kaspar von Grunberg, founder of Humanitec, wrote in his email newsletter. “In high-performing teams, there are few high-profile experts on Kubernetes, and there is a high level of abstraction to keep the cognitive load low for everyone else.”
If the era of devops is indeed coming to an end, or even if the gloss is just starting to come off, what comes next?
Site reliability engineering (SRE), which emerged out of Google when it suffered its own devops-related growing pains, has proved a popular solution.
“Fundamentally, it’s what happens when you ask a software engineer to design an operations function,” Ben Treynor, vice president of engineering at Google and the godfather of SRE, is often quoted as saying.
Take the two large financial institutions, Vanguard and Morgan Stanley, which have found it difficult to balance dev and ops responsibilities as they transition towards more cloud-native practices.
Inserting an SRE safety blanket at both the central operations level and within individual developer teams has helped both companies build confidence that they are striking the right balance between developer velocity and operational stability.
However, the SRE function has also drawn some criticism. Establishing SRE principles is “sometimes misunderstood as a rebranding of the ops team,” as Trevor Brosnan, head of devops and enterprise technology architecture at Morgan Stanley, observed.
“It’s a nuanced problem to solve,” Christina Yakomin, a site reliability engineer at Vanguard, said. “Introducing SRE does make people feel like we are siloing ops again into that role.” Instead, Yakomin wants to encourage Vanguard developers and operations specialists to share responsibility for security and ensure that teams with shared platforms take full operational responsibility for them.
The idea of the internal developer platform, or the discipline of platform engineering, has also emerged as a way for organizations to give developers the tools they need, complete with the appropriate organizational guardrails to enable developers to do their best work.
An internal developer platform is typically made up of the APIs, tools, services, knowledge, and support that developers need to get their code into production, combined into a company-standard platform that is maintained by a dedicated team of specialists, or product owners.
“Devops is dead, long live platform engineering,” tweeted software engineer and devops commentator Sid Palas. “Developers don’t like dealing with infra, companies need control of their infra as they grow. Platform engineering enables these two facts to coexist.”
Brandon Byars, head of technology at the software consultancy Thoughtworks, says he often “sees that division working well in platform engineering teams, which look to remove friction for developers, while giving them dials to turn.” However, he adds, “Where it doesn’t work well is by asking developers to do all of that work without centralized expertise and tooling support.”
The balancing act between software development and operations teams will be familiar to any organization that has worked to implement devops principles across its engineering teams. It’s also a balancing act that is becoming increasingly high-wire in the age of cloud-native complexity.
Resource: Carey, S. (n.d.). Devs don’t want to do ops. InfoWorld. https://www.infoworld.com/article/3669477/devs-don-t-want-to-do-ops.html
MixedMug
We firmly believe that the internet should be available and accessible to anyone, and are committed to providing a website that is accessible to the widest possible audience, regardless of circumstance and ability.
To fulfill this, we aim to adhere as strictly as possible to the World Wide Web Consortium’s (W3C) Web Content Accessibility Guidelines 2.1 (WCAG 2.1) at the AA level. These guidelines explain how to make web content accessible to people with a wide array of disabilities. Complying with those guidelines helps us ensure that the website is accessible to all people: blind people, people with motor impairments, visual impairment, cognitive disabilities, and more.
This website utilizes various technologies that are meant to make it as accessible as possible at all times. We utilize an accessibility interface that allows persons with specific disabilities to adjust the website’s UI (user interface) and design it to their personal needs.
Additionally, the website utilizes an AI-based application that runs in the background and optimizes its accessibility level constantly. This application remediates the website’s HTML, adapts Its functionality and behavior for screen-readers used by the blind users, and for keyboard functions used by individuals with motor impairments.
If you’ve found a malfunction or have ideas for improvement, we’ll be happy to hear from you. You can reach out to the website’s operators by using the following email
Our website implements the ARIA attributes (Accessible Rich Internet Applications) technique, alongside various different behavioral changes, to ensure blind users visiting with screen-readers are able to read, comprehend, and enjoy the website’s functions. As soon as a user with a screen-reader enters your site, they immediately receive a prompt to enter the Screen-Reader Profile so they can browse and operate your site effectively. Here’s how our website covers some of the most important screen-reader requirements, alongside console screenshots of code examples:
Screen-reader optimization: we run a background process that learns the website’s components from top to bottom, to ensure ongoing compliance even when updating the website. In this process, we provide screen-readers with meaningful data using the ARIA set of attributes. For example, we provide accurate form labels; descriptions for actionable icons (social media icons, search icons, cart icons, etc.); validation guidance for form inputs; element roles such as buttons, menus, modal dialogues (popups), and others. Additionally, the background process scans all of the website’s images and provides an accurate and meaningful image-object-recognition-based description as an ALT (alternate text) tag for images that are not described. It will also extract texts that are embedded within the image, using an OCR (optical character recognition) technology. To turn on screen-reader adjustments at any time, users need only to press the Alt+1 keyboard combination. Screen-reader users also get automatic announcements to turn the Screen-reader mode on as soon as they enter the website.
These adjustments are compatible with all popular screen readers, including JAWS and NVDA.
Keyboard navigation optimization: The background process also adjusts the website’s HTML, and adds various behaviors using JavaScript code to make the website operable by the keyboard. This includes the ability to navigate the website using the Tab and Shift+Tab keys, operate dropdowns with the arrow keys, close them with Esc, trigger buttons and links using the Enter key, navigate between radio and checkbox elements using the arrow keys, and fill them in with the Spacebar or Enter key.Additionally, keyboard users will find quick-navigation and content-skip menus, available at any time by clicking Alt+1, or as the first elements of the site while navigating with the keyboard. The background process also handles triggered popups by moving the keyboard focus towards them as soon as they appear, and not allow the focus drift outside of it.
Users can also use shortcuts such as “M” (menus), “H” (headings), “F” (forms), “B” (buttons), and “G” (graphics) to jump to specific elements.
We aim to support the widest array of browsers and assistive technologies as possible, so our users can choose the best fitting tools for them, with as few limitations as possible. Therefore, we have worked very hard to be able to support all major systems that comprise over 95% of the user market share including Google Chrome, Mozilla Firefox, Apple Safari, Opera and Microsoft Edge, JAWS and NVDA (screen readers), both for Windows and for MAC users.
Despite our very best efforts to allow anybody to adjust the website to their needs, there may still be pages or sections that are not fully accessible, are in the process of becoming accessible, or are lacking an adequate technological solution to make them accessible. Still, we are continually improving our accessibility, adding, updating and improving its options and features, and developing and adopting new technologies. All this is meant to reach the optimal level of accessibility, following technological advancements. For any assistance, please reach out to