Escalabilidade "built-in"

Num momento em que muito se fala de Cloud Services, Cloud Computing, e em que começam a surgir muitas empresas a apostar forte nessa área, seria tolice não apanhar a onda e não analisar mais a fundo as várias opções actualmente existentes no mercado que podem suportar as necessidades infra-estruturais de um novo serviço web.

Em primeiro lugar, é de salientar que a utilização dos cloud services pode trazer grandes benefícios para um empreendedor em TIC:

- Redução das preocupações e do tempo despendido na gestão da infra-estutura de hardware e software (o fornecedor do serviço é que terá de ter esse trabalho); 

- Acesso a soluções profissionais (backups, storage, largura de banda...) com baixo custo, devido à larga escala;

- Modelo pay-as-you-go, sem necessidades de grande investimento inicial;

- Escalabilidade "built-in" = Fácil capacidade de expansão da infra-estrutura.

No entanto, nem todos os serviços "cloud" são iguais e muitos deles nem passam de uma mera virtualização de servidores físicos em servidores virtuais, o que dificulta um bocado a sua aplicabilidade, pois continuam a existir limites virtuais de memória, processamento, espaço em disco... e todas as preocupações de escalabilidade continuam presentes: necessidade de load-balancers,  algoritmos tolerantes a faltas... e por aí fora.

Em http://www.informationweek.com/news/software/hosted/showArticle.jhtml?articleID=210602537 são listadas algumas startups que estão a apostar nesta onda. Algumas delas, como a Kaavo ou a Elastra nem sequer são donos de uma cloud própria mas sim fornecem serviços de integração e disaster recovery para outras clouds como a da Amazon ou Google.

Os tipos de serviços disponibilizados por uma cloud são, geralmente:

- criação de máquinas virtuais;

- espaço em disco infinito;

- bases de dados estruturadas; 

- filas de mensagens;

- servidor web escalável até milhões de utilizadores em simultâneo;

- CDNs (Content Delivery Networks) que permite a disponibilização de conteúdos (ficheiros, vídeos, etc..) a partir de vários DataCenters espalhados pelo globo e sem perda de performance devido aos acessos em simultâneo dos vários utilizadores.

Estes serviços são pagos mensalmente (ex: $0.15 por GB por mês), tendo em conta a quantidade de dados transferida para dentro e fora da nossa conta, bem como a quantidade de dados guardados em disco. Apenas os servidores virtuais é que têm um modelo diferente, semelhante aos planos de alojamento web habituais: x por mês fixo, com limites de tráfego e disco.

Como escolher o fornecedor adequado para a nossa solução? 

Ou melhor, a pergunta pode até ser: 

Como definir a solução adequada tendo em conta os serviços prestados pelo fornecedor escolhido?

A forma mais correcta de responder a estas perguntas, passa por conhecer os vários serviços e planos de preços, bem como as limitações apresentadas caso a caso.

A resposta não é fácil. No entanto, vou tentar esclarecer alguns conceitos no próximo post para se delinear uma estratégia de adopção da cloud para o nosso projecto. 

Diverte-te!

Ideias há muitas!

Por vezes pensamos que as nossas ideias têm tanto potencial, que a própria ideia em si vale uma quantia imensurável de dinheiro e, portanto, devemos tudo fazer para a proteger...

Na verdade vos digo: se uma ideia nunca passar de ideia para se tornar em algo concreto, o seu valor é muito pouco ou mesmo nulo.
Portanto, em vez de esconderes as tuas ideias, mostra-as ao mundo, partilha-as sem receio com os teus amigos e verás que essa atitude em vez de ser um risco (por te poderem "roubar" a ideia), pelo contrário, irá contribuir para a evolução da própria ideia, e o momentum criado irá trazer a motivação extra para que a ideia se torne em algo real.

Tornando-se em algo real, o seu valor cresce drasticamente, e aí sim podes pensar em proteger o "produto" através da criação de uma marca ou patente.

Mas nem todas as ideias se transformam em produtos vencedores. A mesma ideia pode inclusivamente ser concretizada de formas tão distintas por diferentes equipas que um produto pode ter um sucesso extraordinário e o outro não passar de um protótipo...

Derek Sivers, Presidente da HostBaby, apresenta este tema de uma forma bastante elucidativa no seu blog http://sivers.org/multiply

"It's so funny when I hear people so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.)

To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

Explanation:

AWFUL IDEA = -1
WEAK IDEA = 1
SO-SO IDEA = 5
GOOD IDEA = 10
GREAT IDEA = 15
BRILLIANT IDEA = 20

NO EXECUTION = $1
WEAK EXECUTION = $1000
SO-SO EXECUTION = $10,000
GOOD EXECUTION = $100,000
GREAT EXECUTION = $1,000,000
BRILLIANT EXECUTION = $10,000,000

