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
Component Description United!!!
Como criar um padrão de fato para descrever componentes de software?? Esta é uma pergunta interessante, mas até hoje não respondida. Seria esta a pergunta de um millhão de doláres?? Em minhas lectures sobre componentes e mercados de componentes me deparei com um mais um paper (Component Market Specification Demand and
Standardized Specification of Business Components) que apresenta informações relevantes que devem ser consideradas em uma descrição de componente… apesar do dito cujo fazer o favor de apresentar/relembrar diversos conceitos, como design by contract, the importance of component markets, composition. Sua maior importância foi justamente relembrar o meu questionamento interno sobre a importância da padronização.
Muitos esforços foram guiados neste sentido nos últimos anos, basta lembrar que em diversas conferências internacionais a descrição de componentes sempre esteve presente em algum paper.
Estes estudos e as necessidades da industria culminaram na aprovação do DRAFT da OMG para a especificação RAS (Reusable Asset Specification). Eis que o problema parecia estar resolvido e que em breve teriamos uma enxurrada de players dando suporte a especificação em suas ferramentas e repositórios… mas como de praxe(Ou praga?) isto não ocorreu (OMG hahahaha).
Para não ser mentiroso, o único player que mexeu um dedo foi a IBM que implementou em 2005 um repositório simples (RAS4W) e deu um leve suporte em sua suíte de desenvolvimento (WSAD).
Mas e agora? O que vamos fazer??? Pense que se uma especificação com grandes players (IBM, Microsoft, Flashline, ComponentSource…) não virou padrão, qual seria a chance de outra especificação tomar este lugar???
Tenho a sensação que está resposta está atrelada a tão falada WEB2.0 e seus formatos de descrição.
Claro que a idéia não é provocar uma reviravolta em todos os estudos sobre descrição de componentes…. e sim tornar a descrição algo simples e fáctivel.
Como exemplo, temos o sucesso do RSS.
Mas…. o que está abordagem difere das existentes?? Vale lembrar que a criação de um mercado GLOBAL de componentes é um dos requisitos para o sucesso do DBC, e já que esperar que todos iteroperem a nível de repositório é impraticável, poderiamos ao menos sonhar que as descrições dos assets(ativos) possam ser intercambiáveis. Já imaginou realizando uma busca no google(ou froogle) através destes metadados??? E o oráculo respondendo todos nossos anseios na busca de componentes?
Para não perder o costume, aí vai o meu review…
* Review do Paper (Relevância: 8 / Inovação: 2 )
* Obs.: Um aspecto interessante do texto são as definições de termos recorrentes.
Ex.: We define a component market as an abstract place where components are exchanged and their value is determined by the bidding process between the supplier and the user of components.
Desafios no Negócio de Componentes de Software
Normalmente as pequisas sobre DBC (CBD?) focalizam em áreas técnicas, deixando de lado um importante desafio (talvez o mais importante…) que é a venda de componentes de software. Negligenciar esta área talvez tenha sido um dos grandes fatores para a lentidão no surgimento e aceitação dos mercados de componentes (ie. ComponentSource) e até hoje uma das grandes dificuldades para a migração de empresas que se baseiam em projetos para o mundo de produtos.
O artigo apresenta uma visão geral sobre o mercado de componentes, enfatizando as dificuldades (Software standardisation, lack of quality components…) e a diferença entre o modelo tradicional de desenvolvimento (Project) para o modelo adequado para componentes (Product). A maior contribuição do trabalho é um estudo empírico sobre as relações B2B entre Customers e Component Suppliers.
OBS.: Interessante a Tabela 1 que apresenta uma comparação entre Software Project Business X Software Product Business.
Visualizar White Paper (Nina Helander & Paulina Ulkuniemi)
Meu review: 7 – Interessante, mas muito confuso.
Talvez seja a dificuldade inicial de entrar em uma nova área.
