The Future of Klevu’s Architecture: The 12 Factor Application

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. 

In summary

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. 

To learn more about the features that Klevu are currently deploying, submit a demo request here.