The major cloud platforms are restrictive by design. Accept it, understand it, and design accordingly. Sometimes you just have to change your design to fit the cloud platform.
Let’s start at the beginning.
When you listen to the cloud vendors they will describe their platform using terms like: scalable, flexible, on-demand, choice etc. It’s the promise of the software defined datacentre. A datacentre with no limits (as long as the colour you choose is black – a nod to Henry Fords 1909 description of colour choice with the Model-T). Cloud platforms are restrictive. Put another way, you have to build your cloud from a set menu. There are minimal customisation options. This fact seems to go unnoticed until the very last minute. And I’m not sure why. I have seen architects freak out that they cannot find the perfect fit for a given design/solution.
Check out Josh’s post on the differences between the cloud models. Have a look at diagram showing the separation of responsibilities. When you hand over responsibility to the cloud provider you lose a level of control. When you hand over control, the cloud vendor removes your ability to customise. In return they give you a reduced set of configuration options. You are given a set menu and you design and build from the options you are given. What does this mean for the architect? It means you have to spend a lot of time understanding the service descriptions and the limits for your chosen cloud platform. It means you’re going to spend more time in the design phase that you are used to. Don’t worry too much though. You’ll more than likely make up time during the build process.
The process of investigating the service descriptions and understanding the limits is on-going. The cloud vendors are changing and updating frequently (which is a good thing). When I am designing I quickly put together the software requirements, compute, storage and network. I work through the cloud vendors list of available options and put a high level bill of materials together. Before going deep into the design I always look at validating things using a minimal viable build (mvp). This means I can validate, or fail quickly, before going into the detailed design. Let’s walk through an example. Earlier this week I was asked by a colleague to do an mock up for a product we are developing. We decided to use Microsoft’s Azure cloud. I mapped out everything that I needed and started the basic build. Network and storage went together quickly. The backend was built from a template VM in Azure. Everything seemed to be working fine. Things came to an abrupt end when I tried to get the client working in an Azure VM. Why didn’t the client work? The software needs OpenGL 2.0 hardware. Azure VMs don’t (at time of press – coming soon I’m told) have hardware OpenGL support. I can’t force a square peg into a round hole. The client is just not going to run in Azure right now. Right. So that’s it then?
“Sometimes you have to change your design to fit the cloud platform”. What if you change the cloud platform? Or even used two providers? Amazon Web Services have GPU enabled Virtual Machines that support OpenGL. This is perhaps an extreme example but in the end I used Azure to host the backend and I ran the client from AWS VMs. I designed from two set menus so to speak. Azure offered better pricing for the backend and I had no choice but to use AWS to host the client. The apparent restrictive nature the cloud didn’t freak me out, I designed around it. I validated that the solution worked. I validated that the cost model using two vendors was in budget. Side note: I was also open to the option of not using cloud at all.
Wrapping up. The cloud vendors offer great choice but from a set menu. Acknowledge that you are unlikely to get a 100% fit from the default offerings. Don’t let it freak you out. Do your homework on the service descriptions. Test and validate early.