Getty Images/iStockphoto
The promise of SRE: Can it ease infrastructure integration?
SRE helps DevOps teams identify infrastructure issues earlier in development, but system engineers and other IT roles remain essential to ensure reliable application integration.
Site reliability engineering was made for DevOps developers. Its goal is to insulate developers from troublesome integration issues with an IT infrastructure that they know little about. SRE can give developers early signals about where an application will fail in production when it is integrated with the rest of the IT architecture.
But does this mean that system engineers -- those who sit on the infrastructure side of IT -- are sold on SRE? And what do the system engineers need to keep doing to ensure that an app with a new enhancement will run?
At the heart of this are application development and integration. Do quick-to-develop-and-deploy Agile applications make integration with an underlying infrastructure stack more or less difficult? SRE proponents say yes. Others aren't so sure.
What SRE was designed to solve from the developer's perspective
In June 2025, McKinsey & Company reported that successful SRE use improved operational productivity by 20%-30% and the DevOps developer experience by 30%-40%.
SRE helps developers by bringing system engineers into the development process while an app is being developed. Here's why that matters:
In Agile and traditional Waterfall development, developers build business applications, and then system engineers check for and resolve underlying infrastructure issues after the app is coded. This is a two-step assembly line process. Ideally, SRE changes this to a single-step collaborative process, so application developers and system engineers can work side by side from the start to resolve issues. This saves developers from one of their worst fears: encountering delays while they wait in line for system programming help.
The infrastructure side of the equation
System engineers bring a vital component to the development cycle that developers don't have on their own: a knowledge of the IT infrastructure on which the applications run.
The underlying infrastructure for applications consists of databases, servers, OSes, system subroutines for transaction processing, provisioning, security, network settings and access/integration APIs to cloud and on-premises resources.
A system engineer can help a developer meet service-level objectives (SLOs), such as ensuring that an application achieves 99.9% uptime and processes a certain number of transactions per second. Because the average application invokes numerous internal infrastructure routines for access and services, a performance or integration issue could occur at any of these points.
For instance, a developer might not know about a database schema change that causes an app to fail, or a new OS or software release might render an app incompatible. Both are IT infrastructure changes that a system engineer working alongside an application developer can quickly discern and resolve.
What SRE can't do alone: Gaps in infrastructure integration
An SRE practice that pairs system engineers with application developers in the early phases of application development will plug many gaps in infrastructure integration that developers struggle with today -- but not all of them.
Here are four infrastructure integration gaps:
1. Change management
Especially with Agile, applications are constantly changing -- and so are databases, network configurations, storage management, servers and security on the infrastructure side. However, the rate of change is much faster on the applications side. An SRE methodology can't eliminate or synchronize every change management issue.
2. The need for custom work
SRE automation tools can resolve infrastructure integration problems on their own, but this automation goes only so far and will always be generic. It won't be able to navigate highly customized APIs into the many legacy systems that enterprises run and developers need to access. In these cases, system engineers must perform the integrations, which will take extra time.
3. Data management
In cases where data is incomplete or broken, data analysts must get involved. Developers often see these issues on hastily constructed test databases, but data issues can occur in production staging, too -- especially if a database schema or access point has been changed.
4. Team integration
System engineers typically prefer working alone. It will be a big change for them to work alongside application developers, and this could be a cultural integration challenge for many IT organizations.
Additional IT ops capabilities that must complement SRE
In addition to system engineers, other infrastructure personnel will need to work within the SRE concept for SRE to be complete:
- Security professionals who can alert a developer to impending changes in security protocols that could affect an app.
- Networking staff who work on load balancing and network route planning for the app, depending on its SLOs and service-level agreements.
- Cloud operations managers who are responsible for overseeing cloud performance for apps hosted on the cloud.
- Database analysts who can alert developers to data or schema changes that could affect an app.
- The operations group, which must schedule backups of the app and its data and place the app into batch run streams if the app's processing is to be done during off-business hours.
Conclusion
SRE is a logical extension of application automation that solves a major developer issue: lack of IT infrastructure knowledge. And although SRE can't solve every infrastructure integration issue, it can solve many of them.
The key now is for sites to identify where SRE can be most effectively employed and how to create a mutually beneficial collaboration between application developers and system engineers.
Mary E. Shacklett is president of Transworld Data, a technology analytics, market research and consulting firm.