Migrating Applications to SaaS: A Minimally Invasive Approach

The software as a service (SaaS) delivery model is very compelling to many organizations. Agility, market responsiveness, shared infrastructure costs—they all represent an opportunity for businesses to transform their approach to how they build, operate, and monetize their products. The reality, however, is that these same organizations often have a significant investment in their existing single-tenant offerings. While the appeal of SaaS is intriguing, it’s often unrealistic to expect that teams can completely rebuild their applications and instantly adopt all of the tenets and principles typically associated with multi-tenant environments.

The challenge, then, is for organizations to find creative ways to incrementally move their solutions to a SaaS model without major disruptions. While the benefits of SaaS may be inviting, it’s important to make the move to SaaS with care and forethought. Ultimately, you want to emerge from this transformation with a product that inherits the best traits of SaaS and becomes an enabler for the business. A simple lift and shift or some flavor of pseudo-SaaS is likely to undermine your long-term goals.

Any discussion of SaaS migration must consider the full scope of what it means to build, deliver, support, and sell in a SaaS model. This means our migration discussion must examine the influence of SaaS on the technical, business, and operational dimensions of an application’s transformation. Migration must be continually looking at all the moving parts of the SaaS landscape to determine which series of moves will allow you to ensure that your path forward embraces the full value of SaaS.

Given this broad scope, we’ll cover this material in two blog posts. This first blog post will look at the minimally invasive models for migration. The emphasis here will be on identifying migration strategies that attempt to limit any changes to the fundamental design of your solution. This is a very common strategy for many organizations that are anxious to reap the rewards of AWS without investing, initially at least, in any significant rewrite or restructuring of their current solution. In the next blog post, we’ll look at a less constricted model where we have the freedom to completely rethink an application’s design and architecture.

In the sections that follow, we’ll review the merits of each minimally invasive migration strategy. We’ll also look at how the management and operational aspects of the business need to change to support migration. Overall, these two blog posts should provide you with insights into some of the patterns that might fit the migration needs of your SaaS applications.

How Multi-Tenant Are You?

Before we dig into migration strategies, it’s important to get a firm footing for the discussion of multi-tenancy. In the eyes of most developers, multi-tenancy equates to having all tenants running in a single infrastructure footprint. In fact, many of the agility values that are associated with SaaS rely on this shared model. Cost, deployments, management, and competitive agility—they all benefit greatly from the merits of a shared infrastructure.

The problem is that this view of multi-tenancy isn’t practical for all businesses or for all domains. There are actually a number of different models that are be used to deliver successful SaaS solutions. In fact, for some, the move to SaaS may simply be about shifting management responsibilities to a provider. So, while we’d love to have some ultimate, universal target for our migration effort, it’s also fair to assume that the target end state of multi-tenancy is likely to vary. As a result, our migration strategies must also vary.

Given this fluid definition of multi-tenancy, our review of migration strategies must embrace multiple flavors of SaaS multi-tenancy. The migration process must allow for SaaS models where some or all of a tenant’s infrastructure may be running in isolation. To the providers and their tenants, these solutions are no less SaaS than any shared infrastructure solution.

The trap you want to avoid, however, is using isolation as a migration crutch. If your tenants and your business ultimately benefit from a shared infrastructure model, then that should be your end goal. Don’t allow the convenience of isolation to undermine your ability to migrate toward that goal.

Building a Foundation

Successful migrations, no matter how complex, rely on adopting an incremental mindset where you attempt to carve out slices of your system and migrate them piece-by-piece to a new model. By approaching this incrementally, you’re given a natural opportunity to identify and introduce the frameworks that will be essential to establishing a foundation that will support your adoption of SaaS technical and operational value systems. Logging, tenant configuration, service configuration, data access, metering—these are all areas where you are likely to need to introduce libraries that abstract away your policies and your tenant awareness.

It’s important to note that this isn’t about taking months to build tools and frameworks. It’s simply about realizing that these foundational concepts need to emerge and be part of your thought process as you deliver the first pieces of your system in your new model.

The Starting Point

Clearly, there are far too many flavors of application design to propose a common starting point. At the same time, there are definitely patterns of architecture that occur very frequently. Frameworks, tools, and general guidance have led many developers down the path of n-tier development, and, as a result, a great number of applications conform to some flavor of the following architecture.

With this architecture, we essentially have a web tier that is used to manage and deliver the assets of your application. This tier is fronted by a load balancer that distributes the traffic to web servers. The business logic of the application resides in the application tier that accesses your application’s database (often through some data access layer).

