Software as a Service (Saas) is a delivery model where consumers pay to access functionality provided by a system when they need it without having to manage, purchase or be responsible for the software providing the functionality.
The large scale adoption of SaaS as a delivery model by providers has been fuelled by the adoption of cloud hosting. The emergence of the cloud made it possible for providers to easily stand-up and scale compute resource in order to provide functionality to large numbers of consumers. This in turn meant consumers no longer had to own their own infrastructure and install software in order to take advantage of the service.
As the use of SaaS has grown the importance of the underlying architecture being suitable for cloud hosting has become ever more important, this has lead to the concept of the Twelve Factor App. This manifesto defines twelve factors that should be adhered to in order to build software with a scalable architecture. I'm not going to go through all twelve factors in this post, instead I'm going to concentrate on the principles that underpin the definition of these factors and which they are designed to promote.
Declarative Infrastructure
In the past knowledge about the architecture and make-up of a systems infrastructure was either held inside engineers heads or within cumbersome documentation that had a strong propensity to become outdated or inaccurate. This meant whenever changes were required or disaster struck the number of people who could effectively deal with the situation was limited, it also makes reversing changes more challenging and provides a barrier to entry for new engineers joining the team.
To deal with this situation we can use declarative formats to define our underlying infrastructure. Sometimes also referred to as Infrastructure as Code this approach uses technologies like Terraform, Chef or Puppet to drive the generation and maintenance of infrastructure in a machine and human readable format that shares many of the properties of code.
This approach allows these files to be managed under source control providing more robustness around the history of changes in the infrastructure and the ability to rollback. Since these files are driving the shape of the infrastructure they also cannot become outdated or out of sync with reality. The repeatability of applying these files also means scaling or recreating your infrastructure, in both development and production environments, becomes an error free process.
Finally new engineers joining the team, providing they are familiar with the technology being used, can easily and quickly get to grips with the nature of the infrastructure and become effective.
Clean Contract
One of the benefits of the cloud is portability, the ability too quickly move between hosting environments, operating systems or hardware configurations. The ability to do this can be easily undermined if your software does not have a clean and well defined contract between itself and it's dependencies.
This can be achieved by proper adherence to dependency declaration and dependency isolation. Software should never rely on a dependency implicitly being part of the environment it's operating in. All dependencies are explicitly declared via some form of manifest that forms part of the applications source code. Many technologies exist for achieving this depending upon the stack you are using to develop your software. Gemfiles, NuGet, Chocolatey and many others all provide a way for software to declare that it is reliant on certain other packages being available. This not only reduces the risk of unfilled dependencies once software is deployed but also makes it easier for developers to simply clone the code and build when getting started in the team.
This applies equally to the availability of system tools that maybe dependent on the underlying operating system, every effort should be made to isolate these dependencies and ensure that the functionality is provided to the application in an explicit and declarative way.
Minimal Divergence
Many issues and problems that present themselves in production will be meet with incredulity by developers since everything worked fine on their machine. These situations are born from the divergence of development and production environments. Many of the principles and techniques we've already discussed work towards reducing this possibility and ensuring as far as possible all environment are the same.
This is achieved by the proper application of continuous integration and deployment. This has the effect of reducing the amount of time between code being developed and being available in the environment and ensures that the process of code being developed and deployed aren't separate responsibilities.
An important aspect to achieving this is also to ensure that technology stacks don't vary between environments. The same database, web server and operating systems are in use everywhere that the code runs. Clearly the resource available in these environments is likely to be different but the fundamental fabric of the technology is kept in line.
The adoption of a cloud based SaaS delivery model is about more than simply where your code is hosted. Rather it is about divorcing your code from having any meaningful relationship with it's hosting environment, the freedom this gives allows for agility, efficiency and productivity.
As with most things whether or not you are embracing a SaaS model is not a binary operation that is on or off. It's about placing yourself on a scale but trying to adhere to the principles described here will help you reach the tipping point where the benefits of the approach will start to be realised.
