Category Archive:The Full Stack Pool Model

The Mixed-Mode Deployment Model 2 – Multi-Tenant Deployment Models

September 16th, 2021 / Categories: AWS Certification Exam, Exams of Microsoft, Introducing the Silo and Pool Models, The Full Stack Pool Model / No Comments »

On the left-hand side of this image, we have our basic tier services. These services cover all the functionality that is needed for our SaaS environment. However, you’ll note that they are deployed in different silo/pool configurations. Service 1, for example, has siloed compute and pooled storage. Meanwhile, Service 2 has siloed compute and siloed storage. Services 3-6 are all pooled compute and pooled storage. The idea here is that I’ve looked across the needs of my pooled tenants and identified, on a service-by-service basis, which silo/pool strategy will best fit the needs of that service. The optimizations that have been introduced here were created as baseline strategies that were core to the experience of any tenant using the system.

Now, where tiers do come into play is when you look at what I’ve done with the premium tier tenants. Here, you’ll notice that Services 5 and 6 are deployed in the basic tier and they’re also deployed separately for a premium tier tenant. The thought was that, for these services, the business determined that offering these services in a dedicated model would represent value that could distinguish the experience of the system’s premium tier. So, for each premium tier tenant, we’ll create new deployments of Service 5 and 6 to support the tiering requirements of our tenants. In this particular example, Tenant 3 is a premium tier tenant that consumes a mix of the services on the left and these dedicated instances of Services 5 and 6 on the right.

Approaching your deployment model in this more granular fashion provides a much higher degree of flexibility to you as the architect and to the business. By supporting silo and pool models at all layers, you have the option to compose the right blend of experiences to meet the tenant, operational, and other factors that might emerge throughout the life of your solution. If you have a pooled microservice with performance issues that are creating noisy neighbor challenges, you could silo the compute and/or storage of the service to address this problem. If your business wants to offer some parts of your system in a dedicated model to enable new tiering strategies, you are better positioned to make this shift.

This mixed mode deployment model, in my opinion, often represents a compelling option for many multi-tenant builders. It allows them to move away from having to approach problems purely through the lens of full stack solutions that don’t always align with the needs of the business. Yes, there will always be solutions that use the full stack model. For some SaaS providers, this will be the only way to meet the demands of their market/customers. However, there are also cases where you can use the strengths of the mixed mode deployment model to address this need without moving everything into a full stack silo. If you can just move specific services into the silo and keep some lower profile services in the pool, that could still represent a solid win for the business.

The Pod Deployment Model – Multi-Tenant Deployment Models

July 15th, 2021 / Categories: AWS Certification Exam, Exams of Microsoft, Picking Technologies for Your Planes, The Full Stack Pool Model / No Comments »

The Pod Deployment Model

So far, I’ve mostly looked at deployment models through the lens of how you can represent the application of siloed and pooled concepts. We explored coarse- and fine-grained ways to apply the silo and pool model across your SaaS environment. To be complete, I also need to step out of the silo/pool focus and think about how an application might need to support a variation of deployment that might be shaped more by where it needs to land, how it deals with environmental constraints, and how it might need to morph to support the scale and reach of your SaaS business. This is where the pod deployment model comes into the picture.

When I talk about pods here, I’m talking about how you might group a collection of tenants into some unit of deployment. The idea here is that I may have some technical, operational, compliance, scale, or business motivation that pushes me toward a model where I put tenants into individual pods and these pods become a unit of deployment, management, and operation for my SaaS business. Figure 3-12 provides a conceptual view of a pod deployment.

Figure 3-12. A pod deployment model

In this pod deployment model, you’ll notice that we have the same centralized control plane on the left-hand side of this experience. Now, however, on the right-hand side, I have included individual pods that are used to represent self-contained environments that support the workload of one or more tenants. In this example, I have Tenants 1-3 in pod 1 and Tenants 4-6 in pod 2.

These separate pods bring a degree of complexity to a SaaS environment, requiring your control to build in the mechanisms to support this distribution model. How tenants are onboarded, for example, must consider which pod a given tenant will land in. Your management and operations must also become pod aware, providing insights into the health and activity of each pod.

There are a number of factors that could drive the adoption of a pod-based delivery model. Imagine, for example, having a full stack pooled model running in the cloud that, at a certain number of tenants, begins to exceed infrastructure limits of specific services. In this scenario, your only option might be to create separate cloud accounts that host different groups of tenants to work around these constraints. This could also be driven by a need for deploying a SaaS product into multiple geographies where the requirements of that geography or performance considerations could tip you toward a pod-based deployment model where different geographies might be running different pods.

Some teams may also use pods as an isolation strategy where there’s an effort to reduce cross-tenant impacts. This can be motivated by a need for greater protections from noisy neighbor conditions. Or, it might play a role in the security and availability story of a SaaS provider.

If you choose to adopt a pod model, you’ll want to consider how this will influence the agility of your business. Adopting a pod model means committing to absorbing the extra complexity and automation that allows you to support and manage pods without having any one-off mechanisms for individual pods. To scale successfully, the configuration and deployment of these pods must all be automated through your control plane. If some change is required to pods, that change is applied universally to all pods. This is the mirror of the mindset I outlined with full stack silo environments. The pod cannot be viewed as an opportunity to enable targeted customization for individual tenants.

