I think the Cloud (IaaS, PaaS, Saas) is very cool. It's changed quite a few things in business, and in many ways, it continues to democratize lots of services and opportunities that used to require large investments. Now more companies and take advantage of the capabilities that they wouldn't have been able to in previous years. In some sense, this is the same as hypervisors allowing many of us to simulate and build large labs of multiple machines for a fraction of the cost that would have been required 20 years ago.

The cloud isn't for everyone, and certainly not for every application, but it can be very useful. I find more and more companies making a move, at least in part, to some cloud service. Often it's AWS, Azure, or Google Engine, but there are plenty of other choices that people use. Whether it's a small PoC, a lift and shift, or complete change to a cloud service, I bet most companies are doing something in the cloud.

And getting surprised at times. There are security issues, and at times, downtime disruptions, but the number one issue I find from most companies is the cost. Yes, the cloud can be inexpensive to get started with, but the costs can quickly grow, often in surprising ways. I ran across a piece on the hidden costs of serverless computing, which is one of the most interesting and exciting ways of building applications. It's also one of the more complex from a pricing model.

The article looks at the various hard costs, many of which may be difficult to estimate. Do many of really know how often someone might trigger some function in an application? If we string together a whole series of these in a serverless fashion, can we be sure of the execution flow, much less count of calls? This doesn't even begin to discuss the development labor side of writing, tracking, understanding how these fit together, and more. I can imagine a situation where serverless functions are never deleted and new ones added because of the fear of breaking some part of an application. Just like applications tend to grow and developers fear touching old code, I wouldn't be surprised to see that happening here.

Since most of these functions will need to touch data at some point, the data store will come into play. Whether this is an RDBMS, like SQL Server, or a NoSQL store, like CosmosDB, certainly we'll find linkages and dependencies that we manage. Perhaps we'll get stuck maintaining APIs in our data stores, and using de-normalized structures to keep multiple copies of data in sync. I wouldn't be surprised to see data transfer costs become an unexpectedly large cost over time, with poorly architected applications, thrown together to meet one tiny request at a time.

I like serverless computing, and for small Proof of Concept (PoC) or IFTT like data flows, simple, narrowly focused applications, this likely works well. Replacing any large scale, complex workflow line of business app? I shudder to think, though the cloud vendors might be thrilled if you try.

Join the debate, and respond to today's editorial on the forums

» Discuss this question and answer on the forums