Providers will either host or offer an on-premises solution where this architecture is replicated and customized based on the needs of each customer. These environments tend to function in complete isolation and may often be running different application versions. Each installation assumes that it is addressing the needs of a single tenant, and nowhere in the design or architecture is there any notion of multi-tenancy.

You’ll also notice that the units of scale in this model are rather coarse-grained. You have web servers and application servers. If some subset of functionality on an application server is causing a bottleneck, your only way to address it is to add more application servers. You can’t really match the scale and profile of our compute resources (instances) with the more granular elements of our application’s functionality.

While there are variants of this architectural model, the fundamentals are shared by many existing solutions. You might see more the application tier separated into families of services that target specific business functions (batch process, caching, and so on). You might see a formal data access layer introduced. Even with those nuances, the basic model and approach remains mostly unchanged.

Now, if you’ve already made the move to a more decomposed microservice architecture, your migration path to SaaS multi-tenancy is more straightforward. Discussion of that migration model is outside the scope of this blog post.

Minimally Invasive Migration Themes

Given the architecture described above, the real question is how to begin to migrate environments of this nature to a SaaS model without fundamentally changing the design or architecture of our existing application. How do we begin to introduce multi-tenancy without requiring a rewrite of the entire solution? How do we address deployment automation and other SaaS agility principles as part of our migration effort? These are the challenges that confront organizations as they try to piece together their migration roadmaps.

While there are certainly multiple ways to attack this problem, some patterns are more prevalent than others. The list of migration models we’ll explore in this post includes:

• Silo Migration Model – introduces separate infrastructure for each tenant, fronting the experience with a single on-boarding and authentication experience
• Layered Migration Model – layers of an application are incrementally migrated to a multi-tenant model
• Data Migration Model – storage models are migrated to a multi-tenant model while the rest of the application remains in a siloed tenant infrastructure

The following sections will examine each of the minimally invasive migration themes and explore some of the key considerations that accompany each model. It is also important to note that these solutions are not mutually exclusive.

Silo Migration Model

For many organizations, the silo model represents the most natural and appealing way to tackle migration. The idea behind the silo model is the acknowledgment that a shared infrastructure model might be too much to bite off at first. The diagram that follows provides a conceptual view of what a silo model might look like on top of AWS.

As you can see, this model preserves most of the core concepts (database, application, and web tiers) from the original architecture described earlier. The silo model creates a separate infrastructure stack for each tenant. To the extent possible, migrations of this type will try to limit changes to the existing design and simply leverage AWS services and constructs where they make the most sense. For example, the web and application tiers of the architecture will get deployed into Auto Scaling groups that span multiple Availability Zones. While each tenant will scale independently, you can still apply elasticity to the siloed infrastructure and dynamically scale the number of web and application servers based on tenant loads. For some applications, the Multi-AZ model will also add a dimension of availability and durability that may not have been previously achievable.

Silo migrations often include a move to one of the AWS storage services. If, for example, you are running tenants on a SQL Server database, you’ll probably consider using Amazon Relational Database Service (Amazon RDS) to support your storage needs. This will allow you to push more operational and availability responsibilities over to AWS and allow your operations team to take advantage of the various options RDS offers for optimizing scale and availability.

The silo model does introduce some new twists when it comes to onboarding new tenants. Ideally, even in a siloed environment, you’d still like to make onboarding as frictionless as possible. This means presenting your tenants with a UI and sign-up process that mimics the same model we see in other SaaS environments, with fully automated provisioning of new tenants.

Moving to automated provisioning and surrounding your tenant infrastructure with tooling will be the focus of your initial migration effort. The investment you make here represents an opportunity to move in a more agile direction, promoting the centralization and automation of any unique tenant configuration needs. The more you can bite off here, the better positioned you’ll be to continually advance your design and architecture.

Fortunately, the automation of this lifecycle is right at the heart of the DevOps tooling that’s supported by AWS and its ecosystem. These tools will equip you with all the building blocks you’ll need to construct a robust, continuous delivery pipeline that will drive the repeatability and stability of your system.

Layered Migration Model

With the layered migration model, the emphasis is on finding opportunities to move layers of your solution to multi-tenancy.  The key to this approach is carving out layers that can incrementally move toward a shared multi-tenant model while still allowing parts of the solution to retain their single-tenant design.

The following diagram provides one example how you might begin to migrate a layer or tier of your application. In this model, you’ll notice the same web and application tiers as in your single tenant model. However, here the web tier is a shared, multi-tenant tier that has been implemented with tenant context.

