TNS
VOXPOP
Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
0%
No: TypeScript remains the best language for structuring large enterprise applications.
0%
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
0%
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
0%
I don’t know and I don’t care.
0%
DevOps / Frontend Development

WebOps: A DevOps for Websites, but the Tools Let It Down

WebOps aims to bring the DevOps approach to websites, but the tools in content management over-complicate matters.
Aug 17th, 2022 7:09am by
Featued image for: WebOps: A DevOps for Websites, but the Tools Let It Down
Lead image via Shutterstock.

WebOps is a portmanteau of “web” and “operations” and, at first glance, appears to be a close cousin of DevOps. As the name suggests, WebOps focuses on the deployment and operation of websites and web applications. The term has been around since at least 2006, when its Wikipedia article was first published (indeed, that page is older than the DevOps article on Wikipedia, which was first published in 2010). Yet when I searched my Twitter timeline, there has been no mention of “WebOps” from the people I follow since 2020.

So what is going on here — is WebOps a real trend or not? To find out, I spoke to Josh Koenig, co-founder and Chief Strategy Officer at Pantheon, a company that has appropriated “WebOps” for its marketing efforts. The term is listed multiple times on Pantheon’s homepage, its definition article currently ranks number 1 in a Google search, and it also dominates Twitter search results.

SaaS for Content Management

Pantheon is a website management company that was founded in 2010. It started off as a “software-as-a-service” for managing Drupal websites. When it launched to the public in September 2011, it was described by TechCrunch as “a Heroku for Drupal sites in that it puts the web development environment in the cloud.” Pantheon eventually expanded to offer a cloud service for WordPress websites too.

“We are still the same core product, the same core value proposition, today as then — we call it a website operations platform,” Koenig told me. “You can think of WebOps [as] applying all of the proven lessons from DevOps and modern software development, to the rather tricky use case of the web. Ironically, DevOps was born from the experience of early web practitioners at scale, but often isn’t used for websites.”

The key difference between DevOps and WebOps is that the latter involves managing content, which typically means marketing people are part of the process. This happens to be something I have deep experience in, even though I’ve never used the word “WebOps.” I told Koenig that I used to be a “Web Manager” in the first few years of the 2000s, and at that time companies didn’t know whether to place me in the IT department or the marketing department (for the record, I ended up in Marketing, but hung out with the IT team at breaks and lunchtimes!).

Comparing WebOps to DevOps

Like DevOps, WebOps enables things like version control and CI/CD (continuous integration and delivery or deployment). But, said Koenig, it applies it “to the narrower technology space of the web […] with a deeper set of stakeholders.” So WebOps includes web designers and content creators in its workflows.

From an IT perspective, how is WebOps usually managed? According to Koenig, it depends on what the relationship is between the IT and marketing departments.

In some cases, he said, the marketing department “earmarks budget to pay for developers who are technically in IT, but are dedicated to Marketing’s technology needs.” But in other cases, he’s seen “really strong central IT organizations” in which IT takes the lead — and in those cases, they tend to make use of their existing DevOps team and practices.

In DevOps, CI/CD is a common part of the workflow. I asked if that’s the case with WebOps too, and if so how does CI/CD work in the web context?

For static sites, Koenig replied, testing is done during the build (typically after content is updated). “The more challenging case is where people have content management,” he said, “so you have a living piece of software that’s running your live website, and that is connected to a database, it’s got some binary assets, images, PDFs, what have you. So you have people using that in production to post new content [but] you also want to be able to make design changes and add functionality.”

The CI/CD workflow that Pantheon has developed to manage this, Koenig continued, allows companies to “synchronize the current state of the live content with a preproduction application environment, and make sure that all the aspects of those two environments are the same.”

This doesn’t sound all that different from what corporate content management systems have always done. In the early 2000s, I used a rather bulky CMS from Interwoven called TeamSite, which did pretty much as Koenig described (kept the dev and production environments separate and in sync). And this was many years before the term CI/CD was coined. So in some ways, it feels like WebOps is just a trendy term for a long-familiar process in website content management.

The Headless CMS Conundrum

What has definitely changed over the past two decades is the complexity of the modern website build and deployment process. Current trends like Jamstack and “headless CMS” give more power to IT teams, but at the cost of added complexity. A headless CMS, for example, is when the presentation and publishing aspects (the frontend, or ‘head’) are managed outside of the CMS. A headless CMS is often used by the marketing team to input their content, while the presentation and publishing are managed separately by the WebOps team.

It turns out that Koenig has opinions on the state of headless CMS. In a recent Forbes article, entitled “​​What I Got Wrong About The Headless CMS”, Koenig wrote that while he helped popularize the trend of headless CMS, he (and the industry) have focused too much on the backend and not the frontend. I think what he meant is that headless CMS products have a reputation for poor user interfaces, whereas modern web apps like Google Docs are easier to use and have better functionality. So, ironically, headless CMS products have made the user experience (the frontend) worse for content creators.

That aside, Koenig told me that the headless CMS trend has “made the need for WebOps in many cases a lot clearer, because there’s orchestration involved.” In other words, there are at least “two separate pieces of software that need to integrate — a frontend and a backend.” That’s where Pantheon and its WebOps approach comes in, he said, as it offers a structured workflow and more automation.

Conclusion

I’ve no doubt that the DevOps approach has a lot of potential benefits for web content management, especially on the back end for the IT department. But after talking to Koenig, I realized that there are many different ways to implement this approach for websites. So it’s still unclear to me what, exactly, WebOps is. The process between IT and marketing seems to largely depend on what CMS tool is being used.

Speaking of which, I’d argue that the tools in content management have over-complicated matters in recent years — with headless CMS in particular not doing a good enough job on the frontend. Developers and operations people may have it better with decoupled systems (Jamstack or headless CMS), but the poor old marketing folks are struggling. Whatever WebOps is, it needs to do a better job for the end users.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.