Category Archive:Full Stack Silo Considerations

A Sample Architecture

As you can imagine, the architecture of a full stack pool environment is pretty straightforward. In fact, on the surface, it doesn’t look all that unlike any classic application architecture. Figure 3-9 provides an example of a fully pooled architecture deployed in an AWS architecture.

Figure 3-9. A full stack pooled architecture

Here you’ll see I’ve included many of the same constructs that were part of our full stack silo environment. There’s a VPC for the network of our environment and it includes two Availability Zones for high availability. WIthin the VPC there are separate private and public subnets that separate the external and internal view of our resources. And, finally, within the private subnet you’ll see the placeholders for the various microservices that deliver the server side functionality of our application. These services have storage that is deployed in a pooled model and their compute is scaled horizontally using an auto-scaling group. At the top, of course, we also illustrate that this environment is being consumed by multiple tenants.

Now, in looking at this at this level of detail, you’d be hard-pressed to find anything distinctly multi-tenant about this architecture. In reality, this could be the architecture of almost any flavor of application. Multi-tenancy doesn’t really show up in a full stack pooled model as some concrete construct. The multi-tenancy of a pooled model is only seen if you look inside the run-time activity that’s happening within this environment. Every request that is being sent through this architecture is accompanied by tenant context. The infrastructure and the services must acquire and apply this context as part of every request that is sent through this experience.

Imagine, for example, a scenario where Tenant 1 makes a request to fetch an item from storage. To process that request, your multi-tenant services will need to extract the tenant context and use it to determine which items within the pooled storage are associated with Tenant 1. As I move through the upcoming chapters, you’ll see how this context ends up having a profound influence on the implementation and deployment of these services. For now, though, the key here is to understand that a full stack pooled model relies more on its run-time ability to share resources and apply tenant context where needed.

This architecture represents just one flavor of a full stack pooled model. Each technology stack (containers, serverless, relational storage, NoSQL storage, queues) can influence the footprint of the full stack pooled environment. The spirit of full stack pool remains the same across most of these experiences. Whether you’re in a Kubernetes cluster or a VPC, the basic idea here is that the resources in that environment will be pooled and will need to scale based on the collective load of all tenants.

A Hybrid Full Stack Deployment Model

So far, I’ve mostly presented full stack silo and full stack pool deployment models as two separate approaches to the full stack problem. It’s fair to think of these two models as addressing a somewhat opposing set of needs and almost view them as being mutually exclusive. However, if you step back and overlay market and business realities on this problem, you’ll see how some organizations may see value in supporting both of these models.

Figure 3-10 provides a view of a sample hybrid full stack deployment model. Here we have the same concepts we covered with full stack silo and pool deployment models sitting side-by-side.

Figure 3-10. A hybrid deployment model

So, why both models? What would motivate adopting this approach? Well, imagine you’ve built your SaaS business and you started out offering all customers a full stack pooled model (shown on the left here). Then, somewhere along the way, you ran into a customer that was uncomfortable running in a pooled model. They may have noisy neighbor concerns. They may be worried about some compliance issues. Now, you’re not necessarily going to cave to every customer that has this pushback. That would undermine much of what you’re trying to achieve as a SaaS business. Instead, you’re going to make efforts to help customers understand the security, isolation, and strategies you’ve adopted to address their needs. This is always part of the job of selling a SaaS solution. At the same time, there may be rare conditions when you might be open to offering a customer their own full stack siloed environment. This could be driven by a strategic opportunity or it may be that some customer is willing to write a large check that could justify offering a full stack silo.

In Figure 3-10, you can see how the hybrid full stack deployment model lets you create a blended approach to this problem. On the left-hand side of this diagram is an instance of a full stack pooled environment. This environment supports that bulk of your customers and we label these tenants, in this example, as belonging to your basic tier experience.

Now, for the tenants that demanded a more siloed experience, I have created a new premium tier that allows tenants to have a full stack silo environment. Here we have two full stack siloed tenants that are running their own stacks. The assumption here (for this example) is that these tenants are connected to a premium tier strategy that has a separate pricing model.

For this model to be viable, you must apply constraints to the number of tenants that are allowed to operate in a full stack silo model. If the ratio of siloed tenants becomes too high, this can undermine your entire SaaS experience.

Conclusion

