A Software as a Service (SaaS) app is an app that is delivered through the browser. Just a few years ago it would have been very difficult for a small group, or even a single developer to launch a SaaS app. Now, with the widespread availability of cheap cloud technology, the barrier to entry has been significantly lowered.
What Do I Know?
In 1996 no one had ever heard of shared servers. So I rented some band rehearsal space, had it wired with a T1 line and installed my own Web servers. Since 1999, before the first dot-com bubble burst, I’ve been working mostly on Web projects with millions of users. I’ve worked on Web apps used internally by large enterprise customers and at startups in the pre-customer phase. Currently I’m working on a few SaaS side projects.
When I started on the large projects, we had to physically deliver PC’s to data centers hosted internally or at a remote third party. My cubes and labs were filled with so many PC’s that the facilities guys were worried I was going to start a fire.
Those days are over. Now everything is hosted in the cloud. The only hardware I use now is a single MacBook Pro.
SaaS App Components
A typical SaaS app needs the following:
- Cloud Provider
- User management
- Source control
- Continuous integration and testing
I would also strongly recommend the use of microservices to avoid creating an unwieldy monolith.
Containers are another area to explore. But it is not something that I would recommend for a beginner.
Pick a Cloud and Stay There
To get started in SaaS development you need to pick a cloud service provider. Because I like to build libraries and keep my options open, I’ve experimented with creating “cloud agnostic” SDK’s. You never know if a provider is going to do something that will make you feel like you need to switch. But it became a maintenance nightmare. To make matters worse, it takes a very long time to learn the intricacies of a cloud providers tools. Then you have to keep up with changes.
Trying to support two cloud providers is not worth the time and effort. I strongly suggest picking just one and putting all of your focus there.
Infrastructure as a Service (IaaS)
Here is a list of the most popular cloud providers, which fall under the category of Infrastructure as a Service (IaaS):
Platform as a Service (PaaS)
If you’re looking for something less complex, you can use a Platform as a Service (PaaS):
If you like working with raw servers:
If you know what containers are:
I’ve used AWS, Google, OpenShift, Heroku and Digital Ocean. For my current projects I’ve settled on AWS. If you’re new to SaaS development, I would suggest getting a few trial accounts and experimenting. When your free trial expires, keep an eye on billing to see if you need to change your design or switch providers.
Database as a Service (DaaS)
For database hosting you could create instances of Linux servers and install something. Or you could use a Database as a Service (DaaS) and leave the low level details to them.
I’ve moved on from SQL Server and MySQL. Now I only work with NoSQL databases. I’m a big fan of MongoDB. But as I worked with Amazon it just became easier (and less expensive) to integrate with DynamoDB. Just as with cloud providers, I strongly suggest that you settle on one type of database and stay there.
Here are some Database as a Service (DaaS) providers to consider:
- Amazon DynamoDB
- mlab - MongoDB
- MongoDB Atlas
- Amazon Relational Database Service (RDS) - supports MySQL, SQL Server, PostgreSQL, etc.
For user management, I use AWS Cognito to manage signup and login. I still have to wire it into my UI. But at least I don’t have to start from scratch.
I’ve been in a position more than once, where my company bought another company with a monolithic Web app. Some of those code bases were ten years old. Just turning them off and replacing them was not an option. Debugging was usually a case of poking it with a stick and seeing if it got angry. I have fully embraced the opposite of monolithic achitectures - breaking an app into microservices.
A microservice has only one endpoint (like: example.com/api/login). It’s small, self-contained, easy to maintain and can be deployed in seconds. If it is being deployed or breaks, it should have no effect on the other endpoints or the site. Developers can be restricted to only work on the code for the microservices they are assigned.
What about Programming Languages?
As an example, AWS Lambda supports: NodeJS, Python, Java and C#. Google supports Go, PHP and most of the other languages. I hear that Heroku is very popular with Ruby on Rails developers. On the larger cloud platforms you can create Linux server instances and install whatever you want. Be aware that such instances tend to be more expensive then using a platforms microservice option.
Most services provide a way to upload files using the command line. For my own projects I work the commands into scripts.
These days everyone uses git and has an account on github.com. Some of the services mentioned can be triggered to publish or test by pushing to a git repo (repository).
Continuous Integration and Testing
For continuous integration (CI) and testing, there are a number of services that you can use:
If you need to manage CI internally, you can try:
Most of the services mentioned either support containers or are looking into supporting them. Think of containers as lightweight virtual machines that can be pushed to and managed by a host. They can be rebuilt, replicated and moved into clusters. It is a bit of an advanced topic. If you would like to know more, visit some of these links:
- What is a Container
- Container Engine (Google Cloud Platform)
- Mitigating an AWS Instance Failure with the Magic of Kubernetes
Be warned that my initial experiments with containers on Google Cloud Platform rapidly ate into my free credits. So don’t leave any unused instances running when you don’t need them.