Cloud agnostic - an approach you might want to avoid
- 1. Jelizaveta Malinina Cloud Agnostic An approach you might want to avoid
- 2. Introduction Notion of “Cloud Agnostic” has been around for some time and while there are companies that might have found this strategy correct for their use cases, in the vast majority of scenarios it’s better to avoid adopting cloud agnosticism.
- 3. What does Cloud Agnostic mean? The term ‘Cloud Agnostic’ refers to tools, services, applications and workloads that can be moved fluidly between cloud platforms without being bound by operating dependencies. Such architectures assure companies of consistent performance regardless of the cloud provider and allow to choose cost-efficient solutions without sacrificing the performance.
- 4. Who might truly benefit from Cloud Agnosticism? The decision of adopting the approach heavily depends on the specific use case. Two most common reasons for using cloud agnosticism: • Create products compatible with any cloud provider • For greater region coverage
- 5. Products compatible with any cloud provider Cloud agnosticism is a good fit in cases where you aim to maximize target audience of your product by avoiding cloud provider entry barrier. Some of the companies following Cloud Agnostic approach for this reason are Cuddle.ai, Experian and Snowflake.
- 6. Region Coverage Alternatively, if your product is required to run in multiple regions and there are limited number of Cloud providers that operate in the desired region — Cloud Agnosticism can help you to manage that. For example, at the moment only Microsoft Azure is present in Switzerland (however AWS is planning to expand to Switzerland by 2022).
- 7. Why to avoid Cloud Agnosticism? Being cloud agnostic looks great on paper, but the reality of implementation can be much more arduous than it’s worth. There are multiple reasons why you might want to avoid this strategy, below are a few to consider. • Upfront Cost & Complexity • Common Denominator • People
- 8. Upfront Cost and Complexity Even though one of the benefits of a Cloud Agnostic strategy is its cost effectiveness in the long run, it initially requires substantial time investment and upfront cost. To build a proper cloud agnostic solution a lot of complexity and levels of abstraction need to be introduced.
- 9. Common Denominator In contrast to “Cloud Native” approach, where applications or tools are being designed to take advantage of all strengths of a chosen cloud provider, “Cloud Agnostic” solutions focus more on the breadth of support, rather than the depth. In other words, you cannot use unique features that are specific to one of the cloud vendors in a cloud agnostic application/tool, and you are restricted by so called common denominator of tools provided by all cloud vendors.
- 10. People Another thing to keep in mind is your human resource’s ability to work in multiple clouds or willingness to invest their time into acquiring knowledge of a new cloud provider. Developers tend to specialise in one cloud vendor and might want to continue working with technology they already excel at, without investing tens or even hundreds of hours learning a new toolset from scratch. Cloud technology is evolving fast and it is already time consuming to stay up to date with all updates from one cloud vendor not to mention all the clouds.
- 11. Easier ways to avoid vendor lock-in One of the main reasons for companies to start thinking about adopting cloud agnostic strategy is to avoid vendor lock-in. But there are some commonplace practices you can follow to take steps towards abstracting yourself away from a specific cloud and still utilising all of its unique features. • Containers • Loosely Coupled Architecture Patterns • Global Libraries • Standard Protocols • 3rd party tools for Infrastructure as Code (IaC)
- 12. Containers Architect systems to be as decoupled as possible using containers which allow for easier portability between providers should there be a compelling reason to switch.
- 13. Loosely Coupled Architecture Patterns Another way to decouple your application and avoid vendor lock-in is by using one of the loosely coupled architectural patterns, below are a few to consider. • Hexagonal Architecture (aka “Ports and Adapters”) • Onion Architecture
- 14. Hexagonal Architecture It’s a pattern that promotes decoupling from technology and frameworks, and separation between Business Logic, User- Side and Server-Side. Its initial intend is to “allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run- time devices and databases”.
- 15. Onion Architecture Onion Architecture is comprised of multiple concentric layers interfacing each other towards the core that represents the domain. The fundamental principal of an Onion Architecture is that all layer dependencies are pointing inwards.
- 16. Global Libraries Consider building custom in-house functions and libraries instead of using cloud specific ones that would tie you to one vendor.
- 17. Standard Protocols Adopting Standard Protocols over the Proprietary ones offers a higher degree of flexibility and more integration options. Consider the following approaches: • Use standard protocols for service communication such as HTTP, AMQP and gRPC which are not vendor specific and are supported by many operating systems and cloud environments. • Use open-source databases such as MySQL and PostgreSQL that are available on almost all cloud providers. Their JDBC and ODBC drivers are also among the most common database adapters. • For standardised authorization and authentication use OpenID Connect over vendor specific solutions.
- 18. 3rd party tools for Infrastructure as Code (IaC) Every cloud vendor has its own mechanism of running infrastructure templates; however, the vendor-specific syntax of each tool makes it much harder to switch from one provider to another. To solve this approach in a cloud- agnostic way, several 3rd party tools allow you to script your infrastructure on most leading cloud providers, giving you an abstraction layer to the underlying IaaS. Terraform, for example, provides you with APIs to work with each of the leading public cloud providers and many on-prem virtualization platforms.
- 19. Successful companies using only 1 public cloud provider: To back up theoretical points by real life examples below is a list of companies that are not only big players but have also decided to stick to one public cloud provider. • Spotify — announced that it is going all in on Google Cloud Platform (GCP) back in 2016 • Netflix — the most prominent early user of AWS, adopting it in 2009 and is one of the Amazon’s cloud big users. But apart from Amazon’s cloud Netflix also uses its own Content Delivery Network. • Lyft — in the beginning of 2019 Amazon Web Services has announced that Lyft is going all-in on the AWS. • Slack — has been running on AWS since its inception in mid-2013.
- 20. Conclusion Decisions about going cloud agnostic or cloud native, or which cloud management solution to choose, shouldn’t be made in a silo. A lot of things should be taken into consideration such as the purpose of the product, geographical location and the knowledge your team has. In summary, it’s overall recommended to choose a single cloud vendor and not building a cloud agnostic platform.
- 21. Questions? More information can be found here Or message me on LinkedIn