6

Click here to load reader

SaaS & the Architectural Considerations for Migration

Embed Size (px)

DESCRIPTION

$32.8 billion - the projected global SaaS spending in 2016 (Gartner) SaaS is becoming a popular software distribution model. But incorporating SaaS into your business strategy and ensuring successful migration from an existing traditional on-premise model requires careful technical and design decisions. At Clarice Technologies, we have helped our clients successfully achieve this transition and wish to share some of this knowledge and experience through this White Paper.

Citation preview

Page 1: SaaS & the Architectural Considerations for Migration

SaaS & the Architectural Considerations for Migration

A Clarice White Paper

Clarice | Enabling Product Journeys to SaaS We, at Clarice, have partnered with many of our clients and helped them modify their product offering from a traditional on-premise model to a SaaS-based model. In the process, we have gathered all round experience in SaaS, and through this white paper, we wish to share some of this knowledge and experience, which will help you jump-start your SaaS initiative.

Here, we have outlined the key architectural elements of SaaS- Data Access, Data

SaaS Today SaaS (Software as a Service) is a well recognized, profitable business model in comparison to the traditional on-premise, license-based software offering.

However, organizations planning a transition to offer this service need to make careful technical and design decisions to ensure successful migration or to create a solid foundation for their service.

Store, Licensing, Scalability, Security, User Experience, and the best practices in each area.

This document will help you ask the right questions before you embark on your SaaS journey.

Gartner has projected

the SaaS market to grow

at a steady CAGR of 19.5% through 2016.

Global SaaS spending is projected

to be around $32.8 billion in 2016.

Page 2: SaaS & the Architectural Considerations for Migration

Challenges Converting an Existing Product to SaaSThere are certain factors/parameters which need to be considered while taking an existing product and converting it to a SaaS offering.

Building a SaaS Service Our work and the resulting experience in this domain has helped us identify five key design area’s and the related decisions required under each for building any SaaS application.

• How will multiple users use your service?

• Does your app need transactional storage?

• Can the schema be changed to allow use of non-transactional storage?

• Can the storage elements be split to store non-transactional storage in Cloud-ready databases?

• How can you assure your customers of keeping their data secure as they move it to the Cloud?

• How can you provide customers a copy of their data locally and prevent ‘vendor lock-in’?

• Is the service scalable? Can you support new users in the future?

• How can the service be designed to minimize running costs and reduce CPU Time/Storage if deployed to the Cloud?

• How can the service be designed so as to be intuitive and reduce support calls in the long term?

Multi-Tenancy

Data Store Design

Data Security Scalability of Service

UX Design

Factor

Data Access

Data Store

Tight coupling may exist between application and data, for example, the application directly accesses database and tables within.

New advances in scalable Cloud databases have many useful features. It will require a re-think of your data store design if you want to make use of these features.

Key Challenge Areas

Data Security In the on-premise case, the customers’ data is physically present with them and ‘owned’ by them. You need assure them of security and ownership of data when they move to a SaaS model.

Page 3: SaaS & the Architectural Considerations for Migration

Factor

Licensing

Scalability and Performance

User Experience

If an on-premise app architecture is extrapolated to the SaaS model, cost of components may be prohibitive. For example, if you require an MS SQL database, you might have to create a new one for every tenant, and bear the license cost for each.

Customers may require access to an older version of the application, or do not wish to upgrade. To cater to this, you need the ability to support multiple versions.

SaaS apps are built for self-service, and therefore the UX needs to be intuitive and pleasing.

Key Challenge Areas

RecommendationsBreak Tight Coupling

By introducing an abstraction (API) that is used to access data, you can break the tight couplingbetween application code and the data store. The resulting benefits are:

• The client application will become data store-agnostic.

• The API can serve third-party integrations.

• Introduce versioning capability for graceful backward compatibility.

BEFORE

AFTER

DB App

AppDB API

Page 4: SaaS & the Architectural Considerations for Migration

Data Store

SaaS applications need to work in a multi-tenant environment, and the data store should support this functionality. Build a multi-tenant data store instead of many single-tenant ones, as it is easier to maintain, due to the lesser number of databases/backups and tuning requirements.

Since multiple tenants can share the same infrastructure, the running costs are shared

among them leading to economic benefits for each.

You could opt for more recent (NoSQL) databases that scale automatically. Features like data backup, resilience, High Availability, Disaster Recovery are built into newer databases like MongoDB or Cassandra.

Lesser Maintenance and Licenses in a Multi-tenant Environment

TENANTS

Application

Database Database

Maintenance, Licenses

Database

Application Application

Maintenance, Licenses

Database

Application

TENANTS

Licensing A SaaS application should be designed to scale-out. In case of horizontal scaling, as the application scales out, it is possible that the components that constitute the application will need numerous instances (and therefore new licenses.) Licensing cost of individual components could quickly add up if not considered at design time. Consider the following:

• In case you are using a component like MS SQL which needs licensing, you will be able to lower costs if you get an Enterprise

license, which is shared between different tenants, rather than dozens of smaller licenses per tenant.

• Explore open source software (OSS) options for software infrastructure, frameworks, components, or tools to build your service that are free, or those that charge nominally.

Page 5: SaaS & the Architectural Considerations for Migration

Data Security

Customers are moving their data from their on-premise data centers to a Cloud storage. Security of this data will be a concern for them. Customers will also want ownership of data. They also need to be assured that they won’t face a ‘vendor lock-in’.

Data in transit and at rest should be encrypted, preferably with an encryption known only to the customer.

Scalability and Performance Scalability and performance of the SaaS application should be your foremost design goals. Design needs to consider various things such as type and nature of data access.

When designing the application for scaling out, keep the following guidelines in mind:

• Individual instances of the application should be stateless to allow for load-balancing.

• Session information should be shared or encoded in the URLs.

• User authentication should be a separate service that can also perform token-based authentication.

• For the data store consider new cloud storage options with databases like MongoDB and Cassandra, which are very scalable.

Load Balancing

As discussed earlier, the architecture should allow multi-tenancy and scaling out. New instances of the software can be added transparently to a pool to dynamically support more load. A Load Balancer should be introduced to maximize the resource use (CPU, storage, etc.)

User Request

Web Web Web Web Web Web

LOAD BALANCER

DATABASECLUSTER

DB DB DB

Page 6: SaaS & the Architectural Considerations for Migration

Data Isolation In multi-tenant architectures, plan the data storage to ensure isolation of tenant’s data from each other.

Data Migration

How will your customers migrate data in legacy, disparate systems to the SaaS storage? Process legacy data to fit into the new design with a proper data migration strategy.You need to build ETL (Extract, Transform, and Load) tools that can migrate existing data to the cloud.

User Experience for SaaS Applications

Customers need a straight, simple way to sign up and start using the service, without any administrator help or phone calls. Since SaaS applications reach out to a larger audience,

the following features are mandatory:

• A self-service sign-up process

• Management of user profiles

• Subscription and billing

• Monitoring and reporting anomalies in application behaviour

• Different policies built in for different user groups

• Simple administration

Clarice Technologies specializes in providing User Experience Design and cutting-edge technology development services under one umbrella to product organization. We take pride in working with companies who consider User Experience key to their competitive stategy.

Summary

The economic and strategic benefits of the SaaS model are well established. When migrating your existing software to SaaS, a new architecture mindset is needed, since SaaS is a service consumed over the Internet and works very differently from an on-premise model.