For many organisations, the cloud and cloud-native application refactoring is attractive. This is often due to the belief that it will reduce complexity and risk for them, when compared to running their own DCs. The theory being that public cloud architecture is simpler.
By going all in, however, many modern “cloud-native” applications are built upon a multitude of solutions, services and elements. This could be anything from a third party PaaS / SaaS provider for ID management, to “rolling your own” caching and search solution. It could even be simply implementing a broad set of management tooling for code and infrastructure automation.
The diagram below represents the technologies involved in one such solution. It’s clearly a highly distributed application with dependencies across many different platforms and cloud-vendors! It’s also not the only example of a solution I have seen in the new cloud-native world!
The risk is, the failure of any single one of those SaaS, PaaS or IDM platforms, automation tools or API gateways could leave an application offline and its owners potentially powerless to resolve it! Developers are exchanging the complexity of building elements into their applications natively, for the risk of distributing (out-sourcing?) them out to other cloud platforms.
Public cloud architecture isn’t always simples!
That is not to say this is not a reason to go to cloud and refactor applications to be more cloudy! The relative benefits to an organisation may far outweigh the risks. The key thing is that in any organisation, requirements from the business will always trump any expectations of simplicity or even consistency!
We are simply exchanging one set of complexities for another!
Thoughts? Feel free to discuss in the comments below!
WARNING – Opinion piece! No Cloud Holy Wars please!
DR in IT can mean many different things to different people. To a number of people I have spoken to in the past, it’s simply HA protection against the failure of a physical host (yikes!)! To [most] others, it’s typically protection against failure of a data centre. As we discovered this week, to AWS customers, a DR plan can mean needing to protect yourself against a failure impacting an entire cloud region!
But how much is your business willing to pay for peace of mind?
When I say pay, I don’t just mean monetarily, I also mean in terms of technical flexibility and agility as well.
What are you protecting against?
What if you need to ensure that in a full region outage you will still have service? In the case of AWS, a great many customers are comfortable that the Availability Zone concept provides sufficient protection for their businesses without the need for inter-region replication, and this is perfectly valid in many cases. If you can live with a potential for a few hours downtime in the unlikely event of a full region outage, then the cost and complexity of extending beyond one region may be too much.
That said, as we saw from the failure of some AWS capabilities this week, if we take DR in the cloud to it’s most extreme, some organisations may wish to protect their business against not only a DC or region outage, but even a global impacting incident at a cloud provider!
This isn’t just technical protection either (for example against a software bug which hits multiple regions); what if a cloud provider goes under due to a financial issue? Even big businesses can disappear overnight (just ask anyone who used to work for Barings Bank, Enron, Lehman Brothers, or even 2e2!).
Ok, it’s true that the likelihood of your cloud provider going under is pretty teeny tiny, but just how paranoid are your board or investors?
Ultimate Cloud DR or Ultimate Paranoia?
For the ultimate in paranoia, some companies consider protecting themselves against the ultimate outage, by replicating between multiple clouds. In doing so, however, they must stick to using the lowest common denominator between clouds to avoid incompatibility, or indeed any potential for the dreaded “lock-in”.
At that point, they have then lost the ability to take advantage of one of the key benefits of going to cloud; getting rid of the “undifferentiated heavy lifting” as Simon Elisha always calls it. They then end up less agile, less flexible, and potentially spend their time on things which fail to add value to the business.
What is best for YOUR business?
These are all the kinds of considerations which the person responsible for an organisation’s IT DR strategy needs to consider, and it is up to each business to individually decide where they draw the line in terms of comfort level vs budget vs “lock-in” and features.
I don’t think anyone has the right answer to this problem today, but perhaps one possible solution is this:
No cloud is going to be 100% perfect for every single workload, so why not use this fact to our advantage? Within reason, it is possible to spread workloads across two or more public clouds based on whichever is best suited to those individual workloads. Adopting a multi-cloud strategy which meets business objectives and technical dependencies, without going crazy on the complexity front, is a definite possibility in this day and age!
(Ok, perhaps even replicating a few data sources between them, for the uber critical stuff, as a plan of last resort!).
The result is potentially a collection of smaller fault domains (aka blast radii!), making the business more resilient to significant outages from major cloud players, as only some parts of their infrastructure and a subset of applications are then impacted, whilst still being able to take full advantage of the differentiating features of each of the key cloud platforms.Of course, this is not going to work for everyone, and plenty of organisations struggle to find talent to build out capability internally on one cloud, never mind maintaining the broad range of skills required to utilise many clouds, but that’s where service providers can help both in terms of expertise and support.
They simply take that level of management and consulting a little further up the stack, whilst enabling the business to get on with the more exciting and value added elements on top. Then it becomes the service provider’s issue to make sure they are fully staffed and certified on your clouds of choice.
*** Full Disclosure *** I work for a global service provider who does manage multiple public clouds, and I’m lucky enough to have a role where I get to design solutions across many types of infrastructure, so I am obviously a bit biased in this regard. That doesn’t make the approach any less valid! 🙂
The Tekhead Take
Whatever your thoughts on the approach above are, it’s key to understand what the requirements are for an individual organisation, and where their comfort levels lie.
An all-singing, all-dancing, multi-cloud, hybrid globule of agnostic cloudy goodness is probably a step too far for most organisations, but perhaps a failover physical host in another office isn’t quite enough either…
I would love to hear your thoughts? Don’t forget to comment below!
Conversations (and arguments) are prevelant in the industry today about moving to the cloud, be it public cloud, private cloud or hybrid cloud.
People are developing into the usual fervent “religious” groups depending on their personal biases and use cases, and today Pure Storage joined the discussion by announcing a new feature for their FlashStack product. Working in partnership with Equinix, they will enable you to effectively colo a replicated FlashStack device in an Equinix DC, then use it to mount volumes via iSCSI, straight into your instances on AWS and Azure.
This is an interesting solution and having discussed this with several other guys at Pure Accelerate, the general impression is positive for two main reasons/uses:
Legacy solutions which depend on traditional enterprise infrastructure / storage patterns and performance.
As a sales enabler for Pure – Ticking checkboxes for FlashStack when”Is it cloud integrated?” comes up in an RFP.
It’s a cool idea, but personally, I am still struggling to find a really compelling use case for this, and I do slightly worry for Pure that they are providing an easy on-ramp to the public cloud for their customers. Once the compute is up there, comfort with the public cloud grows, and applications are refactored to be more cloud-compatible, the primary storage will undoubtedly follow. Pure do run the risk eroding a percentage of their customer base in the long term.
I guess only time will tell, but I hope this little gamble does not turn around to bite Pure in the rear later!
Hybrid FlashStack integration is available on Azure today, with AWS coming soon…
Disclaimer/Disclosure: My accommodation, meals and event entry to Pure Accelerate were provided by Pure Storage, and my flights were provided by Tech Field Day, but there was no expectation or request for me to write about any of the products or services and I was not compensated in any way for my time at the event.