Google vs Azure vs AWS comparison. Part 2: Basic Cloud Services

Google vs Azure vs AWS comparison. Part 2: Basic Cloud Services

1????????Where are the technical strengths of the clouds?

In part 1 of this essay series, the author summarized the scaling possibilities of the big three cloud providers from the money and the technology – yes, also from the ethical side. Goal was to give an orientation to companies who seek to place workload in the cloud. These were the kind of reflections you probably would do first before digging deeper. This part however elaborates on base services in more detail. It focuses on offerings which will help you to burst out of your current boundaries into seemingly infinite computing, storage, and networking space. In doing so, it is rather difficult to do an “apple-to-apple” comparison. The concepts of the providers show differences. Hence, not every service matches the ones of the other competitors 1:1. However, at the end they pursue similar purposes, namely providing you a seamless package to grab your workload, move it into the cloud, scale it up and down as you need and then grow further.

The short essays do not go for a detailed and exhaustive analysis of the estimated more than 500 services – still increasing at the times of writing. But anyway, the author will walk you through category for category. You will notice that there are areas where you find only minor differences between the providers. In other areas, the “specific beauty” or you might say the DNA shines through. Whatever your priority is, the one or the other provider might match your needs better. It is once more important that the author holds a neutral position before now diving into the details.

1.1????????Hybrid connectivity

No alt text provided for this image

Figure 1: Hybrid connectivity – basic services overview

Even today, most migrations into the Public Cloud start with a setup of a hybrid connection from an on-premises datacenter to a provider and vice versa. To support this, all of them offer typical (HA-) VPN to start with. Non-HA connection-types are disappearing right now, as these contradict the principle of ubiquitous serving. A “single point of failure” is simply not state-of-the-art. All providers hence will propose to establish minimum two, but even better four connections for stable redundancy.

Most customers already set up the connection with broad bandwidths right from the beginning. These are reaching in the meantime 200 GBps in the case of Google Dedicated Interconnect. As not every customer can reach the edge-sites of the providers, all of them offer connections via partner. So, you would meet them on a colocation site and then link further to the cloud provider. The 3rd party in between have fixed lines to the cloud providers. They offer you bandwidths from 50 MBps to usually around 10 GBps.

Moreover, all types of active-passive, active-active setups are supported. However, active-active configuration come with the risk that in a case of failover to only one line, the capacity is at half. With that, cascading errors might happen where services and applications in the back rely on the broad bandwidth and would now start staggering. Hence, for highly fault tolerant configurations the active-passive connection is the most popular.

The providers also offer a layer 2 connectivity in the flavors of direct or partner peering. With these connections you reach the “public services” like Google Docs, YouTube, Office 365 (Microsoft) etc. As written in part 1 of the essay series, AWS has the most granular offerings in this area. An example for this is AWS PrivateLink, with which you can reach the public APIs for Storage (S3) and other resources avoiding a route over the public internet. One more very convincing service is the AWS Transit Gateway. It enables smart configurations bundling all types of VPN, Dedicated Connect in a “spoke” with big scale (Amazon 2021 [I]).

1.2????????Identity- and Access-Management (IAM)

No alt text provided for this image

Figure 2: IAM and Identity federation – basic services overview

Identity and Access Management (IAM) is the logical next service customers adopt when landing in the cloud. The tools provide functionality to administer who can access which resource under which circumstances. With any provider you find a detailed roles, users, and groups management to organize your access boundaries. Of course, you do not want to start over and manage user your company administers anyway already once more. Hence, all providers bring a synchronization tool which takes over your identities from on premises LDAP, Active Directory, or other identity tools. Single-Sign-On is given with all of them.

Managing your on-premises identities is the one thing. Managing thousands or even millions of users for applications you expose to the public internet is another thing. To simplify the management of those identities the cloud providers offer OpenID/OAuth based access. With that users take advantage of their Facebook, Google, LinkedIn, Amazon etc. accounts to gain trusted access to the services. The typical way is to check against these providers during the login into a cloud. The cloud providers handle access tokens which then help to assume the right role to use the required service.

Additionally, the providers leverage their own broad identity base. Google takes advantage of the user base established on Google Mail, Google Docs, sometimes enterprises organizing their domain via Google. Microsoft leverages the Active Directory tenants for companies using Office 365.

Google offers with Internet-Aware-Proxy (IAP) a way to securely access resources via http. User do not have to log in via VPN to the respective resources, but can authorize using cloud identities. Examples are Http load balancers, Cloud Run, and Google Kubernetes Services.

AWS has again advanced tools like Cognito. User pools nested there support mobile applications. You can generate a user profile for each identity. With Identity-Pools however, you can also enable anonymous users to receive temporary credentials to get access to services. As a summary you see, that for any use case you find the right setup for IAM with all the providers.

