Having a fully functional, working SaaS product is simply not enough. Your product needs to be portable, scalable and resilient. Klevu’s architecture is changing for this reason. Read on to find out more!
Introducing, the 12 Factor Application...
Klevu is currently undergoing a transition from its legacy architecture to a more sophisticated and scalable version of its existing system design. Klevu’s architecture has always been extremely intelligent but the development team have recognized the need for a more scalable paradigm.
We have a brand new set of principles that are focused on keeping software portable, scalable and resilient.
As with many other SaaS companies, when launching a new product, the focus is usually on building a fully functional, working product and the feature set offered. Although this is critical as the business experiences growth and develops it is also important to focus on how well the product can scale and grow into the future.
Scalability is multi-faceted, but this short article will focus on one aspect: the ability to rapidly deploy system fixes and enhancements without being slowed down in the process.
Deploying fixes and enhancements is not a problem unique to Klevu. Any software company will face individual challenges when it comes to rapid deployments and the management of complex software systems.
What Defines A 12 factors Application?
The 12-factor application is a set of 12 principles that are focused on keeping SaaS products portable, scalable and resilient. It can be seen as the cornerstone of good app development.
Let’s dive into the 12 principles:
1 - Codebase
There should be one central codebase tracked in revision control to facilitate multiple deployments.
2 - Dependencies
Dependencies, such as supporting software versions should be explicitly declared and isolated where possible.
3 - Configuration
Configuration should be stored within the environment itself so that specifics of the setup are not lost or attached to the environment itself.
4 - Backing services
Backing services should be viewed as integral parts to the system and therefore explicitly declared in all versions of the software.
5 - Build, release, run
These three processes should be kept strictly separate so that they can be run in isolation to each other for efficiency and ease of use.
6 - Processes
Execute the app as one or more stateless process(es).
7 - Port binding
Services should be exported via port binding.
8 - Concurrency
The application should use the process model in order to scale for concurrency.
9 - Disposability
The application should have the resilience and be able to be redeployed quickly and easily. This includes graceful shutdown and fast startup.
10 - Development and production parity
Keep development, staging and production as similar as possible to avoid issues with production deployments.
11 - Logs
Treat logs as event streams for the most effective use of analytics data for spotting and fixing issues.
12 - Admin processes
Run admin/management tasks as one-off processes. These are meant to be more state-related and manual than scheduled or automatic tasks.
These 12 principles are designed to be followed as guidelines, not necessarily absolutes but can be applied to many different software models. It helps developers to focus on the values and attributes that are suited to today’s cloud-based internet.