To make a business, you need to multiply the two.

The most brilliant idea, with no execution, is worth $20.
The most brilliant idea takes great execution to be worth $20,000,000.

That's why I don't want to hear people's ideas.

I'm not interested until I see their execution."

Em conclusão:
Ideias há muitas! Aposta na concretização!

Diverte-te!

É mais fácil dar um passo noutra direcção...

...quando já se está a dar um passo em alguma direcção!

Foi com este pensamento que hoje acordei, e que fui mentalmente explorando ao longo do dia.

Por vezes pensamos que a partir do momento em que temos um plano bem definido e nos começamos a mexer de acordo com o planeado, devemos colocar "umas palas nos olhos" para esquecerrmos por completo as outras alternativas existentes e nos cingirmos ao plano. A verdade é que o acto de planear não passa de especulação ou adivinhação e só à medida que avançamos num projecto é que começamos a ter o conhecimento relevante que nos ajude a tomar decisões informadas.

Mudar de direcção durante o trajecto não é tão difícil assim. E, seguindo uma metodologia Agile, o resultado pode ir muito mais ao encontro das expectativas.

O que é difícil é ultrapassar a barreira da inércia inicial! Se planearmos logo de raiz fazer uma aplicação perfeita, com todos os detalhes explicitados ao milímetro, a barreira da inércia sobe; e torna-se um fardo para ultrapassar.
Se, em vez de planearmos tudo ao detalhe, formos gradualmente criando o conceito da aplicação (começando com algo muito simples e desenvolvendo apenas o que é mesmo essencial) a barreira da inércia torna-se apenas uma pedra no caminho, que podemos "chutar" para o lado sem grande dificuldade.

Num post anterior, apresentei a falta de entusiasmo como o inimigo nº1. Aqui, apresento a inércia como o inimigo nº2.

Como combater a inércia?
Bastam duas fases:

Fase 1 - Começar a mexer em qualquer direcção que seja mais fácil, directa, natural, motivante (mas mostrando logo algo como resultado, nem que sejam apenas uns drafts ou umas ideias gravadas em audio/video);

Fase 2 - Alinhar a direcção gradualmente, à medida que se vai avançando (através da gestão de prioridades, com remoção de excessos de ideias acumulados).

Esta é uma outra forma de ver o Agile. E é por isso que eu gosto.

Diverte-te!

A partir de agora também vais poder "postar" aqui

No último mês estivemos tão activos no google wave (a discutir ideias para mini-aplicações) que fui descurando a inserção de novos posts neste blog.

Não por falta de assunto (tenho um conjunto bem grande de temas em lista de espera) mas apenas porque 4horas por semana não dá para muito...

Para que isto não volte a acontecer (este blog ficar "parado" por 1 mês) resolvi tornar todos os elementos da equipa como "autores". Isto quer dizer que a partir de agora vais poder ser tu a "escolher o tema de debate" e dar a oportunidade aos outros elementos de comentar sobre esse tema.

Existem expectativas por discutir, metodologias por dar a conhecer, ferramentas por apresentar... Conto contigo para lançar um novo olhar sobre estes temas! (ou outros)

Envia-me um email com o email que pretendes usar para publicar neste blog. Também se aceitam OpenIDs! ;)

Diverte-te!

As pessoas gostam é de se divertir!

Quantas vezes já pensaste numa ideia de negócio que se baseia na enorme utilidade de uma aplicação e ficas:

"xiiiiiiiii, isto dá mesmo bué jeito. Toda a gente vai querer pagar para usar isto!..."

Desengana-te.

A maioria das pessoas não investe muito na "utilidade". No entanto, gasta muito dinheiro no divertimento.

Senão, faz uma auto-reflexão: Quantas vezes já foste a um bar à noite, onde cada bebida é a 5€, e pensaste: "5€? Que chulice... " "Ok. Quero duas!"

E agora um outro exemplo em que viste uma aplicação na net, que parece super-interessante e que poderia trazer uma grande vais-valia para o teu dia-a-dia, e pensaste: "É a pagar? Esquece..." mesmo que seja por 1€!

Esta tendência natural das pessoas pode comprovar-se com o sucesso financeiro que os jogos tipo FarmVille estão a ter. As pessoas gostam é de se divertir!

E é por isso que é TÃO IMPORTANTE criar aplicações que, para além de serem úteis, sejam também "engaging" e "enjoyable" e façam com que as pessoas fiquem "addicted" (num bom sentido) ao ponto de as partilharem com os amigos.

Diverte-te!

Metodologias de Desenvolvimento Agile

Depois de alguma pesquisa relativa a este tema, cheguei às seguintes ilacções:

Noutras metodologias, a interface é desenhada logo com todas as funcionalidades possíveis mas a maioria é fake, não funciona. Isto torna-se fuleiro pois se o projecto terminar a meio nota-se que o software está por acabar e não pode ser mostrado aos futuros utilizadores.

