Today we launched http://cn.plunify.com. Users in China will be able to enjoy a faster and smoother experience. Upon clicking on the login button, they will be re-directed to a server located in China which acts as a "gateway" to the Amazon Web Services cloud.
If you have been in China, even in major cities like Beijing, you will realize that Internet access to the rest of the world is slow and connections are often even dropped. It is common knowledge that this is partly caused by the Great Firewall of China. While there are solutions such as using proxy servers which get you to the websites you want, latency is high and bandwidth is limited. This becomes a problem for Plunify users in China trying to access our platform in the Amazon Web Services (AWS) cloud.
So how did we overcome get around this problem?
High latency and limited bandwidth
Unless we lay extra submarine cables from the coast of China to US, there is no way our little company can make the access faster.
The main problem was that with connections dropping, our Web-based project manager which runs multiple AJAX connections gets stuck waiting for responses. Sometimes a page will load and sometimes it randomly fails to materialize due to packet losses. Also, the latency can get very high. Uploading a file in parts felt like the entire system was running on a 56kbps modem connection. The problem seems less severe in the Shanghai/Shenzhen regions.
Getting Around It (is easy in theory)
The solution is blindingly obvious and simple - run everything locally (in China)--if only AWS has a region in China. However, they don't and maybe they never will.
So our solution comes with a twist - we will run all user interactions locally, but maintain the compute intensive workload on AWS. This means we will have 2 logical parts, one is a server running locally (on a cloud provider in China), one server running on AWS and some way of connecting both parts.
First, we plan security
It was important that the local server in China was segregated logically from the rest of our network. For example, within hours of starting a server in China, we had already detected several scanning and broadcasting activities (which we blocked) going on in the background. We also hardened the server by using keys instead of the usual name-and-password account login. Temporary files are cleared after uploading and nothing is left un-encrypted if necessary.
Someone to relay the good news - an efficient messenger
To ensure these two logical parts communicate efficiently, we adopted Advanced Message Queuing Protocol (AMQP) as a messaging system. It felt like overkill as AMQP systems are normally used in the financial services industry. But we were impressed by its robustness, speed and ease of use. Besides notifications, we also use it to transfer small files. I will leave out the implementation details but it you are interested, feel free to ping us.
Enhancing the user experience
The first aim is to improve file upload. Now, the files are uploaded to our local gateway before being transferred to S3 in AWS. This speeds things up a lot as once a file is up on the local gateway, we can optimize the upload to S3 better. We also added in a web-based multi-file/drag-drop uploader for ease of use. This combines with a progress indicator, allowing users (not only the ones in China) to know how much time they have for their coffee break.
For the web interface, dropped AJAX connections are now a thing of the past, a figment of last week's imagination, a nightmare on another street (you can tell that I'm happy about this). Databases and files are all sync-ed up behind the scenes using some nifty scripts.
What can go wrong
Now, if you are reading this from China, we still believe that there are ways to improve the access and experience. Let us know if you are willing to help us do more testing and also get a feel for the new interface!