1.3????????Virtual Networking

No alt text provided for this image

Figure 3: Virtual networking & virtual private cloud – basic services overview

When we compare the number of Regions and Availability Zones, Google and AWS are similar. Microsoft has more Regions whilst they obviously offer less Availability Zones per Region (compare Amazon, Microsoft and Google 2021 [II,III, IV]).

The fact that AWS was the first cloud provider resonates also in the Virtual Private Cloud (VPC). You will find the most granular building blocks with AWS. Both, AWS, and Azure run similar concepts. VPCs can span a single region. Subnets are dedicated to availability zones.

At this point, Google excels with its ability that VPCs can span the globe. Furthermore, subnets are regional. Google uses its software-based technologies MAGLEV and AMDROMEDA to form the virtual network resources sitting on the probably biggest network infrastructures worldwide. Since the rise of Google Search and YouTube, the company has relentlessly cabled the world with high performance fiber. Obviously, they are at the top spending for sea cables connecting the continents (Hamilton 2021 [V]). Other sources say, 25-40 % of worldwide internet traffic is passing Google infrastructure (compare Stapp 2019 [VI]).

The three providers use different concepts to manage very fast connections across the globe. Google uses its outstanding global fiber network for the so-called Premium tier. AWS offers the concept of Global Accelerator to link users as closely as possible to endpoints distributed worldwide. Microsoft offers traffic manager which is DNS-based to route and distribute load optimal across the globe.

One major concept for serving users with a worldwide spread is the Content Delivery Network (CDN). All three offer this “caching” of content all over the world in edge locations close to users. This is today one of the most important cloud solutions to let users have a speedy experience. The service is adopted by many global companies.

1.4????????Load Balancing

No alt text provided for this image

Figure 4: Load balancing options – basic services overview

We want to consider load balancing options of the three cloud providers in this separate section. At this point we find a design element which vastly outperforms classical on premises datacenter capabilities. It is a connection from more “elderly” architecture, i.e., scale via lift and shift by sheer infinite infrastructure capacity towards truly “cloud native”. Modern architecture is driven by microservice like Docker and Kubernetes. This enables granular design patterns from big to small, organized in clusters, nodes, pods, containers. Modern architecture scales on each of those layers.

It is not surprising that Google brings with six the most elaborated options as they are the pacemaker in next generation application design (well, they invented Kubernetes and gave it to Open-Source-Community, they started cloud coming from App Engine, see also part 1). Their load balancers integrate very well with the different implementations of container architectures, including types like Deployment Sets and Ingress Service, supporting private as well as public postures of your applications.

All three providers supply load balancer types for global vs regional, TCP (layer 4) vs Http(s) (layer 7), proxy-based vs passthrough (Network LB), public vs internal workloads. The security principle of “reduce your surface of attack” by hiding your applications and systems from the internet using internal IP addresses comes with a significant speed reward. The internal load balancers of the providers do not need to resolve IP addresses via public domain name servers. This makes network traffic around 5-10 times faster. You can reach up to 25 GBps when you use big machines and accelerated networking for AWS ([VI]) or 20 GBps for GcP per VM ([VII]). The network load balancer types also support well internal workloads as those do not use proxies. Instead, those pass your traffic quickly through to backend groups based on algorithms like 3-tuple or 5-tuple hash.

The Application load balancer types support path-based routing with which you might want to separate static content (Web sites hosted on blob storage) from application traffic. You can also use several SSL certificates on these load balancers to improve security postures fitting your needs.

AWS offers a Gateway load balancer which enable deployment and scale of 3rd party virtual appliances (Layer 3). This is used for firewalls, intrusion detection and prevention systems, deep packet inspections. Also, this building block is a possibility to add an extra layer of security into your designs.

Well, again you really will find anything you need with each of the three cloud providers. Clear advantage for Google in the space of “cloud native” postures, advantage for AWS on classical hybrid setups.

1.5????????Computing Options

No alt text provided for this image

Figure 5: Computing options – basic services overview

Companies who search for an extension of their compute capabilities will find the most scale with AWS which is the current market leader. Microsoft will offer you also huge space to expand your compute power from on premises datacenters into the cloud. Google is catching up with more and more space for lift and shift customers. They become very strong when it comes to application hosting and microservices computing environments.

Launching any type of virtual machine whenever you want is the most wooing moment when getting hands first time on the cloud. Within minutes users can spin up single VMs or whole instance groups (Google, AWS) or scale sets (Microsoft) and spread those over the whole world. Configuration options comprise memory optimized, storage optimized, high performance computing using GPUs (Graphical Processing Units) or simply standard machines from very small (“micro”) to extensively large. Furthermore, administrators can create virtual disks of different kinds on the fly.

