Learn how Cloud Computing is changing applications deployment. See how software deployment is moving away from traditional on-premise installable, license based software to consuming software applications as services, on a subscription based models. Learn about different SaaS application architectures that can help you convert your on-premise single tenant installable application to an online multi-tenant application. Find out how to avoid huge capital expenditures upfront and do away with managing applications and dealing with software licenses, there are obvious benefits of running a SaaS business on Cloud for ISVs as well.

1. Productive
Expansion with
SaaS offerings
on Amazon Web
Services
1
Webinar
12th March 2015
11:30 to 12:30 AM PST

2. Introduced By:
Prachi Bhatnagar
Digital Marketing Executive
Presented By:
Gurmeet Singh
Founder & Chief Marketing Officer
2

3. Let’s Talk About
Who
We Are

4. INTRODUCING OURSELVES
Fastest growing AWS Cloud
Partners with Managed Service
Competency in India & APAC
High Customer Retention. 70%
Revenues from Repeat Business
Vast Experience in Large
Scale Complex Cloud
Migration, Big Data &
DWH on AWS
Unmatched AWS Skills 90+
Accreditations & Certifications
4

5. Agenda
What is SaaS? SaaS
Architectures Case Study
How AWS can
help build
a SaaS Product
55

6. What is Software as a Service?
SaaS
6

7. Software as a Service
The software and data
associated with the
software is hosted on the
Cloud.
7
Software Delivery
Model
Software as a Service
or SaaS is a software
delivery model in which
software is delivered
over the internet, as a
service.
Hosted on Cloud

8. Characteristics of SaaS
8
Network Access
Accessible over the
internet
Multi-tenant
Architecture
Common
Infrastructure &
Code base
Ease of
Customization
Configurable
Applications

9. Developing a SaaS Application
Cloud | SaaS
9

10. Essentials for SaaS Applications
10
Multi-tenancy
Self Service &
Personalization
Integration
Operational
Performance
Security &
Compliance

11. Multi-tenancy is the key to successful SaaS
Applications
11
By definition, subscription for
the application over the internet
is sufficient enough for an
application to be defined as
SaaS, but this does not
differentiate it from any ASP
application.
To differentiate a SaaS application
in practical terms it must be a
multi-tenant application.
Multi-tenancy helps leverage
the efficiencies of underlying
infrastructure and application
code, by sharing it across
multiple customers.
Sharing of resources enables
efficient usage of the resources
and reduces costs of
operations.

12. Multi-Tenancy
Cloud | SaaS
12

13. Levels of Multi-Tenancy
The sharing of resources for multi-tenancy happens at
various layers of the system architecture.
These layers can be broadly identified as-
13
Infrastructure Layer Database Layer Application Layer

14. Levels of Multi-Tenancy
There are four types of multi-tenancy models which can be
used to architect your SaaS application-
14
Isolated Tenancy Infrastructure
Tenancy
Application
Tenancy
Shared Tenancy

15. Isolated Tenancy
Cloud | SaaS
15

16. Isolated Tenancy
This is the basic level of tenancy very none
of the layer is shared among the tenants.
16
1
2
Each tenant has their own infrastructure,
database and application. The
infrastructure is physically isolated.

17. Isolated Tenancy
17
Infrastructure
Database
Application
Tenant
Infrastructure
Database
Application
Tenant
Infrastructure
Database
Application
Tenant

18. Infrastructure Tenancy
Cloud | SaaS
18

19. Infrastructure Tenancy
In Infrastructure tenancy the underlying
infrastructure for the application is shared
across tenants.
19
1
2 The database and application layers are
separate for the tenants.

20. Infrastructure Tenancy
20
Infrastructure
Database
Application
Tenant
Database
Application
Tenant
Database
Application
Tenant

21. Application Tenancy
Cloud | SaaS
21

22. Application Tenancy
Application tenancy model will have the
application code and infrastructure
shared by each tenant.
22
1
2 The database is still separate for
each tenant.

