Cloud integration and portability

posted 29 Aug 2017, 08:55 by Lee Newcombe

Integration and portability – either working across multiple cloud providers or else shifting workloads from one provider to another – remain amongst the trickier areas of cloud strategy and security.  Different business strategies and priorities will drive different approaches.  For example, if you take the view that service resilience is your primary concern then the idea of placing all your eggs in one basket, even one as well made as AWS or Azure, may be anathema.  This can then drive architectures that must either split components across multiple cloud providers so as to reduce impact of compromise (including outages) or to use a secondary cloud provider to provide contingency in the event of a failure of your primary supplier.  If you’re going to support portability (the ability to shift workloads between cloud providers) then you need to avoid lock-in which can drive you towards containerisation such that you can take your encapsulated infrastructure from one provider to another – subject to tooling and skills.   This does mean that you end up abstracting away from provider-specific APIs and capabilities where you can (e.g. containerisation, deployment of “cloud management platforms”), which is counter to the idea of going truly cloud-native in this author’s opinion.

What about integration?  This is a more interesting proposition.   Why not use Azure AD (or other cloud-based identity provider) to manage the identities and entitlements used across your cloud supply chain?  Why shouldn’t you send audit logs from a variety of cloud providers to AWS S3 buckets and then Glacier for long term storage (or to a cloud-based SIEM service for analysis)?  Why not go for a distributed microservices architecture with consumable services hosted across cloud providers? You do introduce additional complexity however, for example, how will you

  • secure network connectivity?

  • encrypt data in transit and at rest and perform the necessary key management?

  • authenticate and authorise interactions?

  • consolidate security monitoring and incident response?

  • consolidate billing to maintain a view on costs?

  • maintain an understanding of where data is flowing and why?

  • track operational responsibility for service delivery?

  • secure, monitor and track usage of the exposed API’s enabling integration?

  • secure your automated deployment pipeline across the diverse supply chain?

  • prevent latency-sensitive services from becoming reliant upon multiple traversals over the internet?

  • set and manage service levels for in-house applications built on a multi-cloud platform?

But if you either make use of provider APIs or front your own services with your own APIs then this kind of integration of “best of breed” services can support a move towards truly cloud-native approaches without being utterly reliant on a single provider. That said, failure of a cloud provider hosting a critical component could still take down a multi-cloud hosted microservices-based application if it’s not built with resilience in mind.  It’s also worth noting that adoption of PaaS or FaaS services will abstract away some of these issues for you!

The simplest approach however may well be to pick a cloud provider you are happy with and go all-in (albeit with minimal but necessary intregration such as federated identity).   Complexity is, and will remain, the enemy of security.  If you are prepared to accept the low risk of multi-region cloud provider outage then perhaps you would be best to avoid the complexity of full-on integration or portability and concentrate instead on account-based segmentation of services within a single provider.  

In summary, there is no one-size fits all approach.  Portability may overly constrain your virtualised infrastructure, negating many of the perceived benefits of cloud, whilst some level of integration is likely to be necessary (e.g. federated identity management).  The big question, as is often the case with cloud, is one of trust.  Do you trust your cloud providers to be there when you need them or do you need to engineer in contingency cloud-provider arrangements?  The choice is yours.