All providers give you an easy entry into container deployments with offerings like Azure Compute Instance, Cloud Run, or Elastic Container Service (EKS). Those platforms are made to quickly upload code, containerize it, and provide an easy-to-use runtime environment. You do not need to be a highly skilled cloud developer to use those services. The beforementioned find with Kubernetes environments on each of the three platforms an area to build sophisticated state-of-the-art cloud architectures. The author perceives Google to be the most open, i.e., “Open Source Minded” company. In the previous essay, the author elaborated on multi-cluster, multi-cloud-provider architectures you might build up using the Google-tools and products in conjunction with Istio and Anthos container meshes.

Classical Developers find with the Azure App Service, AWS Beanstalk or Google App Engine Standard (easier to use) or Flex (more sophisticated) environments to upload code and get things quickly running. All the services support a “Code first attitude” where developers concentrate on coding. Managing infrastructure, setting up load balancers, scaling, security settings etc. is all managed by those services.

So, in a nutshell, in this area no on premises data center does come close to the depth and breadth of services and infrastructure given by the big three cloud providers. You hardly will find a use case where the providers cannot support you on “state-of-the-art” level.

1.6????????Storage Options

No alt text provided for this image

Figure 6: Storage options – basic services overview

Not surprisingly you find the most differentiated portfolio for managed services in the storage area with AWS. They started their cloud journey with services for compute and storage extensions already in 2006. One example for this is the Caching Solutions around Memcached. Firstly, Redis Cache which can be set up in HA architecture with replication over availability zones with up to five read replica besides the read & write instance. This architecture is often used in gaming where you need more complex data structures to be shared over various instances. You can configure this cache for a fast warm up as most recent database entries are written to disk (AOFs, Append only Files). Hence, in a recovery after failure, you can quickly load the most recent content back into memory. Secondly, AWS offers Memcached for more simple data structures. You even can use up to 20 nodes and apply sharding to distribute the caching content. During the times of writing these essays, Google is also about to start a Memcached managed service besides the Memorystore which is based on Redis. However, Google and Microsoft still a way to go to catch up with AWS.

Google again is very strong when it comes to modern application architectures which need storage backing on global scale. You find this in use cases for gaming where users are playing worldwide in a joint arena. One example is Pokémon Go, developed by Niantic Labs. The hunt of their global player base, which can be several million at one moment, is backed by up to 5.000 Spanner nodes. The App itself runs on thousands of Kubernetes nodes. Please watch the interview of Priyanka Vergadia and James Prompanya to get deeper insight of this “cloud native” reference architecture ([VIII]). The author considers Spanner to be the leading product for SQL database with global horizontal scaling.

Apart from this you will find persistent disk services which let you scale tremendously; you can attach several disks of nearly any size to your VMs, dependent on VM types used. There are services for “regional disks” which give you redundancy beyond the barriers of an availability zone (well, you need to compromise on speed and throughput). With that you can “force attach” a disk in another availability zone within a region when you face a zonal outage. There is a lot of more fancy solutions which go far beyond to what you know from working with traditional, on premises datacenters. Flavors like classic HDD, SSD, ultra-fast SSDs come with different prices and some configuration options which need to be considered.

SQL databases for most typical products like Postgre or MySQL are offered by any cloud as managed service. The most variants are supported by AWS who also offer a very fast homemade SQL database called Aurora. This relational database scales up to 64 TB size which is far more than with other typical SQL databases.

Non-SQL databases with tremendous horizontal scale are the following: CosmosDB (Azure), Bigtable (Google), and DynamoDB (AWS). The last of which has the most impressive use cases in executing the yearly shopping events like Prime Day, compare part 1 of this article series.

As a summary we can conclude that storage options are vastly available with all providers. There is a clear lead of AWS concerning the most differentiated services and proven tremendous scale for its NoSQL database. The modern app backing solution space is probably best with Google who has a SQL solution which can scale horizontally on global base integrating with microservices architectures. There you find proven use cases in the Gaming industry.

1.7????????Compute and Data Migration Services


No alt text provided for this image

Figure 7: Storage options – basic services overview

The migration services of the providers are important corner stones to get as quickly as possible up and running in the cloud. The tools support assessments of on premises infrastructure. For a “lift and shift scenario” the tools will propose optimal machine configurations in the target zone. After a successful test migration, the workloads will be taken over automatically. Even the decommissioning of the old systems is supported.

For database migrations you also find the right tools with every provider. The typical migration goes via a homogenous transfer. That means you move from products like MySQL to the same or “similar” product family like PostgreSQL. More sophisticated tools like Amazon Schema Conversion Tool help with heterogeneous conversions for customers who like to shift from Oracle-databases to Aurora or Spanner for example.

