Agilidade no mundo real: Brasil 2010

28 de junho de 2010

Semana passada aconteceu o Agile Brazil 2010 em Porto Alegre.

O evento trouxe especialistas e relatos de experiências de todos os cantos do Brasil para mostrar o que está acontecendo com o mercado e o futuro caminho a ser trilhado.

A Cecilia Fernandes e eu mostramos como a remoção de práticas do Scrum em favor a princípios do Lean acabaram por tornar uma das equipes internas mais produtiva e capaz de entregar ainda mais valor. Alguns sugerem que chamemos o que fazemos nessa equipe (e em mais uma, menor, de 2 pessoas) de Kanban, e acredito que esteja bem próximo, mas prefiro me segurar ao lema de não nos atrelar a um método específico, mas sim aos princípios.

Em breve algumas palestras e entrevistas estarão online no site do infoq, no blog da Caelum e por aqui.

Como empresa de treinamento é fundamental para nós tentarmos novos caminhos antecipadamente e esses 2 anos de mudanças, idas e vindas de scrum e lean, lean e scrum, além da onipresença de práticas do xp, é o que faz tudo valer a pena.

A seguir, algumas conversas rápidas com o Rafael Rosa, Lucas Cavalcanti e Philip Calçado durante o evento:


Restrições são boas mas restrições são ruins

24 de junho de 2010

Junto com a Cecilia Fernandes, semana passada tive a oportunidade de apresentar nossa experiência com lean, o que aprendemos, as dificuldades e as vantagens.

A idéia foi demonstrar como as restrições eram vistas muito tempo atrás no desenvolvimento de software, como quebramos ela ao criar nossos próprios métodos “unified”, como adotamos agile através de xp e scrum e quebramos essas restrições novamente através de Lean. O ponto chave está na regra de que agilidade se baseia na inspeção e adaptação para atingir um objetivo, inclusive do próprio método.

No espírito da noite ágil, proposta pelo André Pantalião, a realidade de algumas equipes foram demonstradas e discutidas, junto com suas visões e problemas. Foi uma ótima oportunidade para muita troca de informações e discussão sobre os assuntos.

Em breve teremos outro encontro da noite ágil em São Paulo, anunciaremos nas listas de agile e no meu twitter.

Dois vídeos já estão disponíveis, “Restrições são boas mas restrições são ruins” e “O papel de QA em equipes ágeis”, incluindo as sessões de discussões e conversas logo após as mesmas:

Em breve teremos as outras duas apresentações online também.


Aula aberta de REST e acessando CouchDB/NEO4j

17 de maio de 2010

Na semana passada houveram dois eventos que pude participar.

Na aula aberta de REST onde apresentei a parte técnica de implantação de processos e workflows através de REST, após a palestra do Jim Webber sobre motivações financeiras para tal arquitetura.

No sábado foi a vez do evento noSQLbr, organizado pelo Alexandre Porcelli, cheio de exemplos de uso avançados de banco de dados noSQL, onde pude mostrar como o CouchDB e o NEO4Jse beneficiam de características da arquitetura REST e como podem ser estendidos para obter mais vantagens ainda.

Os slides de ambos os eventos já estão no slideshare, rest
e arquitetura contemporanea com nosql via rest.

O feedback foi ótimo e semana que vem nos vemos em Belo Horizonte.

E o Luca Bastos finaliza: “A apresentação do Jim foi uma das melhores ou provavelmente a melhor que já assisti de REST. E a do Guilherm também foi incrível porque chamou a atenção para coisas muito importantes e ainda apresentou exemplos muito legais que ainda estou digerindo. ”

E você já economizou seus milhares de reais desse ano e passou a usar a web como sua plataforma?


Minha arquitetura dói. Devo mudar para REST?

6 de maio de 2010

O que perdemos em não chegar em uma arquitetura REST de verdade, mas nos manter no modelo tradicional que adotamos até então?

Menor acoplamento

Em arquiteturas tradicionais, incluindo as típicas implementações de web services encontradas em clientes, temos um servidor com forte acoplamento a contratos (schemas e infinitos verbos) que inibem a evolucão de seu servidor independente de seu cliente, o que chamamos de forward-compatibility.

A arquitetura que apliquei é REST?

Um sinal que mostra a não adoção de um arquitetura REST é a existência de forte acoplamento entre clientes e servidores. Na arquitetura que está analisando, as mudanças no servidor implicam em alterações em seus clientes? Eles devem baixar código fonte (jar, gems etc)? Recompilar os projetos?