This chapter focused on identifying the range of SaaS deployment models that architects must consider when designing a multi-tenant architecture. While some of these models have very different footprints, they all fit within the definition of what it means to be SaaS. This aligns with the fundamental mindset I outlined in Chapter 1, identifying SaaS as a business model that can be realized through multiple architecture models. Here, you should see that–even though I outlined multiple deployment models–they all shared the idea of having a single control plane that enables each environment and its tenant to be deployed, managed, operated, onboarded, and billed through a unified experience. Full stack silo, full stack pool, mixed mode–they all conform with the notion of having all tenants running the same version of a solution and being operated through a single pane of glass.

From looking at these deployment models, it should be clear that there are a number of factors that might push you toward one model or another. Legacy, domain, compliance, scale, cost efficiency, and a host of other business and technical parameters are used to find the deployment model (or combination of deployment models) that best align with the needs of your team and business. It’s important to note that the models I covered here represent the core themes while still allowing for the fact that you might adopt some variation of one of these models based on the needs of your organization. As you saw with the hybrid full stack model, it’s also possible that your tiering or other considerations might have you supporting multiple models based on the profile of your tenants.

Now that you have a better sense of these foundational models, we can start to dig into the more detailed aspects of building a multi-tenant SaaS solution. I’ll start covering the under-the-hood moving parts of the application and control planes, highlighting the services and code that is needed to bring these concepts to life. The first step in that process is to look at multi-tenant identity and onboarding. Identity and onboarding often represent the starting point of any SaaS architecture discussion. They lay the foundation for how we associate tenancy with users and how that tenancy flows through the moving parts of your multi-tenant architecture. As part of looking at identity, I’ll also explore tenant onboarding which is directly connected to this identity concept. As each new tenant is onboarded to a system, you must consider how that tenant will be configured and connected to its corresponding identity. Starting here will allow us to explore the path to a SaaS architecture from the outside in.

About the Author

Tod Golding is a cloud applications architect who has spent the last seven years immersed in cloud-optimized application design and architecture. As a global SaaS lead within AWS, Tod has been a SaaS technology thought leader, publishing and providing SaaS best practices guidance through a broad set of channels (speaking, writing, and working directly with a wide range of SaaS companies). Tod has over 20 years of experience as an architect and developer, including time at both startups and tech giants (AWS, eBay, Microsoft). In addition to speaking at technical conferences, Tod also authored Professional .NET Generics, was coauthor on another book, and was a columnist for Better Software magazine.

What is cloud computing?

The best way to understand the cloud is to take the electricity supply analogy. To get electricity in your house, you just flip the switch on. Electric bulbs lighten your home and other appliances. In this case, you only pay for your electricity use when you need them. When you switch off the electric appliances, you are not paying anything. Now, imagine if you need to power a couple of appliances, and for that, you have to set up an entire powerhouse. It will be costly, right? as it involves the cost of maintaining the turbine, generator, and building the whole infrastructure. Utility companies make your job easier by supplying the electricity quantity you need. They maintain the entire infrastructure to generate electricity. They could keep the cost down by distributing electricity to millions of houses which helped them benefit from mass utilization. Now let’s come to cloud computing; while consuming cloud resources, you pay for IT infrastructure such as computing and storage in the pay-as-you-go model. Here, public clouds like AWS do the heavy lifting to maintain IT infrastructure and provide you access over the internet under pay as you go, model. They are revolutionizing the IT infrastructure industry, where traditionally, you have to maintain your servers all by yourself on-premise to run your business, but now you can offload that to the public cloud and focus on your core business. For example, CapitalOne’s core business is banking and does not run a large data center. Before going deeper into cloud computing, let’s analyze some of the key characteristics of the public cloud.

Cloud elasticity

One important characteristic of the public cloud providers such as AWS is the ability to quickly and frictionlessly provision resources. These resources could be a single instance of a database or a thousand copies of the same server used to handle your web traffic. These servers can be provisioned within minutes.Contrast that with how performing the same operation may play out in a traditional on-premises environment. Let’s use an example. You need to set up a cluster of computers to host your latest service. Your next actions probably look something like this:

  1. You visit the data center and realize that the current capacity is insufficient to host this new service.
  2. You map out a new infrastructure architecture.
  3. You size the machines based on the expected load, adding a few more terabytes and a few gigabytes to ensure that you don’t overwhelm the service.
  4. You submit the architecture for approval to the appropriate parties.
  5. You wait. Most likely for months.

