By biztree
Is your Software-as-a-Service (SaaS) business ready to grow? Will your application be able to respond to unexpected traffic spikes? What happens if the new product you just released receives an unexpected celebrity endorsement on social media? Could your website handle the sudden traffic spike? What about if a sudden industry shift creates an unexpected need for your application?
Think that’s not likely? Ask Zoom about what happened at the beginning of the pandemic.
Do you think you are ready to grow? Well, maybe not. To prepare your SaaS business for growth, your application must be ready to scale, and it must be ready to scale at a moment’s notice.
Preparing your SaaS business to grow and expand your customer base involves more than just coding changes. It requires business changes and a commitment to processes and methods. Presented here are seven things you can do to make sure your organization is ready and well-positioned for hyper-growth.
1. To prepare your SaaS business for growth, commit to DevOps
DevOps isn’t the cool kid in town anymore, but the fundamental principles of DevOps are as sound and important today as they were when the term first started being discussed.
DevOps is, at a fundamental level, simply the merging of software development and operations. In the early days of computer applications, the developers of the software were not the same individuals as the operators of the software. Software was written, and “thrown over the wall” to the people that had to operate the software. This created an us-versus-them mindset, and problem resolution was often a matter of finger-pointing between the development team and the operations organization. The disconnection between the two critical teams led to lower-quality software and longer development cycles.
In the early days, DevOps was seen as a way of stopping that cycle. In DevOps, a single team has both development and overall operations responsibility for the software. Sometimes, different individuals or sub-teams would be more development-focused or more operations-focused, but the team as a whole is jointly responsible for both development and operations of the application. This removes finger-pointing since all problems ultimately belong to the single team—there is nobody else to point the finger at.
DevOps process and principles have matured significantly as the years have gone on. DevOps now encompasses an entire lifecycle of product development and operation that includes incrementally improving software and deploying changes in smaller pieces, on a substantially accelerated schedule than was previously possible. This is doable because the single team owns everything, and there is no longer any release coordination that needs to occur between organizations just to transfer ownership responsibilities.
With the advent of web applications and SaaS applications, DevOps took on additional value. It removed the entire concept of software version management and replaced it with continuous deployment and continuous improvement capabilities. Incremental changes are easier to test, easier to deploy, and easier to roll back if they cause a problem in production. DevOps has changed the way we develop, operate, and use software applications today.
2. Embrace a service-based architecture
Your organization needs to scale, too. How many developers can realistically work on that single monolith without stepping on each other’s toes? How can you deploy any serious change when you can’t even test the Goliath in front of you? In order to handle independent teams working on different projects on the same application, you have to build the application in a service-oriented architecture, such as using microservices.
The goal is to have your application built out of multiple, independent services. Then, assign each service to be owned by an individual development team. That team owns all aspects of the development, testing, deployment, operation, and problem diagnosing of that service. Each service provides a Service Level Agreement (SLA) to all the services and systems that make use of the service. This contract provides a set of performance guarantees that allows one service to successfully make plans by relying on the performance of its dependent services.
There is a model that describes this sort of team organization and product architecture that I use. It’s called the Single Team Oriented Service Architecture, or STOSA for short, and it describes both the team makeup and organization and how the application is divided up and managed.
3. Monitor everything
In order to effectively scale your application, you have to understand how your application is performing in all aspects of its operation. This means you have to monitor all aspects of how your application is running, and you have to monitor it continuously.
By monitoring it continuously, you can detect long-term trends in how it is performing, and catch problems early in their formation, allowing you to quickly respond when a problem does appear.
But having metrics is one thing, and making use of them is another. It’s critical that each development team monitor the metrics for how their individually owned services are performing, and respond to problems when they first appear. Additionally, when events happen—events such as deployments or spikes in usage—anomalous metrics are important early indicators of problems that are waiting to happen.
4. Prioritize availability
Your customers expect your applications to work—all the time. No exceptions are acceptable.
Unfortunately, some companies believe that the way they can maintain high availability is by scheduling regular maintenance windows that are used to perform upgrades and other maintenance, in order to ensure the application works successfully at other times. This is a bad practice, and you should not be overly dependent on maintenance windows. First, maintenance windows also count as downtime. Your customers don’t care that the downtime was planned, they care about whether your application is down or not. So, simply planning for downtime does not change the negative impact on customer perception.
Second, maintenance windows are a crutch. Almost all maintenance and upgrades that you need to perform to your application can—and should—be done while the application is operating. It may be easier to perform the upgrade when the application is down, but doing so allows you to avoid asking important logistical questions about the operation of the upgrade.
By taking the easier way out—taking the application offline during an upgrade—you are lowering your availability. Instead, take the time to figure out the right way to perform a maintenance operation or upgrade that can be done while the application is still operating. You will find that the harder problem requires more initiative, and requires you to think about more situations that could happen and negatively impact your application. The simple requirement that your application remains up during an upgrade will encourage the development of best practices that will improve the quality of your application overall and better prepare your SaaS business for growth.
Amazon S3 is a great example of a service designed for high availability. All maintenance and upgrades are performed without taking the service down. As such, AWS guarantees a 99.99% service availability. This means it guarantees the service will be down for a maximum of 61 seconds each week. No more downtime than that and the company refunds money to their customers. This is a high level of availability, but it’s nothing out of line that most well-designed and well-managed applications can achieve.
5. Understand your organizational risk
All applications have risks associated with operating them. You can’t remove all risks from a complex system such as a web application. However, examining, measuring, and monitoring risk can be an effective tool to reduce the impact of complexity on the operation of your application.
Risk management involves three steps:
- Determining where the risk is within your system.
- Determining which risk items are critical enough that they have to be removed from the system.
- Determining a plan for mitigating your remaining risk to reduce the likelihood or severity of an issue should a problem occur.
Using a risk matrix is a great way to manage the risk in your application. Each service owner should maintain a risk matrix for their service, and the risk matrices from all the teams should be combined, prioritized, and managed at the application level as well. Risk matrices provide a great way to communicate unresolved technical debt and other issues with upper management and policymakers in your company.
6. Leverage “just in time” infrastructure
Nothing makes scaling easier than using resources in the public cloud. Built the right way, your application can quickly scale to handle significantly more traffic by allocating additional cloud resources at just the needed moment.
Cloud scaling can assist with meeting burst traffic needs (such as from that unexpected celebrity endorsement); handling cycle traffic patterns (such as lower weekend uses and end-of-month peaks); quickly replacing failed instances; launching test environments the size of production for large-scale testing needs, and smoothly transitioning to upgraded systems.
I call this “just in time” infrastructure, or JIT infrastructure, and it is an effective tool to manage your constantly changing and expanding infrastructure requirements and can prepare your SaaS business for growth.
7. Automate everything
All business and technical processes in your company should be automated. From a technical standpoint, this includes application testing and deployment. It includes updating the infrastructure of your application, and it should include all processes such as problem resolution, review, and decision-making processes.
Automation removes single-point failures. Manual processes can break down at any point simply by human error. Automated processes are repeatable and dependable.
All system changes, infrastructure changes, and process changes should be reviewed, tracked, and monitored. That way even changes to the automated processes will have change records documented. This allows the post-mortem process of an outage or failure to see if a recent process change may have impacted the problem.
Automation is the key to a safe, dependable, and continuously successful system, application, and organization.
Prepare your SaaS business for growth before you need it
Following these seven steps can improve your application’s ability to scale, and your SaaS company’s ability to grow and expand.