Mais genericamente, se a api disponibiliza um jar, gem ou equivalente que é sua API cliente, seu coupling é maior do que um sistema REST real.

Qualquer mudança em todos os clientes, mesmo os que não utilizam as novas funcionalidades, é um acoplamento indesejado. Imagine se todos os usuários do paypal devessem atualizar seus sistemas a cada novo release de sua API?

Se no cenária atual, os custos de manutenção estão altos pois toda mudança é refletida em manter clientes atualizados, sua aplicação claramente não é REST.

Em REST, forward-compatibility é natural.

Escalabilidade

O conceito de REST tenta pegar o que levou a web a ser esse mundo onde aplicações são criadas, alteradas e os clientes (seres humanos) continuam funcionando. É um ótimo da adaptabilidade de aplicações distribuídas como as conhecemos hoje. Não são web services educados.

Se sua empresa sofre com o alto acoplamento que web services popularizados criaram, com altíssimos custos de manutenção, ou ainda baixa escalabilidade, REST de verdade pode ser a solução.

Pergunta/Resposta

As abordagens de web services, SOA como praticado pelo mercado, EJB, RMI, Corba e RPC possuem características similares de alto acoplamento. Responda o questionário a seguir para analisar a vantagem de se usar REST:

(RPC) Qual a facilidade de colocar coisas novas e alterar servidores
existentes na sua arquitetura atual e não
encostar em nenhum cliente, tudo continuando a funcionar como antes? Seu cliente continua funcionando?

(RPC) Você consegue escalar para níveis como o da web, sem precisar comprar produtos de middleware, usando somente middleware commodity como proxies?

(RPC) Quantas vezes a api que você acessava (i.e. amazon) mudou e deixou seu programar quebrar?
(REST) Quantas vezes a amazon mudou o site e você não conseguiu comprar algo?

(RPC) Quantas vezes o sistema do correios ficou fora do ar e seu sistema não resolveu o problema de tolerância a falha, impedindo fornecer cotações de envio de produtos?
(REST): E se a estimativa continuasse válida, sem ter que alterar uma linha de código?

(RPC): Toda vez que sua API muda, você lança uma versão nova e obriga seus clientes a baixarem.
(REST): Você lança uma versão nova.

(RPC): Ao mudar a estrutura de seus recursos – como relacionamentos – todos os clientes quebram. O cliente, frágil, quebra facilmente.
(REST): O cliente, robusto, se adapta as necessidades e permite alterações no recurso e no meio que ele é representado.

Se você deseja alcançar essa arquitetura, é necessário executar diversos passos e usar REST como um todo, não somente verbos http e URIs.

– Se você deseja clientes acessando seu sistema durante anos, sem ter que atualizar todos os sistemas satélites mensalmente.

– Se você deseja escalar sem session replication.

– Se você deseja trabalhar com blue green deployment

– Se você quer ensinar clientes a funcionar com código que eles jamais viram na vida

Adotando REST

Tenho publicado uma série de artigos e vídeos em como adotar REST na prática, do zero.

Artigos técnicos que mostram os problemas e a maneira de implementar uma aplicação REST.

Antes disso, é vital mudar a maneira de pensar de arquiteturas RPC – como serviços web tradicionais – e para isso, é necessário um trabalho mais arquitetural com seus desenvolvedores.

Ao mesmo tempo, um trabalho gerencial permite encontrar os pontos de suas aplicações que se beneficiriam imediatamente, potencializando o retorno do investimento nessa arquitetura.

Eventos

Nesse ano de 2010 são diversos os eventos onde apresentaremos essas vantagens e como migrar para tal plataforma.

Seja em um evento sobre REST, Agile ou email, sinta-se a vontade para conversar sobre o assunto.

06 de maio – Gerenciamento ágil de projetos de Software com Scrum, USCS
13 de maio – Rest do zero, na Caelum
15 de Maio de 2010 – O papel do REST no CouchDB e Neo4J- NoSQLBR
22 de maio – Deploy contínuo – pois integração contínua não basta – Maré de agilidade/Belo Horizonte
29 de maio – Um produto em duas semanas – Maré de Agilidade/Vitória


Rest do zero – Parte 2

6 de maio de 2010

Esse video de 20 minutos mostra como mover de uma api REST tradicional para uma que utiliza recursos linkados e adiciona valor semântico real a esses links. Mais um passo para alcançar uma arquitetura realmente REST, de maneira simples.

Seu servidor e cliente REST já funcionavam assim? Ótimo.

Caso contrário, já é hora de desacoplar seu cliente de seu servidor, não?


REST a partir do zero