It may not be uncommon once you get the approvals to realize that the market opportunity for this service is now gone or that it has grown more. The capacity you initially planned will not suffice. It isn’t easy to overemphasize how important the ability to deliver a solution quickly is when you use cloud technologies to enable these solutions.Image what will happen if, after getting everything set up in the data center and after months of approvals, you told the business sponsor that you made a mistake. You ordered a 64 GB RAM server instead of a 128 GB, so you won’t have enough capacity to handle the expected load. Getting the right server will take a few more months? Also, the market is moving fast, and your user workload increases 5x by the time you get the server. Now it’s good news for business, but as you cannot scale your server so fast, the user experience will ultimately be compromised, and they will switch to other options. It is not necessarily a problem in a cloud environment because instead of needing months to provision your servers, they can be provisioned in minutes. Correcting the size of the server may be as simple as shutting down the server for a few minutes, changing a drop-down box value, and restarting the server again. Even you can go serverless and let the cloud handle the scaling for you while you focus on your business problems.Hopefully, the above example here drives our point home about the power of the cloud. The cloud exponentially improves time to market. And being able to deliver quickly may not just mean getting there first. It may be the difference between getting there first and not getting there. Another powerful characteristic of a cloud computing environment is the ability to quickly shut down resources and, significantly, not be charged for that resource while it is down. In our continuing on-premises example, if we shut down one of our servers. Do you think we can call the company that sold us the server and politely asks them to stop charging us because we shut the server down? That would be a very quick conversation. It would probably not be a delightful user experience, depending on how persistent we were. They will probably say, “You bought the server; you can do whatever you want with it, including using it as a paperweight.” Once the server is purchased, it is a sunk cost for the duration of the server’s useful life.In contrast, whenever we shut down a server in a cloud environment. The cloud provider can quickly detect that and put that server back into the pool of available servers for other cloud customers to use that newly unused capacity.

Cloud virtualization

Virtualization is running multiple virtual instances on top of a physical computer system using an abstract layer sitting on top of actual hardware. More commonly, virtualization refers to the practice of running multiple operating systems on a single computer at the same time. Applications running on virtual machines are oblivious that they are not running on a dedicated machine. These applications are unaware that they share resources with other applications on the same physical machine.A hypervisor is a computing layer that enables multiple operating systems to execute in the same physical compute resource. These operating systems running on top of these hypervisors are Virtual Machines (VMs) – a component that can emulate a complete computing environment using only software but as if it was running on bare metal. Hypervisors, also known as Virtual Machine Monitors (VMMs), manage these VMs while running side by side. A hypervisor creates a logical separation between VMs. It provides each of them with a slice of the available compute, memory, and storage resources.It allows VMs not to clash and interfere with each other. If one VM crashes and goes down, it will not make other VMs go down with it. Also, if there is an intrusion in one VM, it is fully isolated from the rest.

Definition of the cloud

Let’s now attempt to define cloud computing.The cloud computing model offers computing services such as compute, storage, databases, networking, software, machine learning, and analytics over the internet and on-demand. You generally only pay for the time and services you use. Most cloud providers can provide massive scalability for many of their services and make it easy to scale services up and down.As much as we tried to nail it down, this is still a pretty broad definition. For example, we specify that the cloud can offer software in our definition. That’s a pretty general term. Does the term software in our definition include the following?

  • Video Conferencing
  • Virtual desktops
  • Email services
  • Contact Center
  • Document Management

These are just a few examples of what may or may not be included as available services in a cloud environment. When it comes to AWS and other major cloud providers, The answer is yes. When AWS started, it only offered a few core services, such as compute (Amazon EC2) and basic storage (Amazon S3). As of 2022, AWS has continually expanded its services to support virtually any cloud workload. Currently, It has more than 200 fully featured services for compute, storage, databases, networking, analytics, machine learning, artificial intelligence (AI), Internet of Things (IoT), mobile, security, hybrid, virtual & augmented reality (VR and AR), media, application development, and deployment. As a fun fact, as of 2021, Amazon Elastic Cloud Compute (EC2) alone offers over 475 types of compute instances.For the individual examples given here, AWS offers the following:

  • Video conferencing – Amazon Chime
  • Virtual desktops – AWS Workspaces
  • Email services – Amazon WorkMail
  • Contact Center – Amazon Connect
  • Document Management – Amazon Workdocs

As we will see throughout the book, here is a sample of AWS’s offers many services. Additionally, since it was launched, AWS services and features have grown exponentially every year, as shown in the following figure:

 Figure 1.1 – AWS – number of featuresFigure 1.1 – AWS – number of features  

There is no doubt that the number of offerings will continue to grow at a similar rate for the foreseeable future. AWS is a cloud market leader as it has a lot of functionality. They are innovating faster, especially in new areas such as Machine Learning and Artificial Intelligence, the Internet of Things, Serverless Computing, Blockchain, and even quantum computing.You must have heard cloud terms more often in different contexts, including the public and private clouds. Let’s learn more about it.