One of the hottest topic in the IT industry for several years now has been cloud computing, for some very good reasons – reducing capital and operational expenditure, offloading management of routine tasks to highly automated systems, and are some of the top reasons among many. As a direct result, there’s a lot of companies who are creating solutions for or on cloud platforms – and there’s a huge distinction between the two!
tl;dr if you’re thinking about starting a company to provide a solution that fills a functionality gap, you better be prepared to hit a moving target – constantly, with far more variation than traditional gap-filling for on-premises environments.
This post falls cleanly into the ‘random thoughts’ category. It’s a topic I’ve been ruminating on for a while, as I’ve been trying to understand why certain companies I’ve worked with don’t grow, and others do. There’s a multitude of factors beyond those which I’m calling out here, of course – I’m not a business analyst.
Currently, the landscape for cloud computing is dominated by the two giants – Amazon AWS and Microsoft Azure. They’re at war, and therefore there’s changes and improvements every day. Features that your project uses today may be deprecated next week, and removed in two years. This isn’t a frantic pace, but product managers need to stay on top of the changing landscape.
When developing solutions that run on infrastructure you don’t directly own, there’s some differences in the approach that must be taken. I talk a bit about that in my App Modernization posts (part 1 and part 2). Adopting a DevOps model – with the attached concepts of blameless postmortems and failing often and failing fast – is essential to success here. The ability to rapidly change your approach, to rapidly change your architecture, and to quickly see, understand, and fix a failure in your code is critical for success when working in any IT environment today – in particular when working on a platform managed by someone else.
However, there’s a whole class of products that are not simply built using cloud components, but are rather built on top of a solution, usually to fill a gap – examples include the Mobile Console for Microsoft Azure, Office365Mon, or Softchoice’s own Cloud Management Dashboard. There’s nothing inherently wrong with any of the solutions – and in fact, some may be quite brilliant. However, one should always consider whether the identified gap is large enough that the provider will simply assign 100 people to fill it – leaving your 10-person team with a half-finished product that’s been outclassed. If you’re not anticipating a shift like this, you’ll have trouble succeeding. This isn’t especially new, but in on-premises systems, you can tell your customers you’re not prepared for the latest version of the software you interface with, and they will not upgrade until your product is ready. However, with cloud computing, you may not have any warning of a breaking change coming (if you’re not using a documented API), and in any case, you don’t get a choice – you get a deadline to change. This can make the value proposition of your solution considerably less attractive.
It’s a great idea to create a service ON a cloud platform. It can help you control your costs as you grow, by enabling you to scale with your revenue (you ARE planning for that, right?) and by providing a very low-cost buy-in. You gain a competitive advantage over those who are continuing to maintain on-premises infrastructure, by eliminating an entire department. It’s not such a great idea to rely on the stability of a product gap on which to base your business.