SaaS 2, o que um livro sobre SaaS deveria ter?
“single instance, multi-tenancy is still a black art that only selected few have been able to master”
Esse post é rápido… mas é interessante.
Em SaaS is a journey, walk with us, Fred Chong (Arquiteto da Microsoft) indica o que seria interessante ter em um livro sobre SaaS. O melhor é que ele e seu amigo Gianpolo começaram a jornada produzir este livro. Então aí vai…
Sumário:
1. Introduction
* Definitions
* Differences from traditional ASP model
* SaaS value proposition
* Realizing SaaS = business model + application architecture + operation structure
2. Business Model
* Revenue and licensing model
o Additional services revenue: configuration and customization
* Sales compensation model
* Types of software services
* Designing SaaS SLA and contracts
3. Application Architecture Overview
* Instancing and multi-tenancy
* Comparisons of application architecture: on-premise, ASP, SaaS
* SaaS maturity model
* SaaS application architecture issues: identity, data, workflow, messaging, design for manageability, service-orientation, scaling, tenancy, meta-data, service consumption etc.
* Overview of SaaS capabilities and enablement architecture
4. Scaling 101
* Pools: thread, connections etc.
* Async
* Locks
* States
* UI/Presentation
5. Data Management
* Partitioning for scaling and performance
o Data partitioning schemes: Spatial, temporal, hashing etc., SQL Server 2005 support for data partitioning
o Data distribution patterns and functions
o Dynamic partitioning: re-partitioning growing database
* Data availability
o Replication strategy
6. Tenant Management
* Data model for tenant management
* Subscription Management
* Identity management
o Models
*
Delegated administration
*
Identity federation
*
Hybrid: e.g. federation for tenants and delegated admin for tenants’ customers.
7. Tenant Customization
* Meta data service for customization
* Approaches for extending application data model
* Approaches for UI customization
* Approaches for business process customization
* SaaS and system integrations modes:
o In house systems to SaaS integration (main app is in house)
o SaaS to in house systems integration (SaaS is the main app)
o SaaS with partial SaaS solution hosted on premise
o SaaS to SaaS integration
+ Direct
+ Hub-and-spoke through SaaS integration platform (like Salesforce’s AppForce)
8. Application and Data Security
* Common authentication schemes: username/pwd, certificates
* Application single sign-on
* Securing data transfer
o Application security session
o Session data integrity and privacy
o Transport vs. application level security
* Authorization
o Schemes: ACL, RBAC, business rules
o Policy management: distributed/resource, centralized
* Application security abstractions:
o Tokens, claims, security token services, security policies
* Trusted sub-system model for securing application tiers
* Identity context propagation
* Secret/key management: for application and tenants
* Data isolation schemes
o Database access control: RBAC, views etc.
o Partitioning:
+ Logical: tables, databases
+ Physical: disks
o Database encryption
9. Programmable Software Services
* Software service lifecycle
* Service versioning
* Service certification, registration and publication
* Software service registry
o Requirements
o Architecture
10. Programmable Software Service Consumption
* Function vs. data oriented services (web service vs. RSS vs. REST etc)
* Composite applications
* Tools and community framework
11. Instrumentation and Monitoring
* Types, goals and audience of instrumentation: infrastructure, application stack, business logic
* Instrumentation constructs: counters, events, rules, threshold, alerts
* Health monitoring
* Availability monitoring
* Business performance monitoring
12. Configuration Management
* Change management requirements
* Configuration management architecture
13. Metering
* Usage models
* Data model for each metering
* Usage tracking architecture
14. Infrastructure Security
* Network and firewall design
* Intrusion detection
* Protecting against viruses and worms
* Protecting against denial of service attacks
15. Operation Structure
* Provisioning
o Infrastructure
o Application
o Tenants
* Disaster recovery
* Billing
* Network operation center
* Call center
Appendix
* SaaS enablement roadmap: from on-premise and ASP to SaaS
o Scenarios and SaaS enablement strategy
* Enabling SaaS to on-premise solution migration
o Deploy existing SaaS solution and subscription to on-premise
o Need to de-mingle data to be hosted on-premise
Software As Service (SaaS), Mashups… etc
Este novo(será?) modelo de negócios vem revolucionando a forma como iremos construir nossas aplicações futuras. Em vez de nos preocuparmos em (re) desenvolver nossas aplicações, iremos apenas acessar(ws,rest) API públicas(ou pagas… tsc tsc) que já implementem o serviço necessário.
Esta idéia não é necessariamente nova, pois a maior promessa do Desenvolvimento Baseado em Componentes (DBC) é justamente a mesma. A grande diferença é que no SaaS não existe deploy dos componentes(API) e os vendedores de serviço possuem um maior controle sobre seu negócio (leia-se fiscalização, pirataria ZERO!!) e liberdade de negociação com os compradores do serviço.
Mas o que seria esse maior controle? Pense que no modelo de negócios atual software é considerado como um produto fechado (Televisão, Computador, Geladeira…) , ou seja, a principal esquema de negóciação é aquele em que o usuário deseja um sistema, vai lá na prateleira (Ou na softwarehouse), compra e leva para casa para a implantação. Este modelo tradicional é conhecido como pay per copy(pague por cópia), e atualmente possui um alto grau de pirataria, pois com cada cópia do software vai um serial válido para o registro do software. E como todos nós sabemos, estes seriais podem ser compartilhados ou gerados (com os key gen’s). Observe que é a empresa de software que arca com os prejuízos da pirataria.
Neste novo modelo o software é considerado como serviço (TV a Cabo, Luz, Esgoto). Ou seja, de acordo com seu desejo (ou necessidade) você vai lá adquire o serviço(Um mashup com o Google Maps e um banco de dados geográfico da sua cidade, por exemplo) e quando não mais desejar você vai lá e cancela. Este modelo é conhecido como pay per use (pague pelo uso), a vantagem deste modelo é justamente o usuário ser responsável pela utilização do sistema principalmente sobre preço que irá pagar, além de que o vendedor do serviço sabe com certeza quem está utilizando o serviço, agora sendo capaz de bloquear os pirateiros.
Apesar de bloquear os pirateiros, este modelo não está imune a pirataria. Pois, assim como na vida real irá existir a figura do “gato” (Sim… ele mesmo, o mesmo “gato” da luz e da tv a cabo…), ou seja, a pessoa que terá acesso ao serviço utilizando a credencial de outra pessoa.
Observe que neste modelo a pessoa “lesada” é quem fica com o prejuízo da pirataria.
Sendo assim o Software as Service não vem apenas facilitar a criação rápida de aplicativos (Reuso de fato), mas também proteger as empresas produtoras de software com respeito a pirataria.
Você tem dúvidas de que o SaaS irá pegar?
- Adobe Photoshop Versão Online
- ThinkFree representa alternativa ao pacote Office
- Adobe Apollo (Plataforma da adobe em que os aplicativos web interagem com o Desktop)
Obs.: Neste post ainda ficou faltando abordar a liberdade de comercialização dos serviços no SaaS.
Por fim, vai um videozinho do youtube sobre a plataforma Apollo.