A metodologia Agile, baseia-se na utilização de ciclos de desenvolvimento mais pequenos, mas em que no final de cada ciclo todas as funcionalidades visíveis no protótipo/aplicação estão a funcionar.

Ou seja, se o projecto terminasse aí, o software já era usável. Limitado, é certo, mas sem dar a entender que tem "pontas soltas" (funcionalidades por terminar).

Só nós é que sabemos que está por terminar. Enquanto que a percepção exterior é de que está acabado! Com poucas funcionalidades, mas acabado!

Isto é óptimo! Pois permite:

- uma entrega mais rápida de algo que pode ser colocado em produção, enquanto o desenvolvimento continua;

- obter feedback dos utilizadores finais mais depressa, que permite perceber se estamos a ir na direcção certa;

- maior flexibilidade para mudar de direcção se se verificar que a ideia original não serve;

No limite, as várias versões poduzidas podem até ser usadas em paralelo, por diferentes tipos de targets, pois nem toda a gente necessita de todas as funcionalidades.

O problema do software complexo (com muitas funcionalidades) é que torna complicadas as coisas simples. E, para certas pessoas, não há necessidade...

Ou seja:

AIM HIGH, START EASY!

Vejamos um exemplo na prática.

Quando pensamos em desenvolver um site, a primeira coisa que começamos a rabiscar é um layout com um menu, logotipo, algum conteúdo...

E depois, quando vamos desenvolver, acontece disto http://www.eb23-paranhos.rcts.pt/ UNDER CONSTRUCTION.

Em algumas das páginas criadas no menu ainda não se sabe muito bem o que queremos colocar, e ficam em construção (por vezes indeterminadamente).

A proposta Agile é começar de forma simples e com aquilo que é mais prioritário. Por exemplo, um site com apenas o logo e os contactos. Mas tendo por objectivo acabar com um produto fechado em cada ciclo, nem que o produto seja mesmo muito simples.

O grande problema é que a motivação se vai naturalmente detriorando ao longo do projecto... à medida que a novidade vai desaparecendo. Concordam comigo, certo?

Já agora, relativamente ao "under construction", vários sites indicam que não se deve usar por várias razões. Exemplo http://www.cs.utah.edu/~gk/atwork/

Concluindo,

segundo aquilo que pude constatar, o objectivo é apontar inicialmente para um produto o mais simples possível. E só depois de atingir esse objectivo é que se avança com alterações e alterações e alterações... mas sempre tendo por meta terminar cada ciclo com um produto fechado. Interessante, hein?

Portanto já sabes: AIM HIGH, START EASY!

Diverte-te!

Expectativas - Competências da Equipa

Falando em termos individuais, o gráfico ao lado pretende demostrar que o percurso até obtermos todos os conhecimentos que necessitamos para desenvolver um projecto de sucesso ainda é longo. No entanto, podemos contar com o conhecimento previamente adquirido (what we know sufficiently), com uma lista de tópicos que podemos, queremos e vamos explorar (what we know that we don't know) e ainda com a certeza de que pelo caminho da busca de novos conhecimentos vamos encontrar "what we don't know that we don't know", o que irá fazer crescer o círculo azul (pois passamos a saber mais uns assuntos que não sabíamos) e, mais tarde, depois de maior investigação, irá fazer parte dos nossos conhecimentos pessoais.

Uma boa forma de ajudar ao processo de obtenção de todos os conhecimentos necessários, é chamar novos elementos para a equipa. Nesta fase inicial, em que ainda se está a constituir a equipa, um dos principais focos prende-se com o contributo que cada novo elemento poderá trazer para a competência global do grupo.

O ideal será que cada novo elemento venha complementar os conhecimentos já existentes no grupo, fazendo crescer a área do "what we know sufficiently" e também a lista de tópicos a explorar (área azul). Desta forma, iremos maximizar o nosso conhecimento àcerca daquilo que precisamos de saber e garantir o sucesso do projecto.

É um factor preponderante garantir que o conhecimento não é apenas detido por cada elemento em separado, mas sim que seja partilhado abertamente entre toda a equipa. Daí a importância da criação do blog individual, para partilha do conhecimento actual bem como dos novos conhecimentos adquiridos no processo de Enlightened Community Engagement.

Para já, e como forma de apresentação mútua, iremos partilhar (usando o Wave):

- aquilo que cada um sabe que sabe o suficiente;

- aquilo que cada um sabe que não sabe o suficiente mas seria interessante saber;

Apenas para que conste, os elementos da equipa ainda não foram apresentados pois o grupo ainda não está "fechado". No entanto, a partilha de competências individuais no wave irá permitir saber quem já está interessado em fazer parte deste projecto, e com quem podemos contar.

Diverte-te!