Software applications and their development, management, orchestration, administration, maintenance and general wellbeing have moved to the web. Okay don’t write in just yet, those are just the opening credits.

Obviously then, we have started to apply web-centric technologies to these applications in order to push them towards a performance, scalability and interoperability status that we now call “web-scale” – which basically just means big and flexible.

Does this reality therefore mean there is some specifically web-centric version of DevOps to consider? A webby DevOps, even?

As RedMonk’s James Governor put it recently: “We are seeing a massive increase in load on web architectures across the board. With mobile device proliferation, wearable computing, digital TV and the Internet of Things adding orders of magnitude to demands on website performance, the need for sophisticated scaling architectures is growing just as fast.”

The webby DevOps toolkit

So it’s real then… and technologies inside the webby DevOps toolkit specifically include web acceleration knowhow. As we know, a web accelerator is best defined as a hardware or software appliance capable of speeding up the transfer of content between data centre web servers and users’ client browsers.

Techniques for web acceleration include caching, compression and “prefetching” regularly accessed documents and/or data, as well as a variety of optimisation techniques.

There is also processing intelligence to be brought to bear. As NGINX reminds us, some advanced web accelerators can offload computationally intensive processing from backend servers, freeing them to serve content faster.

A common example of web acceleration processing intelligence is encryption and decryption of documents during transmissions secured with Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

But so far this doesn’t really sound like DevOps does it? It sounds more like web-scale architectural orchestration toolchain intelligence (WSAOTI?), not that that expression even really exists – yet.

DevOps-ing web architecture

Founder and chief technology officer of Varnish Software Per Buer seeks to clarify where webby DevOps is going and what its deeper technical nuances might involve. The firm’s Varnish Cache product sits at the intersection of developers and sysadmins.

“Our open source project Varnish Cache is an infrastructure component (you could call it a web architecture component) but has business logic in the shape of VCL (Varnish Configuration Language) in it – so it has the ability to affect HTTP traffic as it flows through,” said Buer.

So web architecture componentry is the new webby DevOps for backend focused web-scale development and intelligence, then, is that it?

“Wherever we position this technology, it presents a challenge to the usual IT silos. This is because a VCL change is typically regarded as a configuration change, but the role of the ‘change’ (in a purist sense) is typically to support change in the application logic,” said Buer.

So hang on, was a VCL change a Dev (developer application logic) change or an Ops (operations configuration and management) change? Or was it both?

Buer explains that users of Varnish pretty much fall into three roles: Dev, Ops and DevOps. Is that an excuse to cover all bases, or a clever way of clarifying things?

“We can tell from the support requests which organisations have real DevOps teams and which don’t. The real DevOps teams get performance gains out of VCL because they are able to move functionality out of their apps layer into it. Real DevOps teams look at the big picture, always trying to strike that ideal balance of performance, scalability and uptime,” he said.

What web-scale DevOps means

So this is it then? This is what web-scale DevOps actually means (or at least it’s a good practical example of it) today. We take a portion of web acceleration with its associated logic efficiencies and add a healthy dose of processing control logic to stay flexible, changeable and Agile.

It has been widely said in no uncertain terms, developers like to lump blame on the sysadmins for poor performance and weak infrastructure provisioning. Ops sysadmins on the other hand like to curse the developers for poorly written code that breaks under strains caused by performance load, change or augmentation.

If we can bring together business logic, configuration logic and application logic in one place, then perhaps we can achieve world peace. ®