Thoughts on Azure Stack and Multi-Cloud Strategy
What is Azure Stack? Is it truly Azure-In-A-Box? Why should one use it?
You know that it makes financial sense to move to the cloud. Cloud, if used correctly, saves you money. However, you do not feel ready to take the plunge yet. There may be several reasons, including the perception of security, compliance to regulations, lack of consensus or the overwhelming need to ship features first to stay relevant.
However, the latest feature addition or the new component requires massive warm storage. Your developers will store them somewhere, write code to retrieve and save the objects. Do not let the moment get bigger than the future. Build your application around Azure Stack. In two years, when you are finally moving to Azure instead of writing another big check for hardware refresh, you will have one less part of your whole stack to migrate. You will be partially cloud-ready!
Azure Stack is your own private cloud sitting right inside your data-center. Your data is sitting on a bunch of exclusive dedicated servers that you procured. However, your application interacts with it via the same REST API-s, SDK-s, authentication mechanism and logistics as if it were interacting with Azure! Your infrastructure will be deployed using the same scripts and templates! This consistency makes moving to Azure a breeze down the line if you ever have to.
Right now, the Azure Stack preview is only available as a single server install. It is not anywhere close to the parity with the real Azure as it will be by the end of 2016. You will have PaaS components running on Azure Stack. You will be able to access the whole bunch of standard gallery images - not just Windows Server 2016 and Ubuntu. You will be able to create a cluster of Azure Stack servers in order to scale out your VM infrastructure.
Azure Stack is Microsoft's way of putting cloud within everyone's reach - treating the cloud as a model, not as a place.
I am confident in the continuous innovation cycle that the Azure Stack team has signed up for. In their first installment, they delivered:
- Web Apps
- MySQL and SQL resource providers to act as back-ends for the Web Apps
- Updated X-Plat CLI and Powershell support for Native SDK
- Productivity Boosters like Native Visual Studio support (enabling things like CI/CD right from inside Visual Studio)
I would love to come back and discuss about the differences and similarities between Azure Stack and OpenStack in details! OpenStack is very promising, but doing OpenStack at enterprise scale is not easy. It is signing up for too much - highly skilled IT Operations folks and need to refresh hardware every six to nine months are cost centers you should be aware of with OpenStack. However, it can make sense for medium sized operations spread across a single or couple of regions. OpenStack is a great tool for managing your own datacenter like a cloud, as long as you would not need to handle that deadly burst of traffic where you wished there was a public cloud to fall back on. It can still be part of your IT strategy - as it has some remarkable positives!
What About "Multi-Cloud" Strategy?
I also want to address something I have heard from several customers in their initial stages of cloud consideration - the fact that they do not want to "get locked in", the perceived strategy of spreading the eggs out in different baskets, the so-called "multi-cloud strategy". I want to address this concern here because the inevitable question that would rise in one's mind when deciding whether to go for Azure Stack is: will this lock me into Azure? Can I ever go back to AWS or Rackspace if need be?
I have almost two decades of development, design and architecture experience in several domains. I have created massive globally distributed systems - right from the envisioning to implementation and support. What I can guarantee you is that truly re-usable code and software is rare, and it takes a lot of farsightedness and painstaking design to make it happen. It is possible, but not many get it right.
Imagine for a moment that you indeed want to implement a cloud-agnostic strategy. All your code must then be designed bottom-up as extremely modular and each module boasting a generic interface where you can plug in cloud-specific libraries. Conceptually, you are building an electronic equipment that can be plugged into any wall socket around the world, so the inner mechanism should be completely abstracted from the power supply - you just delegate power access to one small detachable subroutine that deals with the myriad voltage and pin shape/size variations.
Does that sound easy to grasp? If so, it is actually oversimplification and not a true analogy for cloud-agnostic software.
Even if you painstakingly build abstracted multi-layered software for your functionality, monitoring, metrics, scalability, fault tolerance, HA, deployment, installation and DR - all of which can now run on both Azure and AWS (and can be a support and maintenance nightmare), you are now stuck with IaaS - missing out on the true revolution in public cloud - PaaS! If you have selected a CPM (Cloud Platform Manager) like Red Hat CloudForms, most CPM-s are only focused on keeping up with the IaaS features - compatibility with managed offerings are still quite a distance away! You may need to re-architect to use PaaS solutions to stay relevant in the market, as your competitors start to slash costs by moving to PaaS. They are churning out more features on a faster Agile sprinting cycle than your team can, because your team is bottle-necked by IT patching OS-s.
It may almost sound unfair that the major public cloud players are developing their own PaaS solutions with no commonality or uniformity in application consumption patterns. The truth, however, is that it does not matter. Because the level of effort needed to consume and build on top of PaaS services is orders-of-magnitude less than continuing to control your own IaaS environment. You may think that building cloud-agnostic software is a good strategy, but the LOE and TCO to do so are several times higher than writing the same thing for PaaS on Vendor 1, and then throw it away (or keep it) and re-write it for PaaS on Vendor 2!
Thus, a true bytes-duplicated multi-cloud strategy is very tough to achieve. It sounds great, it sounds like traditional wisdom to not put all your eggs in one basket. However, the cloud has not yet evolved to support such a strategy easily - or at least without significant pain!
And with either Microsoft or Amazon Web Services, one thing is certain. Capabilities will only grow, prices are not going up drastically. These two giants are locked in an epic battle, and customers will benefit from that!
It may make sense to have different parts of your operation on different clouds, but that is a discussion for another day!