SaaS Gigafactory

Similar to Tesla, SaaS organisations require a gigafactory too! SaaS companies are required to have greater agility and velocity to meet the growing demands of the business. Especially when you require hundreds or thousands of engineers to be delivering code at a faster pace to production in a safe and secure manner. To support the hyper growth of the business, SaaS companies are required to have world class infrastructure. This infrastructure is what I call the “SaaS Gigafactory”.?

We live in a world where speed to market is a competitive advantage. Your teams need to scale and operate in parallel to meet the demands of the business and the customers. This means, thousands of code commits a day moving through the delivery pipelines into production in a safe and secure manner without any human intervention.

This is the foundation needed to support the hyper scaling of your SaaS business. The SaaS Gigafactory is needed to accomplish 2 core SaaS principles. The following 2 principles are fundamental to getting your foundation right for building and scaling your SaaS business.?

Principle 1: One single release for all customers on a frequent basis

Importance: Lower TCO,?low cost of maintenance, and higher margins

Being able to publish a single release to your entire customer base in a secure and safe manner is the holy grail of SaaS. This is why the SaaS business model delivers a lower cost of maintenance, higher efficiencies and higher operating margins. SaaS companies need to maintain only one version of the platform operating globally at any given time with frequent upgrades delivered in an agile fashion to the entire customer base.

Principle 2: Quality, Security & “-ilities” Guarantee

Importance: High NPS, Lower churn of customers, high revenue retention

In a SaaS world these non functional requirements (NFRs) become first class product principles. Quality, security, availability, scalability, reliability, and nearly any “always-on” metric are now a must have. These NFRs become the foundation of your SaaS business model. Failure in any of these will cause irreparable brand reputation damage causing significant loss of revenue.

The SaaS Gigafactory

This is known as CI and CD. CI and CD are two acronyms frequently used in modern development practices. The SaaS Gigafactory comprises of 3 stages. Each stage can unlock significant business value as the company move towards completing all three stages to build the SaaS Gigafactory.

• Stage 1: Continuous Integration: Shorter feedback cycle for engineers and always up to date main branch without any broken functionality
• Stage 2: Continuous Delivery: Always ready for production deployment with quality, security, "-ilities" guaranteed
• Stage 3: Continuous Deployment: No release days anymore and code goes live direct to customers in a matter of minutes

To accomplish this, SaaS companies need to invest in building the foundation that is required to do continuous integration, continuous delivery and continuous deployment. All three are required to complete the Gigafactory. This will be a multi year journey and it is important to take the time to build it right.

The name Gigafactory comes from the word 'Giga,' the unit of measurement representing “billions.” The Gigafactory is being built in phases so that Tesla can begin manufacturing immediately inside the finished sections and continue to expand thereafter ~ Tesla Gigafactory

SaaS Gigafactory Principles

The following 6 key principles are important when building the SaaS Gigafactory. These principles help lay the foundation for scaling your SaaS business.

1. Single commit moving through different stages directly to production live traffic
2. No human intervention with shorter feedback cycle to engineers
3. No static environments, everything is treated as livestock and NOT pets
4. Automatic roll back to previous known stable state upon failure
5. Slow ramp on production traffic with automated monitoring
6. Feature flagging capability to turn features on and off

Stage 1: Continuous Integration

Continuous integration requires engineers to merge their changes back to the main branch as often as possible.?Companies can choose to use Gitflow or trunk-based development as their branching strategy. The most important thing is to have the engineer's changes validated by automatically creating a build and running automated integration tests against the build.?By doing so, you avoid?integration challenges that can happen in the subsequent stages.

Shorter feedback cycle will help engineers immediately resolve any issues discovered during the integration testing phase. The entire feedback cycle from code checkin to build to automated integration tests needs to happen in mater of minutes. This allows engineers to quickly resolve any bugs before proceeding to the next task at hand.

Continuous integration puts a great emphasis on test automation to check that the application is not broken whenever new commits are?integrated into the main branch. The objective is to keep the main branch always up to date and without any broken functionality.

Stage 2: Continuous Delivery

Continuous delivery is an extension of continuous integration where product acceptance, quality, security, and "-ilities" related tests are run. This means that on top of automated testing, you have an automated release process with quality, security, and "-ilities" guaranteed. With continuous delivery you can deploy your application any time to production by clicking a button.

In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy changes to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

Getting to stage 2 is a massive accomplishment and will provide significant scale for your organisation. This will allow engineering organisation to add more developers to the system and scale without any productivity loss due to bad infrastructure.

Stage 3: Continuous Deployment

Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.

It is highly recommended to consider canary deployments to production. A canary deployment is a deployment strategy that releases an application or service incrementally to a subset of users. All infrastructure in a target environment is updated in small phases (e.g: 2%, 25%, 75%, 100%). A canary release is the lowest risk-prone, compared to all other deployment strategies, because of this control.

Canary deployments allow organization's to test in production with real users and use cases and compare different service versions side by side. It’s cheaper than a blue-green deployment because it does not require two production environments. And finally, it is fast and safe to trigger a rollback to a previous version of an application. Canary deployments provide additional protection if anything goes wrong due to an unforeseen issue. This limits the blast radius and it is a highly recommended approach.

Continuous deployment is an excellent way to accelerate the feedback cycle with your customers. Teams love continuous deployments because there isn't a "release day" anymore. No midnight release parties means engineers are happy and they can focus on building software, and see their work go live minutes after they've finished working on it.

Common pitfalls to avoid

• Kicking the can down the road and not investing enough in the foundation to enable the organisation to scale early on in the journey
• Customer driven bespoke solutions that have highly customised production delivery pipelines
• Trying to support multiple public and private cloud with on premise solutions
• Not a product priority or lack of understanding of SaaS principles
• Tech leadership does not consider this important enough to warrant focus and investments

Typically this is an afterthought, and the need arises when the organisation hits a scale problem when trying to expand the business. Please invest in the foundation early on to prevent the pain when trying to scale up the business.

Dhanush Hetti