More and more SaaS application 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.
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 build up a cloud-based SaaS architecture.
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.
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 (we collected the most important programming languages in 2017 here), play around with those and try to experiment as much as possible.
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, meta programming, rapid prototyping. Everything’s possible with Python.
Python is a safe bet.
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.
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.
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 datasets.
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 they 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.
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).
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.
While AWS and EC2 enable simple, flexible, and cost-efficient platform setup, they may not always be the right solution for your workloads.
SaaS developers who are building GPU-heavy or latency-sensitive apps may not get expected performance from Public Cloud. This is also true for any database, which may require customized configurations to optimize latency and transactions per second.
AWS does offer advanced cloud instances, but they come at a high price. An alternative to AWS, phoenixNAP Bare Metal Cloud provides access to advanced configurations at a lower price point.
The key difference is that Bare Metal Cloud is fully dedicated, providing consistent performance for demanding workloads. The lack of a virtualization layer makes it possible for applications to access CPU and RAM resources directly. You can choose between 20+ different instances based on your needs.
Built to enable cloud-native development, Bare Metal Cloud is API-driven and integrated with various DevOps technologies. It can be provisioned, scaled, and decommissioned in minutes via API, CLI, or Infrastructure-as-Code tools.
The platform is available on an hourly billing model for instant scaling or through monthly reservations that provide greater cost-efficiency for more predictable needs.
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 database backups, archives or big data analytics.
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.
This article was brought to you by Usersnap – your feedback and bug tracking tool. Used by software companies like Facebook, Google, and AddThis. Read this blog post about how Usersnap helps during your SaaS application development.
Release notes aren't just a list of changes—they’re a key touchpoint in the customer journey,…
Product updates aren’t just a box to check—they’re your chance to connect. And a changelog?…
What’s the point of launching a great feature if no one notices? The real magic…
Ever wonder how some companies make product updates feel like the highlight of your day? …
Picture this: You’re in the middle of a hectic workday, balancing strategic decisions with daily…
Ever wish customer feedback came with subtitles? With the right feedback analytics tools, you can…
