This article is based on commentary originally published on devops.com, drawing on observations from Mike Piech, then Vice President and General Manager of Middleware at Red Hat.
A Growing Split in Developer Skill Sets
The application development landscape is fragmenting. On one side sit developers targeting constrained environments — IoT devices, embedded systems, and smartphones — where finite compute resources demand precision, efficiency, and deep technical discipline. On the other side are developers building back-end services who can draw on virtually unlimited resources through cloud platforms, container orchestration, and emerging serverless frameworks.
According to Mike Piech, this bifurcation is becoming more pronounced as more application logic migrates to the network edge. The consequence is not just a skills gap — it is an operational gap. IT operations teams must now support radically different application classes simultaneously, each with its own deployment, scaling, and lifecycle requirements.
Abundant Resources Encourage Less Disciplined Back-End Development
Multiple layers of abstraction — containers, orchestration platforms, PaaS environments, and serverless frameworks — have made it easier than ever to build and deploy back-end applications. That accessibility, however, carries a trade-off: when compute resources feel unlimited, developers are less likely to optimise for efficiency or commit to a coherent architectural strategy up front.
The upside, as Piech noted, is that iterative, trial-and-error approaches to right-sizing applications are now viable. Modular microservices architectures mean that if one component underperforms or runs in the wrong environment, it can be relocated without rearchitecting the entire application. Developers today have more freedom to experiment with tools, languages, and deployment targets than at any previous point in enterprise IT history.
Hybrid Computing: Local UIs, Remote Back-End Services
One emerging pattern Piech highlighted is a new form of hybrid computing: graphical user interfaces continue to run locally on devices, while the majority of business logic is accessed remotely through APIs. This model decouples the front-end from the runtime environment entirely, freeing developers from decisions about where services physically execute.
While this approach simplifies development, it adds complexity to operations. Each API call traverses infrastructure that must be monitored, secured, and scaled — infrastructure that the developer may never directly interact with.
The Operational Pressure on DevOps Teams
Greater developer freedom translates directly into greater operational burden. As organisations experiment with edge computing, microservices, containers, PaaS, and serverless concurrently, operations teams are expected to deploy, monitor, and manage all of it — often with little advance notice about what the next application model will look like.
DevOps adoption across organisations has historically been uneven. Teams that have invested in automation, infrastructure-as-code, and continuous delivery pipelines are better positioned to absorb this diversity. Those still managing infrastructure manually face an increasingly unsustainable gap between developer expectations and operational capability.
The practical implication is straightforward: the more application models proliferate, the stronger the business case for mature DevOps practices becomes. Dynamic provisioning, automated testing, and self-service infrastructure are no longer optional conveniences — they are prerequisites for keeping pace.
Middleware and Databases: From Monoliths to Microservices
Traditionally, IT operations teams have provisioned monolithic application servers and large relational databases. That model is giving way to a more granular one. Middleware and database functionality is increasingly being decomposed into discrete microservices that applications call on demand, rather than deploying a full application server to support a single workload.
The transition is typically incremental. A common first step is containerising existing monolithic applications using Docker — a lift-and-shift into the cloud — before progressively refactoring toward microservices-based architectures. This staged approach allows teams to gain operational experience with containers without requiring an immediate, complete rearchitecture.
Serverless Computing: Complementing, Not Replacing, Stateful Applications
Serverless computing frameworks — built on event-driven architectures — are gaining traction as a complement to long-running, stateful applications rather than as a wholesale replacement. Piech’s view was that serverless would prove most useful for burst workloads: handling spikes in demand that would otherwise require over-provisioning dedicated infrastructure.
Intermittently-running stateless applications are also natural candidates for serverless execution, where paying only for actual invocations makes economic sense. At the time of the original article, Red Hat was backing the open-source Apache OpenWhisk serverless framework as part of its contribution to this space.
What This Means for DevOps Teams Right Now
- Expect heterogeneity, not uniformity. Your infrastructure will need to support containers, VMs, serverless functions, and edge deployments simultaneously. Design your automation and observability accordingly.
- Invest in self-service platforms. If developers can provision compliant environments without filing tickets, operational teams spend less time on routine provisioning and more time on architecture and reliability.
- Standardise on APIs as the integration layer. As UIs decouple from back-ends and microservices multiply, API gateways, service meshes, and consistent authentication patterns become critical operational controls.
- Build incremental migration paths. Not every workload moves to microservices at once. Define clear criteria for when containerisation, refactoring, or serverless migration is appropriate, and automate the pipelines that support each path.
- Treat DevOps maturity as a competitive requirement. The organisations best positioned to absorb new application models are those that have already automated deployment, monitoring, and rollback — not those reacting to each new model as it arrives.
The Bottom Line
The proliferation of application development models — edge, cloud-native, serverless, containerised monoliths, and everything in between — is not a temporary phase. It is the new baseline. IT operations teams that rely on a single, uniform deployment model will find themselves permanently behind. DevOps practices that emphasise automation, flexibility, and cross-functional collaboration are the most direct path to keeping pace with the diversity that modern development demands.