While the web tier is shared in this diagram, you’ll also notice that each tenant has its own distinct application tier. The web tiers map their traffic to the appropriate tenant’s application tier based on their tenant context.

This model’s appeal is that it allows us to bite off more shared concepts without tackling the entire multi-tenant problem. In fact, the layer that was chosen did not have to be the application tier. You can pick any layer in your environment and migrate it to a multi-tenant model. Then, as you see fit, slowly cut over the remaining layers.

Like the silo and the data migration model, the layered model relies on a parallel migration to automated provisioning. The key difference here is that the scope of what must be provisioned now changes. The web tier can remain somewhat constant while new application tiers will be required for each new tenant deployment.

Data Migration Model

The move to multi-tenant representations of data can be one of the more challenging aspects of adopting SaaS. Application code is often tightly intertwined with the structure and technology that is used to store the data. Despite this coupling, the data layer also represents a very clear boundary in your architecture that can be a natural target for migration.

In many respects, migration to multi-tenant data is simply another variation of the layered migration model described above. However, this migration model tends to feel more like a bottom-up strategy, where you first resolve the challenges of multi-tenant data before moving up the stack into the details of the application design.

Migration of your data is made much easier if your application has already introduced a data access layer. This layer typically abstracts away the details, and limits binding to an API or a storage technology. If this data layer exists, you’ll be in a much better position to gracefully migrate your data to a multi-tenant model. The goal here would be to limit the impact on clients of the data access layer while swapping out the underlying data access implementation with something that includes tenant awareness and partitioning.

You might also use this time to reevaluate your application’s storage technologies. You might, for example, consider a move from a relational model to NoSQL. However, a move of this nature is often viewed as too invasive to tackle in the early stages of migration. Later, if you decide to decompose your application into smaller services, you’ll be in a better position to select storage models that align with the needs of each service.

Whichever path you select, AWS has a rich set of storage options you can choose from. If you’re migrating from a relational model, for example, you can pick from any of the relational solutions that are part of Amazon RDS (Aurora, MySQL, SQL Server, and so on). Amazon DynamoDB (NoSQL), Amazon Redshift (data warehousing), and Amazon ElastiCache could also be included in your storage migration strategy. As part of opting into AWS storage solutions, you may also consider using the AWS Database Migration Service and the AWS Schema Conversion Tool to manage the migration of your existing data.

Changing the representation of your data also means migrating your existing data to the new multi-tenant representation. A common practice here is to move tenants over one by one to reduce risk and make the process more manageable. You can also use this approach to get real-time insights into how your system is performing as each tenant is moved into the new structure. This will give you a chance to tune and refine your storage configuration before all the tenants have been migrated to the new environment.

This staged data migration can also be aligned with the migration of tenants from an on-premises solution into AWS. The conversion of tenant data is applied as each tenant is provisioned and deployed in the AWS environment.

Migrating to an AWS storage service also creates an opportunity to fold in AWS Identity and Access Management (IAM) and Amazon CloudWatch metrics. With IAM, you can control access to your storage and further ensure that tenants are not allowed to access any data outside their realm. CloudWatch can be used to surface metrics about your storage activity and provide more data points that enhance your management and monitoring experience.

Management and Monitoring Migration

Management and monitoring apply universally to each migration model we outlined. Since we’re discussing the migration of an existing solution, it’s likely that you’ll already have some level of management and monitoring tooling in place. For example, most solutions will already have mechanisms to aggregate and analyze log information along with some tooling to enable a view of the system’s health. Still, as part of your migration, you’ll want to think about how these tools might need to evolve as you begin to adopt a more SaaS-focused value system.

Even though some aspects of your solutions will remain single-tenant, you should consider building out a management and monitoring experience that aggregates your tenant activity into a single, consolidated view of system health. SaaS agility relies on having detailed health information at your fingertips that allows you to proactively capture and respond to health events, which, in some cases, may span multiple tenants. This experience should also provide you with a view of a single tenant’s activity and health. This tenant-specific view is essential to supporting tenants who may be experiencing functional or performance issues.

By attacking management and monitoring in the initial phases of your migration, you’ll put yourself in a much better position to support more multi-tenant concepts as your environment evolves. This early investment will also enable you to incorporate more AWS metrics data into your management and monitoring view. You’ll certainly want to be pulling in metrics and events from CloudWatch to assess the state of your environments. You might also introduce custom CloudWatch metrics to surface details that are unique to your application.

