We subscribe to *how many* cloud services?

If the tale of Rip Van Winkle were rewritten about a software manager, Rip would fall asleep in 2005 and awaken today to find all of his servers that used to run in the closet sold on eBay for pennies on the dollar, and all of his software running in the cloud.

While the rise of AWS and other cloud platforms is well-documented, ol’ Rip would also be surprised by the scope of the ecosystem of third-party services, all cloud-based, for project management, CI/CD, testing, monitoring, etc. Unlike a cloud platform, these services don’t replace your old servers; rather, they replace your own labor to implement these services and features.

For software developers who have come of age since the start of this cloud-based revolution, the proliferation of third-party cloud-based services is a given. In a recent discussion with one such developer, I argued that our team’s 15 engineering cloud-based subscriptions was “a lot.” The developer looked at me like I had just woken up from 2005 with a long beard. These days, then, what’s a typical number of cloud-based software services?

​
​A non-scientific survey
To find out, I conducted a survey of fellow members of a local group of technology leaders — the DC CTO Club. Based on responses from 11 DC-area CTOs, the number of cloud service subscriptions (not including AWS or other platforms) ranged from 2 to 22, with a mean of 10.6.


​To put this in perspective, that means a typical software development shop has chosen “buy” ten-plus times when making a build-vs-buy decision on services available in the cloud. Why are cloud-based services chosen repeatedly? I see three reasons:

1. Price — Let’s say a new monitoring dashboard would take one of your developers four weeks of development time to build. At a conservative $60/hr fully loaded, 40 hours per week, that’s almost $10,000. And that number doesn’t include product management, project management, QA, or maintenance. Compare that to $15/month per host for DataDog Pro, and it would take a lot of host-months of monitoring to justify a “build” decision.
2. Quality — for the cloud-based service vendor, that service (monitoring, project management, automated testing, you name it) is core. For you, it’s not. Most likely the third-party service is better than what your engineers could build on the side, and since the vendor needs to continually improve their service to fend off competitors, the gap will grow over time.
3. Immediacy — for a fast-moving software team, immediately being able to integrate a new cloud-based service is at least a couple of orders of magnitude less impactful to flow than defining a new project to build the service, implementing the service, and only then integrating the service.

​Buy vs build vs bag?
Is there any reason to build instead of buy a cloud-based service? Sure. Maybe your HIPAA or other security requirements aren’t met by a third-party service. Maybe you have esoteric technical requirements, like binary-encoded messages, that can’t be satisfied by a cloud-based service like Pusher.

You should also not use a new cloud-based service if you don’t actually and actively need it. This bears mentioning when the introductory cost of many cloud services is minimal and your engineers may enjoy exploring new and cool solutions to problems you don’t have. There’s a always a cost beyond the price — every new service is another moving part that incrementally increases the cognitive scope and complexity of your software. Depending on the service, it may also increase your cloud platform costs, edit-compile-test time, or page-load time.

​
​​Don't sleep through this revolution, Rip
Cloud services' ease of adoption doesn't mean you don't have to do your homework — you do. But in your due diligence, you may need to recalibrate your view of how many 3rd-party services qualifies as “extravagant” — look at total monthly spend across services, not number of services. For software infrastructure that adds value but is not core to your own development expertise, a robust, competitive ecosystem of third-party cloud vendors means you’re more likely than ever to find your needs met by a new service subscription (even if it’s your 10th).


In another post, I’ll follow up with some of my and others’ favorite third-party cloud-based services.

Also published on CTO Craft

---