29 de abril de 2010

Esse é o primeiro post em uma série mostrando como usar Rails e Restfulie no servidor e Restfulie e Mikyung no cliente para criar uma arquitetura REST.

Nesse primeiro vídeo de 10 minutos você aprende a implementar em uma linha de código do Restfulie diversas representações (xml, json, atom) no servidor e também com uma linha, a enviar, receber, atualizar etc dados a partir do cliente.

Nos próximos vídeos sairemos do nível 1 do modelo de maturidade de uma arquitetura REST e passaremos para sistemas completamente REST.

Quaisquer dúvidas, junte-se ao nosso mailing list ou fale comigo no twitter.


Post no blog da caelum: evite tantas reuniões

28 de abril de 2010

Continuando a série de problemas práticos encontrados na maneira de
pensar quando adotamos metodologias ágeis, uma situação que afeta
muito a produtividade de Product Owners e Scrum Masters (ou
líderes/papéis similares em qualquer metodologia) é a falta de
produtividade dos dois devido a quantidade de projetos que lidam.

Este post que escrevi está no blog da Caelum.


Aplicando REST a corporações

26 de abril de 2010

Esse post é uma tradução do meu post original em inglês.

REST é o resultado de uma pesquisa que nos deixou com uma pergunta em aberto, como seu pesquisador sugeriu: REST resolve diversos problemas, mas como aplicá-lo a problemas modernos existentes em aplicações corporativas?

Aplicando REST

Após diversas conversas, resumi um modelo, derivado das restrições de REST, que nos permite medir como um sistema completo (cliente e servidor) alcança uma arquitetura REST.

O vídeo a seguir mostra um exemplo de como começar com o que acreditamos ser REST mas na verdade é uma arquitetura não REST típica e, adotando cada restrição, criar um sistema REST que executa processos de compra em quaisquer servidores REST.

O vídeo está em inglês e, em breve, postarei um tutorial do zero de como criar cliente e servidor aqui.

Qual o poder de “REST Applied”?

“REST Applied” como exemplifiquei resolve diversas preocupações modernas, preenchendo o buraco entre a dissertação de Roy e o uso da teoria em nossos problemas, abrindo espaço para um novo mundo de possibilidades.

Da mesma maneira que idéias REST, apesar de não serem chamadas de REST até então, permitiram que o crawling web fosse um cliente fantástico, “REST Applied” pode mudar a maneira como nossas aplicações se comunicam.

E por que não vimos isso antes? Pois a descrição do Roy segue o rumo de exemplos de crawling, que se beneficiam diretamente de content type negotiation. Por exemplo, o google utiliza o mesmo recurso, acessado por uma URI, com diversas línguas, podendo classificá-lo melhor do que se ficassem em URIs diferentes (sem um header adequado).

“In fact, the application details are hidden from the server by the generic connector interface, and thus a user agent could equally be an automated robot performing information retrieval for an indexing service, a personal agent looking for data that matches certain criteria, or a maintenance spider busy patrolling the information for broken references or modified content [39].”

Mas, “Not surprisingly, this exactly matches the user interface of a hypermedia browser. “… o cliente adapte-se para a representação atual, limitado a inteligência do cliente.

REST Applied pega todas essas idéias e resolve nosso problema, como os exemplos de Rest in Practice também seguem.

Frameworks/bibliotecas usadas

Restfulie dá mais suporte HTTP para bibliotecas http e provê um framework REST enquanto Mikyung permite criar seus clientes REST. Com ambos frameworks você está pronto para aplicar REST de verdade em seus problemas corporativos, não só webbies.

Mikyung significa “capital da beleza”, no sentido de “centro principal da beleza”, em coreano e é uma tentativa de reproduzir em seu nome a aparência de um belo cliente REST, comparado com código RPC.


Modelo de maturidade REST

20 de abril de 2010

Ainda não é REST

Como alcançar REST? Quão maduro é a minha aplicação em relação a REST? O modelo de Leonard Richardson foi amplamente discutido e comentado, inclusive no “Rest in Practice” (um livro que recomendo a leitura). Mas o que ficou faltando nesse modelo de maturidade? Por que o nível máximo não implica ainda em REST?

Nesse post, mais teórico, descrevemos um modelo que aborda o que é REST. Em próximos posts teremos vídeos e descrições de como aplicar REST na prática, fugindo do mundo de “serviços REST”.

De acordo com o modelo, nível 3 adiciona suporte a hipermídia, aperfeiçoando um sistema através do uso de linked data – um requerimento fundamental para REST. Mas HATEOAS sozinho não implica em REST, como o próprio Roy já mencionou.