Overall, your migration to SaaS represents an opportunity to reevaluate your management and monitoring strategy. You should use this moment to look beyond your current tooling and determine which combination of solutions best aligns with the SaaS value system you’re adopting.

AWS and partners in the AWS Partner Network (APN) ecosystem have solutions that can be used to address many of your monitoring needs. These solutions enable you to construct the various views of activity that are often essential to supporting complex multi-tenant environments.

Operations Migration

So much of the migration effort is focused on the application design and architecture that we often overlook the operational aspects of migration. When moving a solution to AWS—in any SaaS migration model—you should be looking at how you can streamline and automate your operations footprint.

AWS and its ecosystem provide you with a rich set of tools that you can use to construct and enhance the operational profile of your SaaS offering. Adoption of these tools and the principles that accompany them should be a key element of any SaaS migration effort. If your organization has not already embraced DevOps, your SaaS migration represents a prime opportunity to launch your technical and cultural transformation to a DevOps mindset. In many respects, the move to DevOps will be at the core of your migration to agility and to a new SaaS culture that supports continual and rapid evolution of your product.

Putting this automation into place early will help you build a foundation that simplifies the evolution of your application’s design and architecture. Once the automation model is established, it becomes simpler to apply these mechanisms to new areas of the system.

The initial investment in DevOps and automation can be high for some organizations, but the concepts are too fundamental to SaaS to postpone. Making DevOps a priority also surfaces areas where teams may require new organizational structures and relationships.

The AWS stack includes a number of tools that can help with DevOps migration. AWS CloudFormation, AWS Elastic Beanstalk, and AWS OpsWorks can be used to provision infrastructure and to automate deployments. AWS also provides tools such as AWS CodeCommit, AWS CodePipeline, and AWS CodeDeploy to support continuous deployment orchestration. These solutions are often used in connection with DevOps automation tools that have been created by the AWS ecosystem. You might, for example, use AWS CloudFormation to automate the configuration and provisioning of your infrastructure. A combination of AWS CodePipeline and AWS CodeDeploy could be used to construct your continuous delivery solution. Take a look at the AWS DevOps page to learn more about DevOps on AWS.

It’s important to note that the migration patterns outlined above often add an additional layer of configuration to your SaaS environment. Wherever you have isolated tenant infrastructure you may also have unique configurations for those tenants. These configuration variations need to be captured, versioned, and stored in a repository that can be referenced by your DevOps lifecycle. This is essential to ensuring that your SaaS environment is deployed with a repeatable and reliable process.

Metering Instrumentation

Metering should never be an afterthought for SaaS environments. Metering data is at the heart of understanding how your tenants consume infrastructure resources. This data often feeds a number of different downstream decisions that can affect everything from optimization to product tiering strategies.

The migration model you select will likely influence your metering options. In fully siloed environments, you have a clear boundary for determining which resources are associated with a given tenant. However, where there is shared infrastructure, you’ll have to give more thought to how you might meter tenant consumption.

AWS provides different models that you can use to supplement your metering strategy. You can use everything from linked accounts to tagging to grouping and identifying your resources. Establishing a metering strategy early in your migration effort will help you determine how your metering model may need to evolve to capture the data that will be useful to your business.

Rethinking Your Infrastructure Profile

Migration—no matter which flavor—represents a chance to reexamine the infrastructure profile of your application. The move to SaaS and the availability of new AWS infrastructure constructs provide you with a natural opportunity to bring new dimensions of scale and availability to your solution. It may also enable new capabilities that were previously constrained by your prior environment.

There are many new technical and operational options to consider as you move to AWS. The array of compute, storage, scale, and availability models supported by AWS can open up new realms of design and architecture for your solution. The move to AWS often introduces new dials and nobs that you can use to optimize the performance and cost profile of your solution.

Operationally, organizations will often use this migration as an opportunity to shift more of the management, scale, and availability burden to AWS, thereby freeing up resources to focus more of time and energy on their own SaaS applications.

The key takeaway here is that migration is about transforming your business. It’s about starting your path toward SaaS in a way that seeds the environment with technical, operational, and cultural changes that will establish a solid SaaS foundation and will align your technology and mindset with your longer-term agility goals.

In this blog post, the focus was entirely on finding ways to migrate applications to SaaS without fundamentally changing their design or architecture. Part two of the series explores scenarios where migration is used as an opportunity to reconsider the fundamentals of application’s architecture and design. This approach opens the door to reshaping all aspects of your application’s design and aligning it with new models for enhancing the scale, availability, and agility footprint of your SaaS solution.