Vendor Microsoft Azure AWS Google
Strengths •Second largest provider
• Integration with Microsoft tools and software
• Broad feature set
• Hybrid cloud
• Support for open source
• Dominant market position
• Extensive, mature offerings
• Support for large organizations
• Extensive training
• Global reach
• Designed for cloud-native businesses
• Commitment to open source and portability
• Deep discounts and flexible contracts
• DevOps expertise
Weaknesses •Issues with documentation
• Incomplete management tooling
• Difficult to use
• Cost management
• Overwhelming options
• Late entrant to IaaS market
• Fewer features and services
• Historically not as enterprise focused
Compute Services • Virtual Machines
• Virtual Machine Scale Sets
• Azure Container Service (AKS)
• Container Instances
• Batch
• Service Fabric
• Cloud Services
• EC2
• Elastic Container Service
• Elastic Container Service for Kubernetes
• Elastic Container Registry
• Lightsail
• Batch
• Elastic Beanstalk
• Fargate
• Auto Scaling
• Elastic Load Balancing
• VMware Cloud on AWS
• Compute Engine
• Kubernetes
• Functions
• Container Security
• Graphics Processing Unit (GPU)
• App Engine
• Knative
Storage Services • Blob Storage
• Queue Storage
• File Storage
• Disk Storage
• Data Lake Store
• Simple Storage Service (S3)
• Elastic Block Storage (EBS)
• Elastic File System (EFS)
• Storage Gateway
• Snowball
• Snowball Edge
• Snowmobile
•Cloud Storage
• Persistent Disk
• Transfer Appliance
• Transfer Service
Database Services •SQL Database
• Database for MySQL
• Database for PostgreSQL
• Data Warehouse
• Server Stretch Database
• Cosmos DB
• Table Storage
• Redis Cache
• Data Factory
• Aurora
• RDS
• DynamoDB
• ElastiCache
• Redshift
• Neptune
• Database migration service
•Cloud SQL
• Cloud Bigtable
• Cloud Spanner
• Cloud Datastore
Backup Services • Archive Storage
• Backup
• Site Recovery
Glacier None
AI/Machine Learning • Machine Learning
• Azure Bot Service
• Cognitive Services
•SageMaker
•Comprehend
• Lex
• Polly
•Rekognition
•Machine Learning
• Translate
•Transcribe
•DeepLens
• Deep Learning AMIs
• Apache MXNet on AWS
• TensorFlow on AWS
•Cloud Machine Learning Engine
• Dialogflow Enterprise Edition
• Cloud Natural Language
• Cloud Speech API
• Cloud Translation API
• Cloud Video Intelligence
• Cloud Job Discovery (Private Beta)
IoT • IoT Hub
• IoT Edge
• Stream Analytics
• Time Series Insights
• oT Core
•FreeRTOS
•Greengrass
• IoT 1-Click
• IoT Analytics
• IoT Button
• IoT Device Defender
• IoT Device Management
·   Cloud IoT Core (Beta)
Serverless Functions • Lambda
• Serverless Application Repository
Cloud Functions (Beta)

Azure vs. AWS vs. Google: Compute

Azure Compute:

  • Virtual Machines: Microsoft’s primary compute service is known simply as Virtual Machines. It boasts support for Linux, Windows Server, SQL Server, Oracle, IBM, and SAP, as well as enhanced security, hybrid cloud capabilities and integrated support for Microsoft software. Like AWS, it has an extremely large catalog of available instances, including GPU and high-performance computing options, as well as instances optimized for artificial intelligence and machine learning. It also has a free tier with 750 hours per month of Windows or Linux B1S virtual machines for a year.
  • Additional Services: Azure’s version of Auto Scaling is known as Virtual Machine Scale Sets. And it has two container services: Azure Container Service is based on Kubernetes, and Container Services uses Docker Hub and Azure Container Registry for management. It has a Batch service, and Cloud Services for scalable Web applications is similar to AWS Elastic Beanstalk. It also has a unique offering called Service Fabric that is specifically designed for applications with microservices architecture.