One dynamic that comes with pods is this idea of placing tenants into pods and potentially viewing membership within a pod as something can be shifted during the life of a tenant. Some organizations may have distinct pod configurations that might be optimized around the profile of a tenant. So, if a tenant’s profile somehow changes and their sizing or consumption patterns aren’t aligned with those of a given pod, you could consider moving that tenant to another pod. However, this would come with some heavy lifting to get the entire footprint of the tenant transferred to another pod. Certainly this would not be a daily exercise, but is something that some SaaS teams support–especially those that have pods that are tuned to a specific experience.

While pods have a clear place in the deployment model discussion, it’s important not to see pods as a shortcut for dealing with multi-tenant challenges. Yes, the pod model can simplify some aspects of scale, deployment, and isolation. At the same time, pods also add complexity and inefficiencies that can undermine the broader value proposition of SaaS. You may not, for example, be able to maximize the alignment between tenant consumption and infrastructure resources in this model. Instead, you may end up with more instances of idle or overprovisioned resources distributed across the collection of pods that your system supports. Imagine an environment where you had 20 pods. This could have a significant impact on the overall infrastructure cost profile and margins of your SaaS business.

What is cloud computing? – Understanding AWS Cloud Principles and Key Characteristics

March 17th, 2021 / Categories: AWS Certification Exam, Exams of Microsoft, Full Stack Silo Considerations, Picking Technologies for Your Planes, The Full Stack Pool Model / No Comments »

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:

You visit the data center and realize that the current capacity is insufficient to host this new service.
You map out a new infrastructure architecture.
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.
You submit the architecture for approval to the appropriate parties.
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.

Private versus public clouds – Understanding AWS Cloud Principles and Key Characteristics

January 17th, 2021 / Categories: AWS Certification Exam, Exams of Microsoft, Introducing the Silo and Pool Models, Picking Technologies for Your Planes, The Full Stack Pool Model / No Comments »

Private versus public clouds

A private cloud is a service dedicated to a single customer—it is like your on-premise data center, which is accessible to one large enterprise. A private cloud has become a fancy name for a data center managed by a trusted third party. All the elasticity benefits wither away. This concept has gained momentum to ensure security. Initially, enterprises were skeptical about public cloud security, which is multi-tenant. But having your own infrastructure dimmish the value of the cloud as you have to pay for resources even if you are not running it. Let’s use an analogy to understand the private cloud further. The gig economy has great momentum. Everywhere you look, people are finding employment as contract workers. Uber drivers are setting up Airbnbs, and people are doing contract work for Upwork. One of the reasons contract work is getting more popular as it enables consumers to contract services that they may otherwise not be able to afford. Could you imagine how expensive it would be to have a private chauffeur? But with Uber or Lyft, you almost have a private chauffeur who can be at your beck and call within a few minutes of you summoning them.A similar economy of scale happens with a public cloud. You could have access to infrastructure and services that would cost millions of dollars if you bought them on your own. Instead, you can access the same resources for a small fraction of the cost.Even though AWS, Azure, GCP, and the other popular cloud providers are considered mostly public clouds. There are some actions you can take to make them more private. For example, AWS offers Amazon EC2 dedicated instances, which are EC2 instances that ensure that you will be the only user for a given physical server. Further, AWS offers AWS Outpost, where you can order server rack and host workload in your premise using the AWS control plane. Dedicated instance and Outpost costs are significantly higher than on-demand EC2 instances. On-demand instances ?? may be shared with other AWS users. As mentioned earlier in the chapter, you will never know the difference because of virtualization and hypervisor technology. One common use case for choosing dedicated instances is government regulations and compliance policies. That requires certain sensitive data to not be in the same physical server with other cloud users.Indeed private clouds are expensive to run and maintain. For that reason, many of the resources and services offered by the major cloud providers reside in public clouds. But just because you are using a private cloud does not mean that it cannot be set up insecurely and conversely. Suppose you are running your workloads and applications on a public cloud. You can use security best practices and sleep well at night knowing that you use state-of-the-art technologies to secure your sensitive data.Additionally, most major cloud providers’ clients use public cloud configurations, but there are a few exceptions even in this case. For example, the United States government intelligence agencies are a big AWS customer. As you can imagine, they have deep pockets and are not afraid to spend. In many cases with these government agencies, AWS will set up the AWS infrastructure and services on the agency’s premises. You can find out more about this here:https://aws.amazon.com/federal/us-intelligence-community/Now that we have gained a better understanding of cloud computing in general. Let’s get more granular and learn about how AWS does cloud computing.

What is cloud computing? 2 – Understanding AWS Cloud Principles and Key Characteristics

January 15th, 2021 / Categories: AWS Certification Exam, Exams of Microsoft, Full Stack Silo Considerations, Introducing the Silo and Pool Models, Picking Technologies for Your Planes, The Full Stack Pool Model / No Comments »

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 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.

Multi-tenant Architecture Fundamentals