10. independence
privacy
optimal Scalability
Cost effective
Inefficient for small tenants
Moderate Complexity
Database Server
App Server
Tenant 1 Tenant 2
Shared
App2App1
Data Isolation
11. Least complex
Most Cost effective
Lack of independence
performance
scalability
Data segregation
App Server
Shared
Database Server
Tenant 1
Tenant 2
App 2App 1
16. Right tool for the right job
• Physical characteristics
• Performance characteristics
• Volatility
• Volume
• Transaction boundaries
• Retention period
• Regulatory requirements
17. When to use RDbMS
OLTP
Table based
Referential Integrity
ACID Transactions
Company Employees
18. When to use Nosql
Key Value Store
Best for content caching, Fast lookups
Redis, MemcacheDB
Column Store
Best for huge data volumes, Fast lookups, Distributed data
Cassandra, Hbase
Great for static, historical data
Document Databases
Best for versioning various documents and formats
CouchDB, Mongo
Graph Databases
Best for complex relationships, social networks
Neo, Infogrid
33. Disaster recovery
RTO (Recovery Time Objective)
“Time to be back up & running”
RPO (Recovery Point Objective)
“Maximum time in which data is lost”
Value
“How much money is recovery worth?”
38. Role of Devops
Asset management
Policy Enforcement
Disaster Recovery
Access Controls
Monitoring - Operations
Deployments– App Dev
Support – APP Dev & Operations
Own Outright Shared Responsibility
`
39. Team Roles
DevOps
Architects
App Dev
QA
Scrum Master
Build Management
Security
Devops
Help Desk
Computer Operations
Account Manager
Field Support
QA
App Dev
Finance
Development Support
40. Business Impacts
Accounting/Finance
• Capex vs Opex
• Pay-as-you-go Harder to forecast costs
• Pricing Balance revenue with platform costs
Legal
• More rigorous RFP Process
• Regulations – SOC2, PCI, ISO27001, SOX, PII, Safeharbor, software escrow, etc.
• Country specific rules on privacy and data
Human Resources
• Cloud requires many new skillsets
• Training
• Recruiting (skill shortage, remote and global workers)
• New incentives
Sales
• Shorter implementation cycles – Sell and go
• Need to understand basics of cloud computing, especially when it comes to defending security
• Need to discuss issues like privacy and SLAs
This presentation discusses various decision points around designing applications and services in the cloud
There are many ways to scale applications. In most on-premises systems we scale vertically by increasing memory, disk, and or CPU processing. In the cloud we scale horizontally by distributing the work across more nodes.
A key guiding principle to scaling is the notion of independence. We should ensure that an issue in one part of the system is isolated and has no impact on other parts of the system.
Each customer should be mutually exclusive so if one customer has a huge uptick of transactions that cause performance issues it is isolated and has no impact on other customers. Likewise, if a module like a reporting system is down or having ussies, you should still be able to bill and server customers from the other modules.
Key to doing REST right is not to maintain application state. Instead rely on hyperlinks (HATEOAS)
We should not be having a SQL vsNoSQL discussion. It often is SQL and NoSQL. Use the right tool to solve each unique problem.
This chart shows where the responsibilities lie between the vendor and the customer
When you build you own private cloud you are responsible for it all. Be careful what you ask for.
If you use the public cloud you are responsible for the app stack and up
If you use PaaS you are responsible for the application and up
If you use SaaS you only focus on administration of IDs