I’ve been involved in many discussions about possible engagements to deploy infrastructure on Azure, they all inevitably lead to the same question; “Why should I spend weeks having a design documented for me when all I need is a credit card and the web portal?”.
The promise of the Public Cloud is such that you can cut out all of the heavy overhead that IT departments bring. With their design, planning, controls and what not that holds up progress. You need results and you need them now, you have your credit card so you can just go ahead and spend the afternoon clicking through to build what you need on your own. But, is this such a good idea?
In my experience, not usually. If you’re in a situation where you want to spin up some infrastructure quickly to just try out an application or test a concept that you have been working on then perhaps that is the right way to go, but if it’s anything more than that, take a pause.
If what you’re looking to do within Azure will lead to any proof of concept with management visibility, any production data being loaded into the service or anything where the user perception counts then you should engage in design services of some kind. It is often overlooked that Cloud Infrastructure is just as complex if not more complex than On-Premises solutions and while that credit card and web portal may get you up and running quickly it may not give you the experience you were looking for. This reflects poorly on you as the person who opted to use the service but also on the Cloud Service itself.
All too often I have heard complaints like “we moved our single VM application to Azure, but then we had downtime because the host was under maintenance, Cloud is supposed to be always on!”, or “we lost some data because we were taking snapshot backups and when we rolled back it caused issues with the application. Azure is rubbish if we can’t get our data back”. There are more like this but in every case I have heard, the issues have all been down to a lack of planning or knowledge of the intricacies of Azure itself.
With every Infrastructure project, there is a lot to think about; Network Security, location of Servers, how you will scale, how you will do backup, how you will provide High Availability, which services even need High Availability, how you will monitor your systems, what storage solutions you will use, what network address spaces and connectivity solutions you need, what your patching strategy will be … And so on. None of this goes away whether your infrastructure is in a public cloud service or otherwise, despite what the marketing of Public Cloud may have you believe.
If you have a project that you are considering running in Azure or any Public Cloud service that will have any kind of visibility which could be affected by an unreliable solution, seriously consider some expert consultancy and design services. Often, the experts will be able to deploy the solution faster and more reliably than you could by clicking through a web portal anyway. Of course, there is cost involved in this, but being presented with solid documentation that addresses the concerns that management and regulators will have will be worth the expense … But only if it is the right kind of document …
In the Cloud world, things change fast and for documentation to remain relevant it cannot be too specific. When I work with my customers I encourage them to go for strategy or framework style documentation, rather than traditional High Level Design, Detailed Level Design, Configuration Documents and so forth. The old style are lengthy to write and do not often cater for a responsive infrastructure that can scale up and down and change at will. Instead, I encourage an approach that establishes a solid set of principles and design decisions e.g. “We will use Azure Backup to a Single Storage Account with Geo Replication for all VM’s because …. Blah”. Because this does not directly reference specific Virtual Machines, yet lets you know to expect with any VM you find in your Subscription will be backed up this way, it’s just more adaptable, more relevant for a longer time and easier to change.
Any documentation that is produced should also clearly articulate the business requirements of the solution and how they are being met. This after all is the reason why you are spinning up a solution in the first place. This also acts as something you can periodically review to ensure the solution is still relevant, appropriate and providing the value that you were looking for.
So do you need Azure Design Services? If perception matters, regulators and management have questions you need to answer or you want to have a solid solution then absolutely yes. You can choose to keep it more high level and general however, then let your code (because you’re deploying as much as you can as code now, right?!) do the specific configuration documentation for you.
Cloud enables you to move faster, but not because it gives you a web interface and credit card access. Being able to move at speed is made possible by implementing a solid foundation and gaining trust in that foundation from all stakeholders, getting this right as early as possible and getting stakeholders on side is paramount to success. Or you may find your company AMEX cancelled.