More and more SaaS businesses are taking off the ground today. And it’s great.
The SaaS business is a super-fast growing industry attracting more and more people and companies. These organizations are more and more floating applications in the cloud. Scaling in the cloud has some essential benefits and risks as well.
In this article we are going to show you how to start building a cloud-based SaaS architecture, dealing with issues of scalability and what this means for your SaaS application.
Everything in the cloud.
When building a (global) SaaS application chances are high that you’re building it in the cloud. The cloud has a lot of advantages – think of scalability – in contrast to local server environments.
Therefore this post, and the ones which will follow, focus on software which is built and engineered in the cloud. Here’s how to secure a cloud-based SaaS architecture.
How to get started?
Which programming language, which database, which software tools should you choose? There are many questions which need to be answered. Therefore I’m trying to focus on the most important things.
So, first things first.
Which programming language?
Building a product for the cloud means building a product with a modern programming language.
Besides personal abilities and skills, the choice of your programming language will be influenced by the possibilities of each language. There are various (modern) programming languages out there making it a hard time to choose the right one.
Take a look at the most prominent ones, play around with those and try to experiment as much as possible.
We did that. And we ended up using Python.
Python is a widely used programming language, designed to emphasize on its code readability.
Python can do a lot of things. Whatever web app you’d like to build, there’s likely a framework for it in Python.
We at Usersnap had quite some experience with Python before using it for our web app. As mentioned, it’s flexibility for various use cases was yet another reason for us to jump on Python.
Python is great and our developers love it. Dynamic typing, metaprogramming, rapid prototyping. Everything’s possible with Python.
Python is a safe bet.
The perfect database
So, one of the first things on your list will include the installation of a database. We recommend making use of a document-oriented database. Document databases are quite different to the traditional concept of relational databases.
Why choose a document-oriented database?
Document databases get their type information from the data itself. Thus every instance of data can be different from any other.
This allows more flexibility, especially when dealing with changes. And it often reduces database sizes.
In summary, the DOB concept offers a richer experience with modern programming techniques.
MongoDB – the database for your web app?
We – at Usersnap – ended using MongoDB as our prior database.
Why we choose MongoDB? Because MongoDB is a document-oriented database that provides high performance, high availability, and easy scalability. Yep. Besides performance (who wants a slow database?), scalability is the most important factor for us as a global SaaS business.
A lot of SaaS founders aim for scaling their business. Besides scaling your product from a business perspective you shouldn’t forget about the technical matters.
Scaling your tech with MongoDB is pretty easy (ok, at least easier compared to other databases). With automatic sharding you can distribute data across various machines.
Sharding is a method for storing your data across multiple machines. And MongoDB uses sharding to support deployment with large data sets.
Learn more about the concept of sharding with MongoDB.
So, how we’ve set up MongoDB for our SaaS application?
We – at Usersnap – are making use of Amazon Web Services and therefore have set up EC2 instances in Ireland, the US and Singapore.
Getting started with MongoDB we installed a single MongoDB instance on our AWS EC2 instance in Ireland.
With the increasing number of US and Asian customers, we noticed performance issues in those areas of the world.
Therefore, we installed a master/slave architecture with the master still in Ireland and added two MongoDB slave instances in the US West Coast and Singapore.
Those two slave DBs utilize read preference to avoid queries across the globe to keep network delay for frequent read operations as low as possible.
Writes still go directly to the master DB and get replicated to the slaves automatically by MongoDB.
Let’s talk about a queuing system now.
A message queuing system is an asynchronous communication protocol, enabling sender and receiver of a message not interacting at the same time.
Also known as Message Queuing (MSMQ) technology it enables web apps to run at different times and to communicate with various 3rd party integrations / APIs / and other services asynchronously.
A message (e.g. a query asking a 3rd party service via an API) is placed onto the queue. It’s stored there until the receiver retrieves it.
A message queue has limits regarding the size and amount of data transmitted in the queue. The great thing about modern queuing systems is that the can be scaled easily.
Again, I’d like to give you some insights on the queuing system we use. RabbitMQ is a great open source queuing system running on all major operating systems.
We run our web app in on the AWS EC2 where RabbitMQ can be run installed and run super smoothly.
Make sure to check out this guide on how to run RabbitMQ on EC2.
How we installed RabbitMQ?
Python with the open source celery task management library is the perfect fit to get the most out of RabbitMQ. It’s tremendously important to have a robust and well-proven piece of software at this point because it builds the backbone of our infrastructure.
Actually, we’re using a single RabbitMQ server, with multiple endpoints that feed the queue with tasks (periodic tasks as well as tasks induced by user actions) as well as endpoints that process those tasks (e.g. produce our nice-looking screenshots).
The optimal configuration would include a second RabbitMQ server to offer replication and failover mechanisms (by hiding them behind a load balancer).
AWS & EC2
Building a scalable web app you’ll probably end up at using Amazon Web Services sooner or later. My guess is sooner 😉
AWS enables you to host and run your web apps as well as performing massive high-performing batch jobs. With Elastic Compute Cloud (EC2) AWS provides scalable virtual servers for every business.
The Amazon EC2 is a must-have for and the heart of our system which provides resizable computing capacity. We basically have rented virtual servers on which our web app runs.
The great thing here is, that those EC2 servers are spread across the world. Depending on your need to scale and which geographic markets to target first, you can select between various locations of your EC2.
Currently, we have three EC2 servers which are located in the US, Ireland, and Singapore. We’ll keep adding further locations (especially in the US and Europe) since the demand of our product keeps increasing. With the EC2 installed it’s super easy to keep adding new servers and resources.
Web Storage S3
Getting more and more users on board for your product will make you easily wonder about your web storage. With the Amazon S3 storage service, we have a great, and highly scalable object storage installed.
Amazon Simple Storage Service (S3) is easy to use, store and retrieve any amount of data. You might wonder if Amazon S3 can only be used with other AWS services? The great answer is: no. It also can be used alone or with other 3rd party storage repositories and gateways. And of course, it works great together with EC2.
Besides storing your data of your web app with S3, it might work great for backups, archives or big data analytics.
Content Delivery Network
A content delivery network (CDN) is basically a system of distributed servers which enables you to serve content to your app users with high performance and high availability.
Let’s assume you have 3 EC2s installed. One in the US, one in Europe and one in Singapore. If someone from New York visits your app, the CDN enables you to serve content to the user through the EC2 located in the US.
So you might wonder how to connect the dots. Below you can find an overview how we at Usersnap have set up our web app and the role of EC2, S3, and CDN.
With Python, MongoDB – as a great document-orientated database, RabbitMQ software-wise the basic setup is done. However, there is way more to think of. In our follow-up posts, we will address the need of a proper monitoring and analytics software as well as how payment procedures can run smoothly in the cloud.
Further on, we will also show you some in-depth guides on how to set up your tool stack for running your web app on a global scale.