AWS Compute:

  • Elastic Compute Cloud: Amazon’s flagship compute service is Elastic Compute Cloud, or EC2. Amazon describes EC2 as “a web service that provides secure, resizable compute capacity in the cloud.” EC2 offers a wide variety of options, including a huge assortment of instances, support for both Windows and Linux, bare metal instances, GPU instances, high-performance computing, auto scaling and more. AWS also offers a free tier for EC2 that includes 750 hours per month for up to twelve months.
  • Container services: Within the compute category, Amazon’s various container services are increasing in popularity, and it has options that support Docker, Kubernetes, and its own Fargate service that automates server and cluster management when using containers. It also offers a virtual private cloud option known as Lightsail, Batch for batch computing jobs, Elastic Beanstalk for running and scaling Web applications, as well as a few other services.

Google Compute:

  • Compute Engine: By comparison, Google’s catalog of compute services is somewhat shorter than its competitors’. Its primary service is called Compute Engine, which boasts both custom and predefined machine types, per-second billing, Linux and Windows support, automatic discounts and carbon-neutral infrastructure that uses half the energy of typical data centers. It offers a free tier that includes one f1-micro instance per month for up to 12 months.
  • Focus on Kubernetes: Google also offers a Kubernetes Engine for organizations interested in deploying containers. Like all of the leading cloud vendors, it’s set up to offer containers and microservices. And it’s worth noting that Google has been heavily involved in the Kubernetes project, giving it extra expertise in this area.

In Visual Studio, there are at least 3 different types of class library you can create:

  • Class Library (.NET Framework)
  • Class Library (.NET Standard)
  • Class Library (.NET Core)

* Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

* Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.

Difference:

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

As a quick resume, we can say that:

.Net Framework and .Net Core are two different implementations of the .Net runtime. Both Core and Framework (but especially Framework) have different profiles that include larger or smaller (or just plain different) selections of the many APIs and assemblies Microsoft has created for .Net, depending on where they are installed and in what profile. For example, there are some different APIs available in Universal Windows apps than in the “normal” Windows profile. Even on Windows, you might have the “Client” profile vs the “Full” profile. Additionally, there are other implementations (like Mono) that have their own sets of libraries.

.Net Standard is a specification for which sets of API libraries and assemblies must be available. An app written for .Net Standard 1.0 should be able to compile and run with any version of Framework, Core, Mono, etc, that advertises support for the .Net Standard 1.0 collection of libraries. Similar is true for .Net Standard 1.1, 1.5, 1.6, 2.0, etc. As long as the runtime provides support for the version of Standard targeted by your program, your program should run there.

A project targeted at a version of Standard will not be able to make use of features that are not included in that revision of the standard. This doesn’t mean you can’t take dependencies on other assemblies, or APIs published by other vendors (ie: items on NuGet). But it does mean that any dependencies you take must also include support for your version of .Net Standard. .Net Standard is evolving quickly, but it’s still new enough, and cares enough about some of the smaller runtime profiles, that this limitation can feel stifling. (Note a year and a half later: this is starting to change, and recent .Net Standard versions are much nicer and more full-featured).

On the other hand, an app targeted at Standard should be able to be used in more deployment situations, since in theory it can run with Core, Framework, Mono, etc. For a class library project looking for wide distribution, that’s an attractive promise. For a class library project used mainly for internal purposes, it may not be as much of a concern.

.Net Standard can also be useful in situations where the SysAdmin team is wanting to move from ASP.Net on Windows to ASP.Net for .Net Core on Linux for philosophical or cost reasons, but the Development team wants to continue working against .Net Framework in Visual Studio on Windows.

This is how Microsoft explains it:

.NET Framework is the “full” or “traditional” flavor of .NET that’s distributed with Windows. Use this when you are building a desktop Windows or UWP app, or working with older ASP.NET 4.6+.

