IP communications services - voice, video and chat and the many variations therein - are all the rage again. Startups are sprouting daily. Though some focus just on mobile, many are building cross-platform applications.

When building such a service, the first and most important capability that you need to build is perhaps not so obvious. It is not wideband voice. It is not chat. It is automated (and silent) client software upgrade. 

The venerable operating system has been around almost as long as the computer has been in existence. Though the "computer" has changed - from mainframes to PCs and now to mobile devices and tablets - the role of its operating system is largely similar. The OS abstracts the underlying hardware and provides applications access to those hardware services. These services typically include file system access, network access, graphics and sound, and of course memory and compute. These are accessed via APIs provided by the OS.

In this post, as in others I write, I speak for myself and not on behalf of my employer.

Cloud means many different things to many different people. For me, cloud is a software architecture and development model for Internet applications that enables continuous delivery to users everywhere. 

One of the keywords in there is continuous delivery. With the cloud, it becomes possible for a software development team to make changes to their application, push the resulting build into production, and have it propagate to some or all users of the application automatically - all within minutes. This is quite different from traditional boxed software. In a boxed software model, once a development team finishes building an application, there is a lengthy process of distribution and upgrades across the user base which can take years. Compare, for example, the time it takes users to get an upgrade of Facebook vs. the amount of time it takes to get an upgrade of Microsoft Word. When Facebook makes a change, that change propagates server side and within the corresponding client-side HTML/JS within moments. Mobile apps still require upgrade on slower cycles, but with the advent of automatic upgrade in mobile app stores, the process of client side upgrade is getting faster. With boxed software, the new software itself must be distributed through physical means, and the owners of that software must opt-in and go through an upgrade process. For IT-provided applications that run in an IT managed data center, the boxed software upgrade process is often even slower. 

So what?

When combined with instrumentation and analytics capabilities, cloud enables a virtuous loop of software improvement:

In this cycle, a development team can build capabilities into their software, deploy those capabilities a short while later (after the battery of automated tests have run), and immediately gain feedback on how the software is performing in the hands of users. This feedback can be in terms of performance - how long does it take to send the message? How many messages don't get delivered? - or engagement - how many messages per day are users sending? Do users send messages in clumps? What is the typical clump size? or other factors like revenue, quality, reliability, and so on. With this data fed back to the development team, they can learn from these metrics and build improvements into the software. Perhaps that improvement is to fix a bug, or to improve a database query to reduce response time, or to add another data center to improve loading of the page. Once that improvement is identified, it can be developed and deployed, and the process continues. 

When this entire process can happen within hours, it changes the way you write software. It enables decisions to be made based on data, instead of guesses. If you think about how much software is written based on beliefs, guesses, or theories about what will happen in production, you can begin to appreciate how powerful this is.

Instead of guessing whether you need all 10 features for users to utilize an application, you can ship it with the first two and see whether you get the engagement you need. If not, add another and measure again.

Instead of guessing whether you need to optimize your database query for better performance, deploy the non-optimized query, measure the overall latency for the user to use the application, and determine whether the database query is even the most significant part of the overall user-observed latency. If not, don't optimize it.

Instead of guessing whether your service is reliable enough for delivering messages, measure the overall message setup delivery success rate for users, determine your threshold for "good enough" (two nines? five nines>", and if its not meeting the threshold, look at instrumentation to determine the top root cause for undelivered messages. Fix that, deploy, and measure again.

Because this feedback loop does not exist in boxed software development, lots of energy and time get wasted in developing software that doesn't actually make it better or achieve the goals driving that development. With cloud, continuous delivery means you can focus on what is important by measuring it. For teams not used to this model, its a real learning curve. Engineers love to optimize and add features, and so it is their natural inclination to do so. In cloud software, you make different decisions. Instead of optimizing, you add a metric that allows you to measure. Instead of adding a feature, you add analytics that allow you to understand usage. This is not just a new process, its a mindset change. But once you make that change, you realize it is so, so much better.

SImply put - cloud software is fundamentally a better way to write software, because it allows you to grow it through experience, not guesswork.