I wish this post wasn't downvoted because I think it's a valuable one, even if it relies on a perception that I don't think quite holds. In my experience, what

I wish this post wasn't downvoted because I think it's a valuable one, even if it relies on a perception that I don't think quite holds. In my experience, what everybody calls "devops" mostly encompasses human problems. It's about communication and clear goals and having empathy for the other people around you who rely on you and on whom you rely. You can't "-as-a-service" human problems. And this article, IMO, demonstrates that well--they're talking mostly about people, except where services just have to plug together and wait for that human to come by with a roll of duct tape. Technical: honestly, meh. You pick a cloud, you use their hosted services where it's safe to and you pull something tested off-the-rack where it's not (i.e., I am all over RDS, but I steer clear of DynamoDB--that sort of thing), you go on with your day. Over time you'll probably (everyone does, and IMO it's at a point of maturity where I am, too) gravitate towards containers, using them to make the "developer" part of the stack taller and leveraging tools like Kubernetes to handle much of the deployment side. Operations' bailiwick is then (fortunately) much more restrained, and in the two-stddev size scale that stuff is just not that complicated. What does become complicated is people. Having tried to -as-a-service the technical side of things in ways beyond "hosted X", it quickly becomes something where the business processes of your company (the bits that actually matter) inevitably require doing something-or-other in a sufficiently bespoke manner that an "-as-a-service" option for that becomes at best clumsy or at worst hostile. (I'm reminded of stuff like Rightscale or AWS OpsWorks when I say that, though my product was rather more in-depth. Probably to my detriment; it made it even harder for bespoke processes to fit into the system!) Invariably, the challenges for almost all of my client are people challenges. Training developers into their roles' expansion, training operations people into a culture of and a habit of automation, and facilitating frank and open discussions between them. That stuff is hard. IMO, it's also the rewarding part of devops, and it's the part where your team can be a multiplier rather than an adder. But I do think that ownership of the orchestrative bits of the technical side are still (maybe always?) necessary in order to have something to multiply. (Usual plug: I both advise and assist with implementations on the technical side and I consult, travel and remote, on the human side. Happy to chat and help figure out if and how I can help you and your folks. Contact details are in my profile.)