“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

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.

Um dos fenômenos mais interessantes da web 2.0 é a folksonomia ou tagging, que nada mais é do que associar um contexto (várias keywords) a uma informação em uma base compartilhada. Sendo assim, a grande inovação dos sistemas tagged’s é proporcionar uma busca contextual (Filtragem de Informações) mais eficaz do que os sistemas non-taggeds.

Ou melhor:

“Tagging-based systems enable users to categorize web resources by means of tags (freely chosen keywords), in order to re-inding these resources later. Tagging is implicitly also a social indexing process, since users share their tags and resources, constructing a social tag index, so-called folksonomy.”

Yusef Hassan-Montero  and Víctor Herrero-Solana

Em Improving Tag-Clouds as Visual Information Retrieval Interfaces 

Legal… mas o que isso tem demais? Bom, ao meu ver o interessante é que isto demonstra que estamos em um novo estágio da internet… em que nós (Eu e você inclusive!)  estamos  entendendo que a internet só tem significado e utilidade se as informações existentes forem encontradas de maneira simples e eficaz.  Então sempre que disponibilizar um conteúdo na web… tag nele!!

Obs.: Claro que para todos os outros problemas existe o google… quem sabe o google não cria uma base de dados universal para tag’s?? Google Base???

A review sobre o paper:

•  Fala sobre um novo modelo de popular nuvens de tag’s levando em consideração a interelação entre as tags.
• Relevância para meu estudo: 4
• Inovação: 8
• Relevância para mim: 10 (Gostei do assunto…)

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.