.NET Core is cross-platform .NET that runs on Windows, Mac, and Linux. Use this when you want to build console or web apps that can run on any platform, including inside Docker containers. This does not include UWP/desktop apps currently.

Xamarin is used for building mobile apps that can run on iOS, Android, or Windows Phone devices, usually runs on top of Mono, which is a version of .NET that was built for cross-platform support before Microsoft decided to officially go cross-platform with .NET Core. Like Xamarin, the Unity platform also runs on top of Mono.

NameMicrosoft Azure Cosmos DB  Microsoft Azure SQL Database  
DescriptionGlobally distributed, horizontally scalable, multi-model database serviceDatabase as a Service offering with high compatibility to Microsoft SQL Server
Primary database modelDocument store
Graph DBMS
Key-value store
Wide column store
Relational DBMS
Secondary database modelsDocument store
Graph DBMS
Websiteazure.microsoft.com/­services/­cosmos-dbazure.microsoft.com/­en-us/­services/­sql-database
Technical documentationdocs.microsoft.com/­en-us/­azure/­cosmos-dbdocs.microsoft.com/­en-us/­azure/­sql-database
DeveloperMicrosoftMicrosoft
Initial release20142010
Current releaseV12
License commercialcommercial
Cloud-based only yesyes
DBaaS offerings (sponsored links) 
Server operating systemshostedhosted
Data schemeschema-freeyes
Typing yes yes
XML support yes
Secondary indexesyes yes
SQL SQL-like query languageyes
APIs and other access methodsDocumentDB API
Graph API (Gremlin)
MongoDB API
RESTful HTTP API
Table API
JDBC
ODBC
ADO.NET
Server-side scripts JavaScriptTransact SQL
TriggersJavaScriptyes
Partitioning methods Sharding 
Replication methods yes yes, with always 3 replicas available
MapReduce with Hadoop integration no
Consistency concepts Bounded Staleness
Consistent Prefix
Session Consistency
Eventual Consistency
Immediate Consistency 
Immediate Consistency
Foreign keys noyes
Transaction concepts Multi-item ACID transactions with snapshot isolation within a partitionACID
Concurrency yesyes
Durability yesyes
User concepts Access rights can be defined down to the item levelfine grained access rights according to SQL-standard

Cosmos DB is a globally distributed, multi-model database solution with high SLAs around distribution. It’s designed for your applications and supports document and graph databases. Azure SQL DB has the concept of consistent reads and the ability to store your data. But my goal here is to talk about their differences with global replication and global distribution of your data.

Cosmos DB

  • When it comes to distributing, with Cosmos DB you get a primary instance to write against and it gets distributed to all your read-only replicas that you choose around the world.
  • You can simply push a button, activate new scenarios and you can run manual failover transactions.
  • The big key with Cosmos is that is was built for global distribution. It was designed with the controls that allow it to be globally distributed with SLAs associated with that global distribution.
  • Another key thing is that you get one URL and that URL knows where to go and does all the work.

Azure SQL Database

  • Makes it possible to globally distribute your Azure SQL Databases.
  • You can have a primary replica that stands in the US and add secondary read-only replicas in Europe and Asia for instance. You can have the read closer to the people who are using your global applications.

A couple things to be aware of, with Azure SQL DB you only have 4 read-only secondaries off an individual or SQL DB. In contrast, Cosmos DB can replicate wherever Cosmos DB is in the data center; you just go in and click a button. Also, in Cosmos you can do manual failover operations, or you can code them out, so it can be written to wherever it is in the world, closer to the active people using your application.

Do you need the ability of global distribution of your data and wonder which database is the best for this? Today, I’d like to give you a comparison between Azure SQL Database and Cosmos Database for global distribution.

Cosmos DB is a globally distributed, multi-model database solution with high SLAs around distribution. It’s designed for your applications and supports document and graph databases. Azure SQL DB has the concept of consistent reads and the ability to store your data. But my goal here is to talk about their differences with global replication and global distribution of your data.

