Best Practices for SaaS Development Using Microservices

One question startups always face when developing software for their product is: Which SaaS architecture pattern to choose—monolith or microservices?

How to choose the right SaaS platform architecture for your startup

I would suggest starting with what’s simplest for now, and planning for the future. That being said, when starting a quick POC it might be easier to do a quick monolith, but when planning a full production environment, microservices is the proper way to do it.

Architectural decisions, once taken, shouldn’t be considered final for the whole life of the product. Hence, a change from a monolith to a microservice Saas architecture is a possibility to be considered, even though it might get harder to change once the product starts to grow in complexity. Sam Newman’s book Monolith To Microservices addresses this topic pretty well and gives an idea of what to expect when planning this architectural change.

Another aspect to consider is this: How do you provide your product to your customers?
Customers always come first.  And customers worry about data protection when using software.

What are the features of a good SaaS architecture design?

To provide a complete service to your customer, you must consider three components when thinking about SaaS application architecture.

Security

This component’s scope is related to how your solution will handle user data and access to that data. It is imperative to create a robust security process that can keep up with a growing customer base. This way, the product will be able to scale without risking security breaches and cement its position in the market.

Data Privacy

Nowadays, data privacy is a hot topic and a significant aspect of every publicly available online service. This topic is also related to legal and regulatory norms depending on the country of operation and can be a complex topic. It is essential that your solution architecture keeps data privacy in mind.

Customization

A product can increase its possibilities of success by engaging with more users and onboarding them as regular customers of the service. This will be easier if you can customize the solution to target a broader range of users and allow product growth.

With the previous points in mind, let’s have a look at the benefits of SaaS architecture under two different architectural approaches for structuring your product: single and multi-tenancy.

The best use case for single-tenant architecture

First of all, let’s understand what single tenancy means and its pros and cons.

If you plan your product as a single tenancy architecture, you’ll have to provide a single instance of the software and the respective infrastructure to a single customer. This approach will give the customer their own version of the code and independent database.

Pros

• Security: increases the protection of each customer’s data and decreases the possibility of data leakage between customers since each software instance has its own database.
• Customization: increases the possibility of custom evolution of the solution throughout time.
• Controlled Evolution: each customer can choose which solution updates to apply and when to do it.

Cons

• Provisioning: every time a new customer is onboarded, new infrastructure needs to be provisioned.
• Increased Cost: having multiple infrastructures increases operational costs.

This is the best SaaS enterprise architecture in situations where the product core value is related to security and reliability. You want to evolve different customizations of the product per customer.

An example is a FinTech startup that provides unique and customized models for financial data processing for each of its customers. Each customer can choose the continent/country they want to store their data in. In this case, each customer will have their own implementation of the software and database, which means that each customer will have the code in a separate repository. Each repository will be deployed to a cloud provider and evolved with its own CI/CD process. Similar to the code, each database will also need to be handled separately and hosted in the customer’s geographic region.

The best use case for multi-tenant architecture

Now that we know what to expect from a single tenancy architecture, let’s look at the multi-tenancy approach.

With a multi-tenant approach, the software and respective infrastructure are shared by multiple customers. All customer data lives in a shared database.

Pros

• Cost Reduction: one infrastructure to support all customers helps decrease operational costs.
• Easy Updates: changes to the solution are rolled out to all customers at once.
• Customer Onboarding: a single onboarding process for all customers makes the process of acquiring new customers easier.

Cons

• Performance:  if all customers start to use the solution heavily, performance might decrease due to the number of requests.
• Security:  if an external malicious party has access to the system data, it might access all customer’s data.
• Single Point of Failure:  if the solution is down, it is down for all customers.

Multi-tenant SaaS architecture is the best architecture for SaaS in a case where the startups start growing their customer base and wish to take advantage of the pros listed above. An example is an online book store with one website for all customers. The data relating to books and all customer’s purchases are stored in the same database. In this case, a single implementation of the software and respective database can be deployed to a cloud provider and evolved with a single CI/CD process. A cloud-based SaaS architecture would be great for this.

Single-tenant vs. multi-tenant: which is better?

As we can see from the previous sections, each architecture type has its own value and can be useful in the right use cases. If you are concerned about security, go with a single-tenant architecture, but if your worries are related to operational costs, pick a multi-tenant architecture.