23. Application Tenancy
23
Infrastructure
Application
Database
Tenant
Database
Tenant
Database
Tenant

24. Shared Tenancy
Cloud | SaaS
24

25. Shared Tenancy
Infrastructure, database and application
are shared among all the tenants.
25
1
2 Each unique tenant in the database will
be identified by a unique tenant id.

26. Shared Tenancy
26
Infrastructure
Database
Application
Tenant Tenant Tenant

27. Design Consideration for
Multi-Tenancy
Cloud | SaaS
27

28. Design Considerations for Multi-Tenancy
28
Infrastructure
Completely
isolated hosts or
shared (CPU,
RAM,
Communications)
Database
Separate DB
Schema or
Shared Tables
Application
Multiple code
bases or Single
code base
Tenancy
Identifying
Tenants

29. Isolated
Infrastructure Physical Host Per Tenant
Database  Separate DB for
each tenant.
 Physical Separation
of DB.
 Tenant aware
naming
conventionto
resolve naming
conflicts
Application  Multiple code bases
 Can have different
versions
 Tenant aware
naming convention
to resolve naming
conflicts
Tenancy  Physical isolation
 Separate URLs and
path names

30. Infrastructure
Infrastructure Virtual Host per tenant
Database  Separate DB for each
tenant.
 Physical Separation
of DB.
 Tenant aware naming
conventionto resolve
naming conflicts
Application  Multiple code base
 Can have different
versions
 Tenant aware naming
convention to
resolve naming
conflicts
Tenancy  Physical isolation
 Separate URLs and
path names

31. Application
Infrastructure Everything is shared
(CPU, RAM, Web
Servers,
Communication)
Database  Isolated by tenant.
 Tables do not need
tenant id
 Tenant access
through DB naming
model
Application  Single code base
 Separate tenant ids
provide multi-
tenancy
Tenancy  Separate Tenant id
 Isolated DBs

32. Shared
Infrastructure Everything is shared
(CPU, RAM, Web
Servers,
Communication)
Database  Single Instance
 Table Includes
Tenant Id for
separation of
tenant details
Application  Single code base
 Separate tenant ids
provide multi-
tenancy
Tenancy  Separate Tenant id
 Isolated DBs

33. Isolated Infrastructure Application Shared
Infrastructure Physical Host Per Tenant Virtual Host per tenant Everything is shared
(CPU, RAM, Web
Servers,
Communication)
Everything is shared
(CPU, RAM, Web
Servers,
Communication)
Database  Separate DB for
each tenant.
 Physical Separation
of DB.
 Tenant aware
naming
conventionto
resolve naming
conflicts
 Separate DB for each
tenant.
 Physical Separation
of DB.
 Tenant aware naming
conventionto resolve
naming conflicts
 Isolated by tenant.
 Tables do not need
tenant id
 Tenant access
through DB naming
model
 Single Instance
 Table Includes
Tenant Id for
separation of
tenant details
Application  Multiple code bases
 Can have different
versions
 Tenant aware
naming convention
to resolve naming
conflicts
 Multiple code base
 Can have different
versions
 Tenant aware naming
convention to
resolve naming
conflicts
 Single code base
 Separate tenant ids
provide multi-
tenancy
 Single code base
 Separate tenant ids
provide multi-
tenancy
Tenancy  Physical isolation
 Separate URLs and
path names
 Physical isolation
 Separate URLs and
path names
 Separate Tenant id
 Isolated DBs
 Separate Tenant id
 Isolated DBs

34. Security Considerations
Cloud | SaaS
35

35. Security Considerations
Restricted APIs
Security
patterns to
keep in mind
Trusted Database
Connections
Access
Control Lists
Tenant Data
Encryption
36

36. Application Stability
Cloud | SaaS
37

37. Scalability Considerations - Application Scalability
38
Design Stateless Applications
Statelessness means that each transaction can be handled
by one instance as well as any other.
Pool resources like threads, networks & database
connections
Maximize the resource usage and enable predictable
resource usage
Asynchronous I/O
Perform other tasks while it waits for input and output to
complete