Cosmos DB

  • When it comes to distributing, with Cosmos DB you get a primary instance to write against and it gets distributed to all your read-only replicas that you choose around the world.
  • You can simply push a button, activate new scenarios and you can run manual failover transactions.
  • The big key with Cosmos is that is was built for global distribution. It was designed with the controls that allow it to be globally distributed with SLAs associated with that global distribution.
  • Another key thing is that you get one URL and that URL knows where to go and does all the work.

Azure SQL Database

  • Makes it possible to globally distribute your Azure SQL Databases.
  • You can have a primary replica that stands in the US and add secondary read-only replicas in Europe and Asia for instance. You can have the read closer to the people who are using your global applications.

A couple things to be aware of, with Azure SQL DB you only have 4 read-only secondaries off an individual or SQL DB. In contrast, Cosmos DB can replicate wherever Cosmos DB is in the data center; you just go in and click a button. Also, in Cosmos you can do manual failover operations, or you can code them out, so it can be written to wherever it is in the world, closer to the active people using your application.

Manual failover is not something you would do with Azure SQL DB. All those writes must come to a primary replica and we’d have to feed out the replicas through read. The biggest pain point you may notice is managing the connectivity to your Azure SQL database in a globally replicated scenario.

There are some techniques, as well as tools within Azure to make it easier to use, such as Traffic Manager. You have the option to use an IP address in Traffic Manager and route things through there, but you must set all that up.

With Cosmos DB, that work is done for you because it’s designed from the ground up to be globally replicated. This does not mean you shouldn’t use active global replication with Azure SQL DB. You just need to understand the differences and use cases to make sure you use the database that best fits your needs to distribute your data globally.

Compare the most common: Amazon DynamoDB, Azure Cosmos DB and Mongo DB

NameAmazon DynamoDBMicrosoft Azure Cosmos DB MongoDB 
DescriptionHosted, scalable database service by Amazon with the data stored in Amazons cloudGlobally distributed, horizontally scalable, multi-model database serviceOne of the most popular document stores
Primary database modelDocument store
Key-value store
Document store
Graph DBMS
Key-value store
Wide column store
Document store
Websiteaws.amazon.com/­dynamodbazure.microsoft.com/­services/­cosmos-dbwww.mongodb.com
Technical documentationdocs.aws.amazon.com/­dynamodbdocs.microsoft.com/­en-us/­azure/­cosmos-dbdocs.mongodb.com/­manual
DeveloperAmazonMicrosoftMongoDB, Inc
Initial release201220142009
License commercial commercialOpen Source 
Cloud-based only yesyesno 
Server operating systemshostedhostedLinux
OS X
Solaris
Windows
Data schemeschema-freeschema-freeschema-free 
Typing yesyes yes 
Secondary indexesyesyes yes
SQL noSQL-like query languageRead-only SQL queries via the MongoDB Connector for BI
APIs and other access methodsRESTful HTTP APIDocumentDB API
Graph API (Gremlin)
MongoDB API
RESTful HTTP API
Table API
proprietary protocol using JSON
Server-side scripts noJavaScriptJavaScript
Triggersyes JavaScriptno
Partitioning methods ShardingSharding Sharding
Replication methods yesyes Master-slave replication
MapReduce no with Hadoop integration yes
Consistency concepts Eventual Consistency
Immediate Consistency 
Bounded Staleness
Consistent Prefix
Session Consistency
Eventual Consistency
Immediate Consistency 
Eventual Consistency
Immediate Consistency 
Foreign keys nonono 
Transaction concepts ACID Multi-item ACID transactions with snapshot isolation within a partitionMulti-document ACID Transactions with snapshot isolation
Concurrency yesyesyes
Durability yesyesyes 
In-memory capabilities yes 
User concepts Access rights for users and roles can be defined via the AWS Identity and Access Management (IAM)Access rights can be defined down to the item levelAccess rights for users and roles