Are you cloud agnostic?

Before I start swinging towards one option or the other (being cloud-agnostic or not), let's discuss what it actually means.

I am sure that we all hear a lot of brouhaha over being cloud agnostic, and most people believe that being cloud-agnostic means that we should be able to lift "all" our Cloud Infrastructure from one vendor and shift to other on a moment's notice. If you keep this as your principal tenet, then you will probably end up running private datacenter like infrastructure on borrowed cloud servers, which, in my opinion is not the most wise strategy.

However, I have seen multiple examples where teams (and probably companies) spend a lot of time and money in developing platform technologies that are readily available as managed service, only to realize that creating a robust scalable, distributed cloud platform takes time, effort and of course ongoing maintenance, which pushes their release and go-to-market cycles further. This is loss of potential revenue and unwise spending of resources.

In many cases, start-ups beat established companies to market by assembling readily available PaaS offering and creating value for customers. After all, most customers don't care if you have created your own Infrastructure or you used managed offerings from a cloud vendor. Point to understand is that, it is the product that sells and customers care about, not underlying infrastructure. And achieving the same quality and scale that a cloud vendor can offer is more-often-than-not a herculean task, which is best avoided.

By now, I must be sounding like an advocate for a vendor lock-in. Well, I advocate a hybrid approach, where you own most of your business logic and try using the cloud offerings that don't really lock you in with proprietary technologies. This can be achieved by making intelligent choices of suitable Cloud Services and by writing vendor specific wrappers around your code (check Facade Pattern).

For example, a simple Infrastructure that contains Data Processing, Storage, Message Queue and a User Interface could be built quite easily on AWS using EMR (Spark jobs for Data Processing), Kinesis (Message Queue), RDS (Storage) and React UI (use any of the AWS hosting solutions).

If you look at this Infra from the top level, you might see EMR, Kinesis, RDS and infer that this is locked-in with AWS.

If you look little deeper, Spark jobs are your business logic written in Java/Scala and can be ported to any Spark platform without any changes in core business logic. You have wrappers around your code to read data from Kinesis and will just change the wrapper functions to start reading from Kafka, this shouldn't be a huge investment. Similarly, let's say that you are using PostGres on RDS; all your DB Schemas, SQL Queries and Data can easily be ported to any other Cloud Platform providing PostGres. React UI should be straight forward too, you just need a Web hosting platform.

So, in this case, you just manage your business logic and leave every other aspect of Infrastructure management to the Cloud Vendor. Some of other things that you might get by intelligently using PaaS offering are Identity and Access Management, Auto scaling, High Availability, Disaster Recovery etc., without having to burn the time of your talented programmers on infrastructure management.

By no means, I am saying that you will be able to shift from one cloud vendor to other in a matter of hours, however by making intelligent choices you will save money and time and will be able to concentrate on what matters most (i.e. "Creating value for your customers").

And...you will have a happier team, that is not burning hours in solving the tedious issues of scalability and stability of the underlying Platform.