Lembremos como RMI e objetos distribuídos permitiam a navegação dentre objetos e seus estados? O exemplo a seguir ilustra tal situação:


orders = RemoteSystem.locate().orders();
System.out.println(orders.get(0).getProducts().get(0));
receipt = order.payment(payment_information);
System.out.println(receipt.getCode());

Mas e se o código acima for uma sequência de invocações remotas de EJB? Se navegando através de relacionamentos (linked data) é REST, implementar o código acima a través de HTTP também seria (fora a falta de uniform interface).

O modelo se aproxima de REST no lado do servidor, e Rest in Practice chega a REST em ambos os lados, descrevendo a importância da semantica e de media types. O resto desse post descreve o que ficou de fora desse modelo de “serviços REST via web”, que na realidade são “serviços via web”.

O que ficou faltando?

O exemplo anterior não inspecionou a representação atual e relacionamentos antes de decidir qual seria o próximo passo e isso cria um alto acoplamento inexistente em aplicações REST.

O exemplo anterior contem um conjunto fixo de instruções a ser seguido, independentemente de qualquer resposta do servidor. O cliente não se adapta, não responde ao resultado de suas interações, mas assume um processo fixo.

The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations.“.

Se a API fosse http e o servidor respondesse com “Server too busy”, um cliente REST de verdade tentaria novamente em 10 minutos, o que os clientes tradicionais que escrevemos não fazem.

Mesmo alcançando o máximo de maturidade no modelo de Richardson, a aplicação que envolve cliente e servidor, não se adapta ao estado do recurso, ainda não é REST: seu cliente ainda possui um alto acoplamento.

Por esse motivo não existe tal serviço como REST web service, mas para ter uma aplicação REST, tanto o cliente quanto o servidor devem seguir suas características arquiteturais.

Modelo de Richardson e HTTP

Relações ricas em semânticas podem ser compreendidas por clientes e são fundamentais para a criação de um sistema REST. Um ponto importante é lembrar que o modelo continua sendo muito importante para demonstrar a maturidade de uma arquitetura em cima do uso de HTTP, mas ainda não impede o alto consumo financeiro vindo do uso do “mindset de web services” de maneira mais elegante, mas com o mesmo custo de acoplamento.

Um modelo de maturidade REST

Por todos esses motivos, proponho um modelo de maturidade independente do protocolo, onde podemos medir o uso dos aspectos de REST em um sistema:

Rest Architecture Maturity Model

Rest Architecture Maturity

Para atingir REST, o primeiro passo é a utilização de uma uniform interface: um conjunto padrão de ações que podem ser executadas em todos os recursos existentes. Por exemplo, em HTTP, os verbos definem a interface uniforme, o que pode ser efetuado com cada recurso.

O segundo passo é a adoção de linked data para permitir ao cliente navegar entre estados e recursos de maneira uniforme. Através de HTTP, como o modelo de Richardson descreve, este é o uso de hypermídia como connectedness.

O terceiro passo é adicionar valor semântico aos links. Relações definidas como “related” podem possuir valor semântico em determinados processos, menos valor em outros. “payment” pode fazer senido para outros. A criação e adoção de media types permitem – mas não implicam – em código sendo escrito de maneira menos acoplada.

O quarto passo é criar clientes de maneira que suas decisões sejam baseadas nos relacionamentos e estado de recursos, além do conhecimento do media type. É o media type e seus relacionamentos que criam o acoplamento entre clientes e servidores, qualquer outro acoplamento vem de arquiteturas que não REST.

Todos os passos acima devem ser tomados para minimizar o acoplamento do cliente ao servidor – e vice versa.

O último passo é a evolução do cliente. Code on demand permite educar clientes como se comportar em situações específicas que não foram previstas, como por exemplo ao encontrar um novo media type desconhecido.

Note que para a adoção de REST, o modelo apresentado no gráfico, nenhuma menção foi feita ao protocolo HTTP (somente exemplos), pois REST é agnóstico ao mesmo.

O post a seguir descreve como criar um cliente REST e suas vantagens.


Videos sobre REST

13 de abril de 2010

Nesse sábado acompanhar o encontro do GURU-SP e foi possível fazer uma apresentação relampago que o Fernando Ribeiro gravou. A palestra é a jato, portanto perdão por ser direto ao ponto.

no vídeo a seguir, faço uma apresentação em inglês sobre o que é e o que não é REST, em inglês.

E a apresentação no GURU-SP:

E você, já estava escrevendo clientes REST?