38. Database Stability
Cloud | SaaS
39

39. Scalability Considerations – Database Scalability
40
Database size will increase with addition of new
users and increasing transactions.
Increase in data will impact the database
performance with higher querying and transaction
times
Results in poor user experience.

40. Scalability Considerations – Database Scalability
Optimize Database Performance by:
41
Data Partitioning - Partition the data into smaller segregated chunks
to improve querying and transactional efficiencies.
Read Only Copies - Keep read only copies of databases. Redirect the
reporting and query requests to these read only databases to balance
the load on the transactional database.

41. Monitoring
Cloud | SaaS
42

42. Monitoring
43
To be competitive in the SaaS market, stability and availability of the
application play an important role
Continuous monitoring of the application and underlying infrastructure
is critical to success
Use the right set of monitoring tools which allow automation

43. Case Study
Cloud | SaaS
44

44. Case Study
A Leading e-Book Software Provider
45
Business Case
1
2 Provides on-premise e-book software to large publishers
Huge initial success, but the growth slowed down after a few years3

45. Case Study
46
Limited large book publishers to sell to
To identify new revenue channels & stay competitive
Challenge
1
2

46. Case Study
Support for 500,000 concurrent users, tested by creating virtual load for
500,000 users
47
Solution
Sales model turned upside down – Instead of a US$250,000 license cost for
one implementation, now a subscription fee of US$1000 per year
Convert the existing software to a SaaS application
Instead of selling the software to a small number of large publishers, sell it
to large number of individual and institutional publishers
1
2
3
4
5
6
Re-engineering of the application
Deployment of multi-tenant scalable infrastructure on AWS

47. Using Amazon Web Services to
build your SaaS Platform
48

48. AWS Provides Broad and Deep Services to
Support any Cloud Workload
Application Services
AWS Global Infrastructure
Networking
Deployment & Administration
StorageCompute StorageCompute Database
49

49. Amazon
RDS
Auto
Scaling
Elastic
Beanstalk
CloudFr
ont
ElastiCac
he
Some AWS technologies to help build your
SaaS Platform:
Amazon
EC2
ElastiCac
he
AWS
Cloudwatch
50

50. Amazon Elastic Compute
Cloud – EC2
Amazon Elastic Compute Cloud (Amazon EC2)
is a web service that provides resizable
compute capacity in the cloud.
51

51. Self
Hosti
ng Waste
Customer
Dissatisfaction
Actual
demand
Predicted
Demand
Rigid Elastic
Actual
demand
AWS
You Don’t Need to Guess
Capacity
52

52. Amazon
RDS
Amazon Relational Database Service
(RDS)
RDS makes it easy to set
up, operate, and scale a
relational database in the
cloud
53

53. AWS brings the ability to scale
your platform elastically as
your business grows.
54

54. Use Auto Scaling
55

55. Auto Scaling
56

56. Elastic Beanstalk
Java PHP Pyth
on
Ruby .NET Node
.js
Docker
AWS Elastic Beanstalk is an easy-to-use service for
deploying and scaling web applications.
57

57. Offload your architecture
• The more you can offload, the less
infrastructure you need to maintain, scale,
and pay for
• Two easy ways to offload:
– Use Amazon CloudFront CDN
– Introduce Database caching
58

58. Offload popular traffic to Amazon
S3, CloudFront
59

59. Offload databases through caching
60

60. Amazon Cloud Watch Metrics
All instances come with
CloudWatch metrics enabled
and configured by default
61

61. Architected for Enterprise Security requirement
Certifications and accreditations for
workloads that matter
AWS CloudTrail - AWS API call
logging for governance & compliance
Stores data in S3, or
archive to Glacier
Log and review user
activity
MTCS Tier 3
Certification
62

62. 63
SaaS Roadmap
To define the SaaS
roadmap for your
Product, talk to us.
Global Audience
Give your Product a
global audience by
converting them to
SaaS.

63. Thank You for Attending
64
Any Questions?
Contact us at: info@blazeclan.com