Even very broad banded hybrid connection topologies cannot cope with big data volumes. As a rule of thumb, devices like Snowball (AWS), Data Box (Azure) or Transfer Appliance (Google) come to play when transferring data volumes larger than 10-30 TB. AWS even offers truck mounted transfers for data up to 100 PB.

The strength of Googles in “cloud native” or microservice-oriented architecture is supported by a specific transfer service called Anthos. That tool can assess applications and rank the readiness on a scale from 1 (poor) to 10 (well prepared). Starting from a score of 8-9, the tool will automatically generate container artefacts out of your application and generate a cloud native application out of your legacy ([]). Azure also offers assistants to take over applications from legacy to cloud.

2????????Summary

In this essay, the author summarizes and compares the basic cloud services of Google, Azure, and AWS. This part focused mostly on the typical scale game like computing options, network services, storage services. Those elements will mostly support customers who want to burst into the cloud. With the described services there are a plenty of options for a “lift-and-shift” approach.

A conclusion on the question: “now, which provider is the best?” still cannot be taken. It was clear that any provider will satisfy the typical needs of a customer. However, we saw that AWS in the described “lift and shift area” has surely the most elaborated services and probably also the biggest scale. None of the providers can claim to be the “dominant” one in all areas. Each one has its specific strength. So, there is not “the best cloud”. Customers need to investigate based on their specific requirements. This essay shall help to give some orientation in doing so.

In part 3 of? article series the focus will shift to the “cloud native” services like data processing, Artificial Intelligence etc. That is where the requirements of tomorrow will be fulfilled.

About the author:

Dr. Marc Braun works as Vice President Service Delivery Management at T-Systems since 2009. He helps customers to migrate and run their SAP workloads on “their” right cloud. Most recently, combining some of the moves with the customers’ S/4 transformation. Variants of SAP-Workloads on Azure, AWS, HEC and more and more also Google combined with private hybrids are building a really multi cloud scenario. Marc achieved Professional Architect certifications of AWS, Google, and Azure as well as SAP certifications.

No alt text provided for this image


Marc earned his PhD in 1999 with a research on Component Business Architectures based on Microsoft versus SAP for small to medium sized enterprises (SME). In his thesis he elaborated rule-based structures (algorithms) to match the disperse requirements of SMEs with adequate software functions.

3????????Annotations

I.????????Amazon 2021/1, Building a Scalable and Secure Multi-VPC AWS Network Infrastructure, https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html [2021.12.30]

II.??????Amazon 2021/2, Overview of Amazon Web Services https://docs.aws.amazon.com/whitepapers/latest/aws-overview/global-infrastructure.html [2021.12.30]

III.?????Google 2021/1, Cloud locations, https://cloud.google.com/about/locations [2021.12.30]

IV.?????Microsoft 2021/1, Azure geographies https://azure.microsoft.com/en-au/global-infrastructure/geographies/#overview [2021.12.30]

V.??????Isobel Asher Hamilton 2021, Photos: How Facebook and Google use sonar ships, gigantic underwater plows, and divers to lay thousands of miles of undersea internet cables around the globe, https://www.businessinsider.com/google-facebook-giant-undersea-cables-internet-tech-2021-9 [2021.12.30]

VI.?????Alex Stapp 2019, https://truthonthemarket.com/2019/09/27/debunking-elizabeth-warrens-claim-that-more-than-70-of-all-internet-traffic-goes-through-google-or-facebook/ [2021.12.30]

VII.???Amazon 2017, Announcing improved networking performance for Amazon https://aws.amazon.com/de/about-aws/whats-new/2017/09/announcing-improved-networking-performance-for-amazon-ec2-instances/ [2021.12.30]

VIII.??Google 2021/2, network bandwidth https://cloud.google.com/compute/docs/network-bandwidth [2021.12.30]

IX.?????Priyanka Vergadia and James Prompanya 2021, How Pokémon GO scales to millions of requests? https://cloud.google.com/blog/topics/developers-practitioners/how-pok%C3%A9mon-go-scales-millions-requests [2021.12.30]

X.??????Google 2021, Migrate for Anthos and GKE, https://cloud.google.com/migrate/anthos [2021.12.30]

Martin Wanka

OCS - Let′s talk about it and find a solution!

3 年

Sehr interessante Zusammenstellung und übersicht. Super gemacht Marc. Vielen Dank für die Beitragsserie.

Very well written, condense and clear. Highly recommended reading!

要查看或添加评论,请登录

Dr. Marc Braun的更多文章

社区洞察

其他会员也浏览了