Hosting your mobile app’s backend
Very few apps these days don’t require any kind of backend service. With this post, I’m sharing some experiences we’ve gathered on figuring optimum setup for hosting a backend for your mobile application.
Why figuring out the backend right is so important for us at Appzio?
Appzio is a platform for developing native apps only from the backend. Mobile client downloads all of its configuration from the server and relies on the backend for its business logic and views. That’s why the responsiveness and performance of our backend services is crucial for good end-user experience.
Choosing YOUR backend
If you are developing an app as a regular native app, with ReactNative or using some other tool, you will generally need a backend for your app. First step is determining the complexity of the required backend. For simple data storage and retrieval, Google’s Firebase provides probably the best value for money at the moment.
Firebase is by default scalable & performant solution, but unfortunately at the time of the writing, it is not multi-region. Also, if your application requires more complex business logic, you will soon run into Firebases limitations — it has simply hasn’t been built for creating complex business logic. You can get around this with Cloud Functions to some degree, but for complex backends, it would not be my tool of choice. Obvious down-side with Firebase is that you will be fully dependant on Google with this setup and porting your backend to another service provider is a major undertaking.
As most mobile applications use a restful interface to communicate with the server, you can develop your backend with any programming language you are comfortable working with should you require more complex logic.
If you are using Appzio to develop your app, we provide scalable hosting service using Google Cloud or another cloud of your choice. And you can develop the apps with PHP and soon also with NodeJS.
If your app is targeted at single country or continent, you can skip this part. However, if you are planning to launch your app globally, location of your backend matters a lot. Network latency and throughput between the server and client plays a major part on the overall app experience.
Also; if you are within EU, there are rather strict regulations on where data can reside if there is any personal information saved on your app’s backend. Quite simply, if you have personal data and service EU customers, the data should be in the EU. All cloud & hosting providers can provide EU-hosting, but then for users outside of the EU, which hosting provider you choose matters a lot. Read more about GDPR here.
Appzio apps are primarily hosted in Google cloud, because Google provides the best latency across regions. Intercontinental data travels inside Google’s own network, providing unparalleled network performance and latency.
So before choosing your hosting provider, make sure at least to do simple ping test from different locations. You want your ping results to look something like this (ping on one of our servers, using https://tools.keycdn.com/ping):
Rather than something like this (ping on rackspace.com):
Before you jump the gun and start blaming me from completely unfair test, it should be noted, that Google does little magic here with their load balancer, giving simply amazing ping latency as the end-point is always near you. This is not the full picture, but it does reflect also when you run a test with website testing tool (https://www.dotcom-tools.com/website-speed-test.aspx).
Here are results from an Appzio API call:
And then a similarly sized payload from Rackspace website:
As you can see, the subsequent calls tend to be faster than the first ones. There are various reasons for this, but one issue which is often overlooked is the quality of the DNS service. So if you do your hosting setup properly, don’t leave the domain hosting hanging at goMama.com or another provider that doesn’t take the dns hosting seriously.
Single server hosting
Unless you expect your app to reach hundreds of thousands users in a very short time, easiest setup would be with a single server instance. This does impose a single point of failure, but if your backend is setup right, backed up regularly and hosted by a reliable provider, you don’t normally run into troubles with this approach.
For hosting virtual servers, best experiences we’ve had is with DigitalOcean. They provide an easy way to scale your server up as your usage grows and DigitalOcean management tools for servers are very user friendly. For heavier usage & bare metal servers, we’ve had excellent experiences with IBM SoftLayer. What you want to look for with this setup is that your server instance has guaranteed resources, good fast network connectivity and good tools to monitor the load.
Good bare metal setup with a backend that doesn’t have heavy data processing, will easily support tens of thousands of monthly users, even up to million monthly users if your backend is not too heavy on data processing.
This is also how we started hosting Appzio apps initially, but soon grew out of this setup as the requirements and app usage kept growing.
Need more bang from your single server setup?
Easiest next step for scaling up is dividing your app server, data storage and possibly caching to different servers. If its just a single backend you are hosting, you can also start by adding a load balancer without a more complicated cluster setup.
Thing to note though, is that as soon as you start throwing more servers in the mix, the internal network latency will eat some of your performance. Nothing is as fast, as a single bare-metal setup.
Appzio’s current infrastructure relies on Kubernetes for orchestrating app servers, database servers & auxiliary services. In order to setup different clouds and servers, we use Ansible for automating the server administration tasks. With Ansible, we’ve managed to make our cloud setup clonable with a reasonable one hour’s worth of work.
Our deployment relies on Gitlab, where we also host all our private and public git repositories. Gitlab is also connected directly with our app servers to provide automatic repository creation for customer’s custom modules, Android client building and for many other things.
Upon building a new version of the backend, Gitlab builds a new docker image, pulls the correct version of backend code from GIT and then deploys to Kubernetes pod(s). This makes it possible to easily revert previous version of the backend and easily add more pods as traffic grows. All traffic goes through cloud providers load balancer.
While network file share is easily solved with the cloud providers networked file share (just remember to test performance also here), the database scaling is more complicated to solve well.
Depending on the app, the app might either use a shared database server, dedicated database server or clustered database setup. Appzio’s data storage is MariaDB which comes with a built-in support for database clustering. However, due to how most SQL databases work with cluster setups, it might not work out-of-the box for multi-regional hosting.
To give you an idea on when to start moving to distributed setup, here is a snapshot from one of our database servers which is servicing 100k+ monthly active users:
Which translates to roughly 1 CPU only.
In other words, you need to be moving massive amounts of data, before you outgrow a powerful single database node setup.
Whether standard database clustering works for a multi-region setup depends largely on whether there are many database writes. SELECT statements are easy, but inserting and updating of data requires locking, which can slow things down considerably if you need to cross regions. Again, different providers have big differences on their internal intercontinental performance.
Here, if you can live without the relations support, the scalable hosting becomes easier to solve. MongoDB is an excellent option for key-value storage. And if you are not afraid of the Google lock-in, Google’s Cloud Spanner is one the most interesting things to happen in the database space in a long time.
For MySQL compatible scalable hosting, have a look at Percona.
If your app relies on many downloadable assets (images, pictures, videos, fonts etc.) its worth looking into using a CDN network. If you already have your files on some cloud providers shared network drive, most providers have an easy option to propagate file shares directly into CDN.
With Appzio apps CDN can be enabled with a single click of a checkbox.
Comparing different providers for CDN pricing and coverage can be surprisingly difficult. This nifty little tool can help on that, but unfortunately it doesn’t include for example Google, Azure and Rackspace.
Unless you really need more, go with a single server setup or a backend-as-a-service option.
If you need more, don’t go without a proper orchestration tool (Kubernetes, Marathon, Docker Swarm etc). And even though learning them is not rocket science, there are a lot of caveats, so seek professional help to maintain your sanity.
With a proper orchestration setup, you spend less time managing server farms across the globe with less effort that it used to take to manage a single server. Yes, the jump in productivity is really that crazy.
And remember, not all hosting & cloud providers are equal in terms of performance and features. We’ve seen a 4x difference in internal network latency between two leading cloud providers. That is a lot.