Nowadays, multi-tenancy architectures are more popular as they don’t require much maintenance, and the product evolution is automatically propagated to all customers. Multi-tenancy is also the easiest way to maintain intensely developed product solutions.

Five enterprise architecture frameworks for SaaS startups

When a startup starts to get traction and needs to scale, there is time to pick a framework to help structure the company and create a path for the future.

To achieve structured growth, the company can choose to adopt one of the following enterprise architecture frameworks. Let’s have a quick look at what each of these frameworks stands for.

Zachman Framework for Enterprise Architecture

The Zachman Framework for Enterprise Architecture was created in the 1980s and named after its creator, John Zachman. This framework aims to:

• Have a base understanding within the realm of a company’s IT systems
• Create architectural representations that bridge with business concepts
• Evaluate operational tools and methodologies and their relationship with one another; and
• Study tools that aid the construction of IT applications and compare them to understand which one is the best for the job.

The Open Group Architecture Framework (TOGAF)

TOGAF has been around for 25+ years. With a development process known as Architectural Development Method (ADM), it is composed of the following parts:

• Modular Structure—the TOGAF standard is composed of modules that one can add incrementally
• Content Framework—provides a detailed model of architectural work products
• Extended Guidance—it allows teams to extend the core framework and create an integrated hierarchy of architectures
• Architectural Styles—the TOGAF standard is designed to be flexible, and it can be used with various architectural styles.

Federal Enterprise Architecture Framework (FEAF)

FEAF is a management best practice for aligning business and technology resources. Originally used by the United States Government, it has become famous among private enterprises.

Gartner’s Enterprise Architecture Framework

Gartner, a global leader in IT research, has put forth a set of best practices for enterprise architecture solutions throughout the years. Its process focuses on evaluating the enterprise’s current state, identifying technologies to invest in, and determining the processes needed to achieve the desired future state.

NIST Enterprise Architecture Model

Originating in the 1980s, the NIST Enterprise Architecture Model aims to connect a company’s business, information, and technology variables and create an enterprise architecture. It is composed of a five-layer model:  

• Business Architecture—understand the business requirements and drive the information architecture
• Information Architecture—represents the types of content gathered from requirements
• Information Systems Architecture—automated and procedure-oriented information systems
• Data Architecture—describes the access and use of data
• Data Delivery Systems—technical implementation of the data architecture

Independent of the enterprise framework, the startup chooses to achieve growth. The architecture implementation needs to follow a set of best practices to guarantee the quality of the product. Let’s have a look at some of the best practices related to microservices architecture.

SaaS architecture best practices

When building the architecture of SaaS, you should follow a set of SaaS architecture best practices that will guarantee that your solution will grow with solid foundations. Let’s go through some of the best practices that should be followed.

Highly performant

Performance is vital when building a service that is to be consumed by a multitude of customers. To grow the customer base, it’s essential that the application doesn’t reach the market while still slow. Otherwise, new user adoption will be more difficult.

Scalable

The adopted solution should be highly scalable and allow the product to grow by adding new customers and keeping a good level of service. This point is usually a big challenge for startups, but when they get it right, it’s half of the way to having a good product on the market.

Highly available

Once the solution is ready, it’s essential to have it constantly available and reduce downtime to zero (or at least aim for that mark). A good infrastructure is vital to having high availability. Having a cloud SaaS architecture and having redundancy related to data and services are the pillars to achieve high availability.

Engaging user experience

Fundamentally, customers can interact with the service and have a good user experience. It’s one of the main factors that make customers annoyed or even cancel service subscriptions, so pay a lot of attention to this point.

Monitoring

This point is fundamental to tracking how the solution is performing while customers are interacting with it. Create a set of metrics related to technical aspects of the solutions and a set related to business metrics. These metrics can be displayed using dashboards or reports. The point is to have feedback and a way to understand how the solution is performing.

Conclusion

Building a product isn’t just about code or choosing an architecture. As we have seen when going through the sections of this article, it includes:

• Considering how to provision your solutions to your customers to ensure sustainable growth
• Choosing an appropriate framework once the company starts to scale to support the growth effectively
• Following best practices when developing the system

In conclusion, it is a long path filled with important decisions that should be thought out from the beginning so that the risks of failure can be minimized and the chances of successful growth increased.