“It’s in the cloud” seems to have become the default response to questions about resiliency and the redundancy of technology. Unfortunately, this is synonymous with a politicians answer, completely none committal and lacking in any form of detail. Due to the terminology, jargon and three letter acronyms (TLAs), used by cloud providers and the willingness for technical teams to regurgitate these magical solutions, it has made the cloud the default deployment strategy for any company board these days.
Before I continue, I have to admit that our company’s infrastructure is all in Amazon Web Services (AWS), and I am a massive proponent of cloud solutions. This isn’t just because my personal life now seems to be run by Amazon, I could not survive without Prime Delivery, Prime Now, Prime Music and the fact that I have not yet finished the first series of “The Boys”.
I have disclaimed my significant conflict of interest, my issue is not with cloud providers, it is with the default interpretation that all cloud deployments are created equal.
I seem to spend a significant proportion of my life, filling in due diligence questionnaires for financial institutions, or at least it seems like inordinate amounts of time, these due diligence questionnaires (DDQs) seem to have the same effect on time distortion as dentist waiting rooms or black holes. The most painful aspect being that they do not seem to have been updated since the 1990s, including such questions as the physical security of the data centre and destruction of hard disks. These are very difficult to respond to when AWS is gracious enough to indicate to its clients the country that its datacentres are in, but not providing any details. This is taking security through obscurity, to new levels, the only way to respond to these queries is by referencing WikiLeaks, which is not generally regarded as a primary or reputable source.
The fact that the American military is looking to outsource their technical infrastructure to either AWS or Azure via project JEDI, is a good way of addressing the concerns around security. The fact that this project is also annoying Oracle is a side benefit for anybody who has been involved in licencing conversation with said organisation. They are clinging onto their biggest client by throwing sueballs at these new upstarts on their turf.
It is clinging to the old technology, whilst claiming the benefits of cloud technology, that is my main gripe and adds confusion to the industry. There is significant difference between the old fashioned lift and shift of technology into the cloud and building cloud native from the ground up. For instance, for our data distribution business we use AWS DynamoDB as our backend database, trying to explain that this is a serverless database that is automatically distributed, across three different availability zones within a single region. To any of my clients that I have responded to via a DDQ, my main production database is globally replicated, providing me with six copies of the database in two different continents. If anybody managed to read to the end of this paragraph without their eyes glazing over, I am afraid to tell you that you might be a geek.
Trying to explain that versus previously, when I used to explain that I ran an SQL cluster with one node hot and the other cold, just deploying this into the cloud does not provide the same level of back up or redundancy around the technology. The capabilities, technology and language associated with the cloud have changed, but currently the validation and verification associated with the cloud are putting the end users at risk. The clients need to be educated, as to the capabilities of Lambda, Cosmos, DynamoDB, Scale Sets, EC2 instances, Kinesis, S3 and API gateways, the desire to create new and exciting names, has made cloud the flavour of the decade, but without the correct questions being asked by clients, they can be bitten, by the innate trust in the capabilities of cloud.
As another example of this new capability is backup, previously I used to undertake full backups at weekends, with incremental backups in quiet periods during the day. Recovery from these backups used to involve the invocation to my favourite deity and in extremis the ritual sacrifice of a goat. These days with cloud technology, I have point in time backups that allow me to recover my database instance to any second in the last thirty days, and I can recover these any time I wish (within the same region currently) to a new instance of the database and this is all done automatically with just the click of a button. Again trying to explain and justify this technology that has the same aim but manages to achieve it in significantly different manners and with massively different success rates.
Cloud deployments, are definitely the way ahead, the fact that our company has managed to create and deploy three identical environments, spread across the globe for development, UAT and production, with capabilities and functionality that organisations many times our size cannot yet achieve, speaks to the power of the cloud. However without the correct language or differentiation between deployments built in the cloud versus lift and shifted into a cloud environment, the use of cloud could become diluted and detrimental. Thus to provide the differentiation I propose the following “cloud native” for any products designed for full cloud deployments from the ground up versus “cloud interloper” for systems designed for on premise that are now hoisted into the cloud.
Bernie Thurston, CEO, ULTUMUS