To do the Cloud, you must be the Cloud.

I mentioned in an earlier post that I had been interviewing at a number of very smart companies lately, where all of them are truly pushing the boundaries of how computers are meant to be used in various environments.  For the ones that truly are stellar, there is one commonality.  They don't just do the cloud.  They live in the cloud from start to finish.  There are no hulking desktops, only powerful mobile Apple laptops.  There are no large enclosed areas housing any kind of development infrastructure, it's all in the cloud.

I can appreciate this, as exactly the same thinking applies with respect to the design of secure software.  I receive far too much credit for being far too knowledgeable about security because of a simple conclusion I reached a long time ago.  The first step is simple.  Don't do insecure things, to wit, don't use unencrypted communications.  Ever.  Not even in R&D. Never ever ever.  The result is that you will never wake up in a cold sweat wondering if the right security flags got thrown in your last release.  In my world, crypto was always on. Communications were either secure or unavailable.  In what I have seen for best practices in the cloud, the rule is the same.  The truly knowledgeable players know that the cloud is not a destination, it's where you live.

Let’s consider some issues that confront business with respect to the cloud.  The foremost is pricing.  Customers do not respond well to prices that vary by usage, yet the business only knows at the end of each month what that customer cost.  Yes, there's lots of ways of breaking it down, but there is risk there that isn't there if you're hammering on your own capital equipment.  That said, the business has also probably been negotiating its way through ever more complex internet provider contracts over the years, so this isn't the first fixed/variable cost IT problem that's ever shown up.  The issue is that the cloud is new and mysterious and there's not a lot of data to project from.

In developing an application, it’s a given that employee costs will dwarf any other expense.  That is exactly why it is best for the business to move the entire effort into the cloud, for no other reason than the data acquired will be invaluable in pricing, and any capex with respect to infrastructure will be eliminated.  Early development will give you smaller measures to allow you to estimate risk of 'oops, something happened that made the machine go permanently crazy and run flat out for 24 hours'.  Later development gives you detailed metrics from all of the software testing artifacts.  Some of these artifacts specifically exist as test cases for edge conditions, i.e. beyond what is considered the boundary of the systems capabilities, and tests for what the power customers do, i.e. ask for lots and lots of complex operations.  With actual cost values from the latter development and some feeling for risk with earlier development, there's enough information in hand to factor a variable cost cloud solution into a competitive fixed price.

In considering the creation of a cloud based solution, a 'pretty much' cloud based solution is as pointless as a 'pretty much' secure application. Consider the cloud.  Large numbers of geographically distributed machines with very fine grained capability/cost selection, capable of providing world class performance all over the world, and tended to every second of every day by highly skilled highly dedicated teams.  Now consider your proprietary IT infrastructure.  I'll wait.... 

If you were to ever end up entangling some poor beast in your own IT infrastructure with the cloud, now you have one machine that has to serve or interact with machines in the cloud that effectively never go down, can duplicate themselves all over the world in response to live customer demand, while your machines are fixed in space, cannot get bigger or smaller whenever they want, and it's your problem if the CPU just burst into flame.  The instant you have a 'pretty much' cloud based solution, you're going to have to write any SLA with respect to the capabilities of your machines. Unless you are very large indeed, or have truly peculiar requirements, the economies of scale pretty much prove you've got a losing proposition out of the gate.

I could go on, but why bother?  This isn't a direct argument for why one should go to a pure cloud solution, rather it is for how to go to a cloud solution.  With respect to pricing the offering, by definition you will collect the test data necessary to price within any tolerance you want, and initial experience will allow you to adjust that price based on your appetite for risk.  With respect to delivering the offering, it's an all or nothing approach unless one wants to instantly become the weak link in the chain. Leave the workstations there if you have to, and let them talk to all the legacy systems.  For the cloud, every machine resource involved in the visualization, construction, and delivery of any solution should be in the cloud as well. 

In conclusion, consider it this way.  Though the stories are endemic, nobody wants to bug a key developer on their long delayed vacation and make them frantically try to remember some arcane detail. It's always that the situation is desperate.  You can never know when something might go wrong.  Imagine a world where that developer can provide the 15 minutes of arcane data and happily return to their vacation. Because they fixed what you needed, right from their phone.  And yes, it is more secure than if you locked everything up in your building.