Things Cloud Vendors Say That You Should Take With A Pinch Of Salt

Cloud business isn't easy. Many of the businesses in this space have not been able to sustain the competition, and have closed down or at the verge of it. The competition is so strong that even organizations that championed virtualization are finding it hard to find a ground to stand on. Google, Amazon, and Microsoft have found themselves with a sizable share in the highly competitive market. It is not surprising they are thriving considering all of these companies have the ability to build multiple billion-dollar data centers in various parts of the world at the same time, knowing that none of that money is coming back anytime soon. All this along with the continuous innovation that and engineering talent that need to go into this venture. Add taking care of industry compliance, local laws and regulations in various countries that need to be met. Needless to mention the massive marketing budget to top it all off, and make it all make sense. This post is about some aspects that you, as a cloud customer should care about and know about. These are some areas I believe to be not getting the deserved attention in the multi-billion dollar cloud marketing campaigns run by cloud vendors. The intention is not to say that all cloud professionals fall for these marketing misrepresentations, but unfortunately, there are far too many architecture/IT management crimes being committed that keep customers away from great technological solutions.

Pets vs Cattle

The phrase arises from the fact that conventional IT depts were fond of their servers and had names, much like you'd name your pets; when they fall ill your nurse them back to full health. The new paradigm suggests that you don't name your servers instead number them, like you'd do to cattle, when they fall sick, you get another one. Oh wow! you'd think; so did I. What's the reality of this notion? Does it apply to your business, to your applications, to your datacenter? This truth is that it works; it works for large data centers operating at cloud scale. Because the data center design is driven by the design of the software that runs the data center. If you're a regular IT dept on the consuming end of IT, you've got an infrastructure up datacenter that you adopted based on best practices. This means your infrastructure decides how the application should be hosted and run. The software design might not have the ability to be resilient to apply the cattle analogy. The app might not come up if a server goes down and you bring up another one. In technical terms what if that application is stateful and you're storing state outside and it is not cluster-aware. (There is a ton of such apps). Who does it work for then? As mentioned earlier, if your applications are designed to handle a failure of nodes where they run you can have the data center to adapt to the new app design. If you're aware of such architectural patterns chances are you're doing virtualization orchestration or containers or microservices.

Network Security

First off, I'm not challenging the talent and expertise cloud providers put in to make their platform secure. Cloud follows a shared security model, where the best security professionals in the world could be brought in to devise the best of security practices in the world. The result of such practices and innovation could be enjoyed by the customer of these vendors. But, then does that security apply to all skews of the cloud? Because, there are SaaS, PaaS, and IaaS. SaaS and PaaS are where the vendor does most of the infrastructure-heavy-lifting. But, in IaaS I'm responsible for the OS and the basic core infrastructure and the vendor takes care of the underlying virtualization and below. The message that cloud vendors have sent out on cloud security has often left a multitude of IaaS based infrastructure with basic security controls like networks security groups ACLs. In a conventional data center, network security was given more attention and care. I'm surprised as I'm alarmed with to find some deployments done with bare minimum security implementation on thecloud. The reality is that building DMZs, IPID, anomaly detection, placement of third party firewall appliances etc is all a necessity and are practices you should follow for IaaS based solutions, but very few people do it falling for the fake sense of blanketed security messaging sent out by vendors. Read the fine print on security best practices from your cloud vendor's product team when you design solutions for your customers. The certifications your cloud vendor has for security is primarily for their data center and you'll enjoy the benefits of those investments for a large range of your assets on the cloud, but that doesn't imply that you do not have to think of security again.

Serverless architecture

This is easily the cloud's answer to the selfie stick. Everybody has one and thinks it makes them cool. No, it doesn't. The wave and noise are around serverless are such that everybody is making their next app using serverless. Why? Why is there so much noise on this subject? The example scenarios are even more baffling, make a thumbnail of a picture user uploads and one would use serverless for performing this operation apparently. Consider you're a blogging platform and image uploads is one of the core functions your users would perform, would you be comfortable paying your cloud vendor for every upload a user makes? Or, would you take a conventional approach of dedicating an appropriately sized compute resource to perform this activity? Or, even a container or microservice to perform this. It is true that serverless has its benefits, and I see interesting opportunities for its use in edge scenarios of your application. Consider you're building an e-com app and you do fraud detection, the action you take in such an occurrence could be left to a serverless function. The point I'm making is you'd have significantly fewer frauds being detected in an e-com application in comparison to genuine transactions. It might not be wise to dedicate resources, like microservices or containers or VMs standing by for such an unlikely event. Also, if you're building low latency applications like chat or games or stateful services or long running tasks; serverless will set you up for failure; as serverless tech stands as of date. I'd like to see developments in this tech and be proven wrong about this in future though.

Cloud CoEs

There is a widespread belief among cloud service providers and cloud partners that, the way to differentiate themselves is by building themselves a cloud CoE. They are right to a very large extent about this because CoEs help build cutting edge tech capabilities that if a customer needs a complex solution that is off the beaten path CoEs can engage that assignment and get cracking. In other words, this helps build a strong technology track for a service provider. That's how I talk when I put on my rose-tinted glass and look at the world. While all that is rosy, one has to know and acknowledge that our customers come to us for a solution and our technology track is merely the means to accomplish that solution. More often than I like, I see affiliations to certain CoE or possession of a certification convert individuals to advocates of a certain vendor (myself included). It is through careful and conscious effort that you should differentiate between your affiliations and customer's definition of accomplishment. You've to step outside of the affiliation mind block and build that solution or get your solution vetted by an individual from an alternate cloud CoE. When an organization is setting out to build multi-billion dollar ventures at hyper-scale their marketing muscle will also be massive. Traditionally marketing has been on the forefront of driving customer happiness; if you're an architect or plays a role in the capacity of designing or influencing cloud-based solutions, read the fine and print to ensure customer success.

These are some irks that I've observed in the messaging from cloud marketing teams, please free to share your views and thoughts.