With all the options available to use from IAAS to SAAS, hybrid to private, understanding whether or not you have, or could benefit from, a cloud solution can often to lead to some debate as to what qualifies as earning a ‘cloud badge’. For me, as an architect of software, I find it’s not so important to consider where your systems are located so much, rather to consider whether your solution allows full employment of the more significant advantages that the cloud has to offer. First, I think it’s important to distinguish between the generic cloud and the managed cloud. By that, I mean the generic cloud has been around for ages and is a way for companies to offload their on-premise physical hardware into a remote server hosting provider. Often this involves one or more powerful physical servers hosting virtual machines. Deploying a website to such a machine would then allow you to proclaim you’ve created a cloud solution. Managed cloud is what I would refer to as being Microsoft Azure, AWS or Google Cloud Platform etc. There are others but these 3, in my mind, are targeting the widest audience within IT and software, offer more than just supporting their own native tools and are growing the fastest. Yes, you could use any of these providers to provision a virtual machine on to which you deploy a website but anyone who has taken this approach will find they have missed the point somewhat. The driving purpose behind ‘moving to the cloud’ is to benefit from as much of the managed element of the cloud provider as possible without giving up more control or customisation then you are prepared to accept. Here are my top ten benefits of what I look for in designing a cloud solution.
- Deployment automation – can you release your solution time and again through automation with rollback options?
- Low upfront cost – can you avoid investing heaving in reserved capacity and resource before you really need it?
- Resource management – are you able to hand off management of underlying dependencies that are not part of your remit?
- Easily scale – when your solution needs more grunt can you get it instantly without downtime?
- Automatic Failover – can your solution detect a failure and automatically stay up and running?
- Geo-redundancy – do you have the option of protecting against a significant regional outage without having to lift a finger?
- Global Performance – do you have the option of replication across the globe to ensure low latency wherever you end users are?
- Metrics & Monitoring – is this built in with the option to provider automatic alerts under certain events?
- Hybridisation – can you configure site-to-site networking between on-premise and your cloud solution without requiring manual intervention by the cloud provider?
- Enterprise integration – can your solution integrate with other solutions both in the cloud and on-premise with minimal or even zero-code solutions?
So, if your cloud solution requires you to submit a ticket to request an upgrade to the host, or you need to email someone in support to ask them to take a look at how a node is performing, you may be in the cloud but getting into the cloud is just a first step at opening up the possibilities to make your solution the best it can be. It’s just as important to consider how you can build those benefits into your solution to ensure you don’t just have a cloud solution, but you have a solution that has been built for the cloud.