The second part of comparison of the cloud providers to help you understand all you need to know about the differences between the cloud providers and make the best decision for your business.
Kubernetes is a nice tool for running your Game Servers and other demanding services like Matchmaking or Leaderboards. But in some cases it can be an overkill (such is the case if you haven't got much experience with it, or no time to play with adjusting the settings of scaling the resources). In this case, it is better, and safer, to use fully serverless solutions from any of the three major providers.
All providers implement their own SDK upon which you will develop your service, deploy it on the serverless engine and that is all you have to care about.
There are different advantages to this approach such as
This helps to deliver services and applications with high quality/availability even in a small team and in a short period of time.
AWS Elastic BeanStalk offers the biggest variety of supported programming languages for development. MS Azure comes up with App Service which provides managed servers for different programming languages but mainly Windows servers for .NET and .NET Core.
I'd like to highlight here the integration of Visual Studio with tools and GitOps that comes with this service. I think Microsoft did a great job helping developers to automate the deployment process as much as possible.
And finally GCP comes with AppEngine which is the oldest of the three products, but with great SDK integration not only with the serverless functionality, but also with other managed services like Memcache (Managed Redis) and DataStore (Managed NoSQL database).
If you are afraid of vendor lock-in or you are trying to do something that is out of scope of the SDK provided, you can opt for Google AppEngine Flex or Cloud Run. There is also a similar product in AWS -> Docker with Elastic BeanStalk and AWS Fargate, with Azure Serverless Container Instances. It might seem as the easiest way to run Containers on your cloud but you have to implement your own way of logging, monitoring or calls to other cloud services.
All three services/products belong to the range of K-Native engine services. So if you want to avoid vendor lock-in completely you can run your own configuration of K-Native platform on any of these Cloud providers. But again - do not underestimate the time and expertise needed to manage it for yourself.
And last but not least, Cloud Functions - the serverless tool that you can use on the cloud
Compared to the previous two engines that are here for running the whole application on serverless platforms functions are just simple pieces of code intended to do one task.
They are intended as actions or tasks that are triggered by specific events (HTTP request, DB change, Repository commit, Queue message arrival and so on).
Compared to Serverles engines (AppEngine, Cloud Run) that are usually HTTP request based and as an application it handles several types of request (related to one type of domain), Cloud Functions are focused on handling one action in a specific time-frame (time execution is restricted to max 5 minutes, usually 60 seconds). This is great for connecting different systems/services/parts of your applications without the need to connect to specific API. Events in one application can trigger the function to process data from it and send it to another application/system.
Of course, you can build your whole backend with Cloud Functions (and some developers already did that) but I do not recommend to use this concept for such things. You can fall into the maintenance hell when the number of functions rises to bigger values. There also will be a need for another tool (or hierarchy system) to have an overview of which functions belong to which part of the application. Some PL/SQL developers know what I'm talking about so learn from their mistakes.
Azure comes with its own similar tool/ solution in Azure Functions, AWS offers a service with fancier name AWS Lambda and GCP provides Cloud Functions
If you are a developer like me and you're allergic to words like “orchestration”, “scaling”, “yaml”, “Terraform” etc., or if your last load balancing happened on a fishing boat on the last vacation and DevOps, CI/CD and Infrastructure as a Code are foreign words to you, you might have just found a magic garden where the backend of your game will flourish without watering. :-)
Ok, but jokes aside.
The main advantage of serverless is that even with the small team you are able to create the whole backend for a game in a feasible time span. You can create some services even in a matter of days or hours. You can make canary deployments or A-B testing without knowing almost anything about load balancing. You can also write additional functionality or integrate different systems together with Cloud Functions.
This will give you the advantage of bringing new functionality faster (with less problematic updates) protect you in case of unexpected errors on client's side or in case the new version of the API from a third party vendor arrives without your knowledge.
On the other hand, serverless won’t tolerate programmers who make errors easily (you pay more for resources if you do not use them wisely). You have to know what you are doing (especially with managed resources like database read/write, storage and memory).
But once you learn how to use it to your advantage, it will help you develop faster and soon (once your game gets promoted) you'll just watch millions and millions of requests being served without you moving a finger.
Once you have decided which compute system you are going to use, it is time to think about getting data from users, storing them and delivering data to other users.
It will be hard to build Game Backend applications without persistent storage. It's almost impossible to make it respond in real time without cache and you would drown in the pool of asynchronous requests by trying to make all services communicate without proper queues.
Again, I would like to concentrate more on managed services, because I think, here lies the power of the cloud that brings the biggest value to the game developers.
Let's start with the most commonly used service - Storage Service.
It could be used as media content storage and delivery; integrated repository for big data for ML and analytics; or in special cases as a backup and archiving service. And of course, there's way more you can do with it.
It is hard to compare real prices as AWS and Azure provide some services for free or don't count the usage of the Cloud Storage in some services but instead you pay for inbound and outbound traffic. That's why you have to know how to set up CNDs or Cache to use it to its full potential at a minimum cost.
GCP has its own Google Cloud Storage where you can optimize the price by applying specific rules (date, size, amount, accessibility...) for the best performance to price ratio, based on your BackEnd needs.
AWS has a bit of a different approach, where it offers every type of storage (Object, File, Block Storage, Elastic Backup….) as a standalone service. See the overview here. And again based on the service you use you can get 12 month for free, or totally qualify for a free tier (with limits to the amount of data you can store)
MS Azure has a similar approach to AWS with many of their different services. All storage services are listed here.
More or less all providers offer the same services but it is important to know how to use them efficiently.
SQL DBs
Here, we see yet another clash of Titans!
There are at least 20 managed services supporting databases amongst all three major cloud providers.
I will start with SQL managed services, because SQL DBs are still most widely used. Even in the gaming industry where some SQL solutions aren't ready for the cloud just yet.
Google offers Cloud SQL service which is a relational DB engine based on either MySQL, PostgreSQL or MS SQL Server DB. It's fully managed, scalable and provides high availability.
AWS offers not only managed MySQL or PostgreSQL (AWS Aurora) but in case you have a different DB engine you want to run as Managed DB service you can use Amazon Relational Database Service where you can add more DB engines like MS SQL Server, Oracle DB or MariaDB.
What is different from other providers is that AWS Aurora is able to get 5x the throughput of standard MySQL and 3x the throughput of standard PostgreSQL. This performance is on par with commercial databases, at 1/10th the cost. Which is definitely a benefit for the gaming industry.
MS Azure is definitely the king of managed services for MS SQL Databases with their Azure SQL Database which is the DB flagship of managed relational databases on Azure. It also supports managed MySQL and PostgreSQL but without high-end features like in SQL Database.
Actually, it contains services and features that are related more to the new family of relational DBs, Hybrid Relational Databases where you will get not only vertical but also horizontal scaling (more in the direction of NoSQL world).
AWS does not have an exact competitor for this but we can consider AWS Aurora at least from some features as a similar service. Google offers Cloud Spanner which is relational DB service with transaction and ACID functionality of Relational DBs. It also provides the benefits of global scaling just like on NoSQL databases which can bring some significant cost reduction as well.
I'm not a big fan of SQL databases for Gaming but I'm a real enthusiast of managed services. The package you get allows you to forget about worrying about how the DB runs. You get automated backup and restore functionality and potential performance benefits. Once you have a solution that already uses SQL database you can easily move it to the managed services of your provider. Of course the more features it provides the more vendor locked you will get, especially with hybrid relational DBs.
I think that the biggest benefit for Gaming is in the integration with other serverless services like in SDK of Kubernetes Engines, Serverless Application services, Function services where integration helps to get the best performance and best availability (based on region and internal network). Another less obvious advantage is entry to the Analytic world, where you can better control and process data from SQL than from NoSQL.
We've already touched on the topic of Hybrid Databases in the previous chapter. I'd like to show you some more options on how to incorporate object functionality into SQL DB. There are several approaches but for simplicity let's talk about one of them. I'm talking about JSON object storing and querying here.
SQL Server provides 2 types of JSON storage in text and as a jsonb (aka JSON Blob) object type, and also querying. PostgreSQL also provides similar functionality with JSON objects. You can read a nice article in simple English about how to use this functionality here. And here is more info with technical details for MySQL JSON lovers.
If you feel more comfortable in Relational DB and you already are a master in SQL querying, you can definitely benefit from both worlds. Hybrid Databases will give you horizontal scaling and storing of JSON objects that will help you design some features without strict relational constraints on DB model and data consistency. This can help you to be more flexible if you need to update DB models or in designing your Gamed Data (especially on the fly).
And let's move to my ultimate favourite - NoSQL DBs. I do think they are the best for modern, online Cloud Games and especially good for Microservices of the game backend. I'm talking mainly about Object and Document type of DBs which are most suitable for Game Development. But anyway, if you find any other type of NoSQL database suitable for your service, then good for you! :)
And why are NoSQL Databases so great?
Because you can store any type of data in any specific part of DB without strict Data Model and Constraints. Not convinced just yet? Let me tell you a few reasons why I'm sure you'll love them.
1. You can scale the DB more easily. -> less work and time spent on thinking about how to handle such and such amount of Data/Request.
2. It is easier to replicate data on Global Level. -> You can update DB in the European node and get the same data on the Asian one faster (in milliseconds). That means you pay less for the traffic, your response is faster and you have back-ups in more then one node.
3. You can have different data types based on the different versions of your application at the same time in the same DB. -> Canary deployments or A-B testing has never been easier. You can patch data based on the version of your app that is being red/written.
4. Storing binary objects -> you can transfer data in special binary objects (not as a text), which will really improve response time and the price of your traffic.
5. Less compute time needed to ETL (extract, transform and load) -> You need less compute power to store or read specific data from DB and that means - cost reduction again!
6. No Joins. There is no time for consuming queries that have to search through 27 legacy tables.
7. No confusing default values of the attributes (columns), which you will never use in this type of object. No legacy data (if not needed).
Sounds great, right? Of course it has some design flaws such as less indexes or only a simple query based on key/value or based on data type stored in the object. But in general it brings more pros than cons for online games and game back-end created from Microservices.
Let’s have a look at what the Cloud offers. It is hard to compare NoSQL DBs because most of them work on different principles but I will try to focus on similar products.
One of the greatest is AWS DynamoDB which is a mix of key/value pair and Documentdb with great performance. Combination of key/value and Documentdb makes it suitable for almost all use cases that Gaming studios can experience. From serverless Web Apps through Mobile backends and Microservices. What makes this product even better is SDK integration with Elastic BeanStalk or Lambda for example. Your Serverless DB grows with your Serverless Compute Engine simultaneously.
MS Azure comes with a different solution. Azure Cosmos DB is an open SDK that provides services for Table API, SQL(Core), MongoDB, Cassandra and Gremlin. Based on your needs, you will use a suitable DB engine for your service.
Google provides two DBs (which actually is one with a basic and advanced mode :-)) - DataStore and advanced Document version Firestore. Firestore is comparable to AWS DynamoDB. It is suitable for most of the needs of a gaming studio. The integration with Google AppEngine - Cloud Function and Cloud Run are phenomenal.
NoSQL DBs were created for multi storing and fast data replication, high availability and easy scaling. All these attributes are needed in modern multiplayer online games. We can definitely get a lot from SQL databases but why to abuse them if we have something better that is built for usage in the cloud. Think not only about these benefits but also about the future ease with Canary deployments, no downtown updates or running different service versions on the same DB.
Your players, developers, game designers and analytics will thank you!
If you have to read all your data from DB every time the app requests it, you will either go bankrupt or your service will get unavailable under a heavy load.
To prevent these issues you need a cache. And if you have a multiplayer game architecture you won't only need local cache but also a global one (server scaling + geographical nodes).
If user data is accessed more than once per user session (not only game session), or if your service doesn't store data for more than 15 minutes (Matchmaking, Match Leaderboard...) you should consider using cache. If you use managed DB by your cloud provider you pay not only for reads and writes of data but also for the transfers. This is time and cost ineffective.
AWS offers Amazon Elastic Cache for this. It offers two managed services - one for Redis and one for Memcached. Google comes with the same solution for both Cache engines called Memorystore. In older versions of AppEngine you were able to use internal Memcache for no additional price to AppEngine CPU time, but as it is so cheap and powerful, Google plans to gradually end it, and in a few years replace it with Memorystore.
And finally Azure Cache for Redis is managed by Redis from Microsoft.
In case you will opt for Redis solution you can use it as NoSQL key/value pair DB as it supports persistence. This is handy when you are trying to build e.g. highly responsive leaderboards which will be available during the whole life (several years) of your game.
Now we are in the phase where we know how to run, scale and manage our services, but we don't know how to connect them internally to work as one big Game Backend.
Not all the API calls can be done synchronously in real time and not all calls are suitable for asynchronous calls. There is a one way cloud solution that I mentioned in the previous chapters. - Cloud Functions (AWS Lambda, Google Cloud Functions, Azure Functions). But those are event-driven calls, more suitable for ETL or ELT processing for analytics and can’t be used as a buffer. To drive the request load or read load of the DB or CPU and memory usage you can employ Queues easily.
There are some advanced Queues implementations like Apache Kafka or ActiveMQ you can host on your cloud as well, but I would like to concentrate more on managed solutions from cloud providers.
AWS provides two types of service here - Simple Queue Service mostly as a middleware between services and advanced Publish/Subscribe version Simple Notification Service which can be ordered and you can even use it to notify users by Push Messages or SMS.
Azure has its own implementation in managed Service Bus which is an ordered Pub/Sub queue.
Google has its own service called Pub/Sub which is ordered (in the region) queue. Google comes with its own special implementation of asynchronous queue called CloudTasks where you can specify workers to be executed on different services. Difference with a Pub/Sub queue is that a normal queue is only middleware (it means it has no decision power) but Tasks can decide and plan workload in your Backend.
And with this product we are touching event-driven pipelines like Azure Event Grid and AWS Event Fork that are used to load big amounts of data mostly into analytics. Game Analytics is the theme for its own Blog post, so we will skip it for now.
By employing managed Queues you can easily manage data flows and request load on services inside your game back-end. Decouple microservices and manage the cost of your solution. On the other hand, you can implement Game Chat, Matchmaking or Spawning to the Match in Pub/Sub systems. Most of the managed services provide free inbound and outbound traffic in one region or node. They are a great solution to work with your dedicated servers. If your back-end contains more microservices and you are planning to build your own analytic pipeline in the future, Queues should be one of your most used managed services in the cloud. Take a good look at them too.
I tried my best to walk you through all the services I think you will need to build a modern back-end for a multiplier online game. I hope it will help you figure out which cloud provider is the best for you.
The more knowledge and skills you have in building infrastructure and managing orchestration tools for Kubernetes/Docker or Networking, the more options you have because you won’t be vendor-locked to a specific SDK or product. You can even combine the best tools from all providers if you dare. I personally don't recommend this as it requires deep expertise, knowledge and research of all platforms you use that can - in the long run - conclude with more costs than running your solution with one provider.
Little ad in the end. :)
If you are not sure where and how to start, Revolgy is more than willing to take a look at your current solution and help you pick the best Cloud Platform for you, design your infrastructure on the cloud and build your backend architecture for best performance and cost-effectiveness