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:
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