Por que cidades crescem, empresas e pessoas sempre morrem, e a vida fica mais rápida? /ou: It's complex (adaptive), baby...

Posted: 7 de jun. de 2011 | . David Lojudice Sobrinho | tags: , , , 2 comentários

"Melhor 51.22 minutos que eu gastei nos últimos bons tempos. OBRIGADO!" - Richard Saul Wurman (fundador das conferencias TED)

Normalmente não utilizo este blog para a simples divulgação de conteúdo, já que tenho outros meios de fazer isso (twitter, google reader, trunk.ly). Tento ao menos digerir algo para colocar aqui. Mas dessa vez, acho que vale quebrar a regra e simplesmente divulgar esse excelente vídeo, já que é sobre um assunto recorrente neste blog.

Geoffrey West, físico teórico, ex-presidente do Instituto Santa Fé (famoso instituto dedicado ao estudo de sistemas adaptativos complexos), mostra no vídeo abaixo os resultados dos seus mais recentes estudos no campo de sistemas complexos e problemas de escala (vindos da física). Mais informações no vídeo e no site:

Why Cities Keep Growing, Corporations and People Always Die, and Life Gets Faster
http://edge.org/conversation/geoffrey-west

Alguns pontos do vídeo (tirados do site):

... The great thing about cities, the thing that is amazing about cities is as they grow, so to speak, their dimensionality increases. That is, the space of opportunity, the space of functions, the space of jobs just continually increases. And the data shows that. If you look at job categories, it continually increases. I'll use the word "dimensionality." It opens up. And in fact, one of the great things about cities is that it supports crazy people. You walk down Fifth Avenue, you see crazy people. There are always crazy people. Well, that's good. Cities are tolerant of extraordinary diversity.

This is in complete contrast to companies. The Google boys in the back garage so to speak with ideas of the search engine, were no doubt promoting all kinds of crazy ideas and maybe having even crazy people around them.

Well, Google is a bit of an exception, because it still tolerates some of that. But most companies start out probably with some of that buzz. But the data indicates that at about 50 employees to a hundred that buzz starts to stop. A company that was more multi dimensional, more evolved, becomes uni dimensional. It closes down.

Indeed, if you go to General Motors or you go to American Airlines or you go to Goldman Sachs, you don't see crazy people. Crazy people are fired. Well, to speak of crazy people, is taking the extreme. But maverick people are often fired.

It's not surprising to learn that when manufacturing companies are on a down turn, they decrease research and development, and in fact in some cases, do actually get rid of it, thinking this is "oh, we can get that back in two years we'll be back on track."

Well, this kind of thinking kills them. This is part of the killing, and this is part of the change from superlinear to sublinear, namely companies allow themselves to be dominated by bureaucracy and administration over creativity and innovation, and unfortunately, it's necessary. You cannot run a company without administrative. Someone has got to take care of the taxes and the bills and the cleaning the floors and the maintenance of the building and all the rest of that stuff. You need it. And the question is, "can you do it without it dominating the company?" The data suggests that you can't.

The question is, as a scientist, can we take these ideas and do what we did in biology, at least based on networks and other ideas, and put this into a quantitative, mathematizable, predictive theory, so that we can understand the birth and death of companies, how that stimulates the economy? How it's related to cities? How does it affect global sustainability and have a predictive framework for an idealized system, so that we can understand how to deal with it and avoid it? If you're running a bigger company, you can recognize what the metrics are that are driving you to mortality, and possibly put it off, and hopefully even avoid it.

Otherwise we have a theory that tells you when Google and Microsoft will eventually die, and die might mean a merger with someone else.

Animais, cidades, empresas... a mesma coisa! Metáforas nunca estiveram tão próximas da realidade...

Memcached.JS /ou: Sanidade não era pré-requisito

Posted: 1 de mar. de 2011 | . David Lojudice Sobrinho | tags: , , , , 3 comentários

Idéia
Eu acho que pra aprender uma nova linguagem, engine, etc., é bom ter um projeto com um propósito prático. Afinal é na prática que você vai sentir as verdadeiras dores.

Estava interessado em aprender Node.JS, principalmente seu modelo de non-blocking I/O e JavaScript no server-side utilizando o V8. Ao pensar num projeto pra implementar essas idéia, event loop (de I/O) e memória (GC), a primeira coisa me veio a cabeça foi o Memcached.

Mas implementar o Memcached em JavaScript? Ninguém falou que seria fácil! Aqui compartilho alguns desafios que encontrei, alguns vindos do problema proposto em si (cache distribuído em memória) e outros vindos pela solução dada (Node.JS, V8, etc.)

Prefácio: Memcached Server em JavaScript?
Quando comecei, a idéia parecia meio maluca, mas a intenção era aprender e, logo, sanidade não era pré-requisito. Se eu conseguisse implementar os principais comandos e um algoritmo de complexidade O(1) de cache, como no projeto original, eu já estava feliz. Depois era só perseguir uma performance parecida.
Depois de conseguir atingir alguns desses objetivos, o Memcached.JS agora me parece uma alternativa em alguns cenários. Exemplos que me vem a mente:

- Não tenho acesso a um Memcached mas uso um serviço de cloud para Node.JS. Se performance não é seu requisito mais forte, você poderia ter uma instância do Memcached.JS sem problemas (e, alias, não é que a performance do Memcached.JS é ruim, ela só não é tão boa quanto o projeto original).

- Alterar o comportamento do server. Entre se perder em 7500 linhas de código em C do projeto original, basta brincar com 750 LOC em JS. Simples.

Tenho certeza que pessoas mais criativas que eu vão achar usos mais interessantes, mas esses acima já me fazem olhar para o projeto de uma forma diferente. Sim, é uma idéia meio maluca, mas talvez tenha sua utilidade.

JavaScript mostra sua idade
A primeira dificuldade que se encontra ao programar em JS em server side é que existem um mundo de informações sobre JavaScript, mas a maioria é "how to" para desenvolvimento front-end, onde informações de DOM e JS se misturam. Além disso, a maioria dos links é da idade da pedra da internet. Ex.: procure "js string concatenation"

Encontrar bom material sobre JavaScript, sem detalhes de browser e além disso atual, com técnicas avançadas do uso da linguagem (a parte funcional, por exemplo) leva um tempo. Bom, vou facilitar seu lado: http://neversaw.us/2011/1/16/not-your-fathers-javascript/

Orientação (quase) a Objeto
Pode-se argumentar se existe ou não OO em JS, mas a verdade é que se ela existe, não é "out-of-box". Você se pega desbravando por prototypes, problemas com this e o obscuro bind. E tudo que você queria era um método numa superclasse. Depois desse perrengue, hoje eu acho super legítima a idéia do CoffeScript.

V8: Uma VM para server-side?
Uma discussão que apareceu quando estava desenvolvendo o projeto foi se o V8 era uma VM preparada para server-side, já que o principal mantenedor, o Google, tinha interesse exclusivo no front-end. Interessante, certo?
Meus testes, no meu domínio de problema, mostraram que o V8 se comportou muito bem. Para um cache, que trabalha com objetos em memória, eu não vi grandes penalizações.
O que eu vejo como melhoria, especificamente para o Memcached.JS, é que o Buffer faça parte do V8, assim como String, e não parte da lib do Node.JS. Isso provavelmente iria fazer o Buffer ser gerenciado tão rápido quanto a String é hoje.
Ai vem a pergunta: isso vai fazer diferença no front-end (aka Chrome)? Não. E por isso, provavelmente, não veremos essa alteração tão cedo.

Se você precisa entender como a VM está trabalhando ou fazer profile do seu código em JS, recomendo aqui algumas libs e tools muito boas para fazer isso:
- https://github.com/dannycoates/v8-profiler
- https://github.com/dannycoates/node-inspector
- http://code.google.com/p/v8/wiki/V8Profiler

E a parte boa?
Concorrência! Coisa linda de ver. Quão simples pode ser um código que não precisa se preocupar em bloquear recursos compartilhados em um ambiente altamente concorrente? Simples o suficiente. E isso é muito bom! Foi possível desenvolver um cache acessado por várias conexões simultâneas sem um nenhum "lock". Cool!

Ah! Eu falei da velocidade do código? V8 shines!

Eu sei que o Memcached.JS não é o típico exemplo de uso do Node.JS, mas valeu o aprendizado. E reforçou que eu devo ficar de olho no Node.JS e JavaScript!

Idéias Inovadoras e o Network Effect /ou: i dance with myself

Posted: 29 de out. de 2010 | . David Lojudice Sobrinho | tags: , , 1 comentários

Idéias Inovadoras e o Network effect:

1 - Por ser diferente, ninguém entende sua visão e você se sente sozinho. Mas você acredita na idéia e continua a falar sobre ela. É o que você acredita.

2 - A primeira atitude ativa das pessoas é menosprezar sua idéia. Por conservadorismo, por medo ou whatever. Mas você leva na boa e continua com a mesma convicção.

3 - Aparecem os early adopter, normalmente mais interessado no simples fato de serem "early" do que serem "adopter". Mas eles entendem sua idéia e a divulgam com o mesmo vigor que você. Eles costumam ter um grupo restrito de amigos, mas que são um hub para um grupo muito maior.

4 - Ai, com esses hubs, o crescimento de pessoas que conhecem/gostam/compram sua idéia é exponencial. Só deixar o network effect acontecer. Sua idéia agora é uma inovação! Parabéns!

Ainda não entendeu? Tem um video que mostra isso na prática!



i believe you guys!

Apresentação na QCon SP /ou: Ai vai o PPT

Posted: 12 de set. de 2010 | . David Lojudice Sobrinho | tags: , , , 1 comentários

Primeiro, obrigado pelo pessoal que apareceu lá e principalmente para os que questionaram e/ou compartilharam um pouco dos problemas e soluções com a gente! Foi realmente muito bacana! A idéia era essa: compartilhar experiências. Objetivo mais do que alcançado!

Antes que esfrie, ai vai a apresentação:

Apresentação na QCon SP

Posted: 16 de ago. de 2010 | . David Lojudice Sobrinho | tags: , , , 0 comentários

Primeiro queria agradecer ao pessoal que compareceu no DevInSampa (fotos)! Foi muito bacana, com o pessoal fazendo perguntas bem interessantes.

Agora esperamos você na QCon SP!

Case CMS Abril - System of Systems e Arquitetura (quase) Caótica.
Ao aceitar que organizações são sistemas amplos, orgânicos e complexos, devemos adaptar nossa arquitetura a esta realizade. Como viabilizar um enterprise system que se adapte com a velocidade necessária as mudanças de requisitos, conflitos de necessidades dentro deste paradigma?
Para tanto, será explorada a teoria de Sistemas Complexos Adaptáveis e Emergência x BDUF, System of Systems e REST Archtectural Style e como estes conceitos estão ajudando a Abril a construir o parque de aplicações que suporta a publicação de mais de 100 sites e provê mais de 300 milhões de requests/mês.

Apresentação no Dev in Sampa

Posted: 22 de jul. de 2010 | . David Lojudice Sobrinho | tags: , , , 0 comentários

A apresentação no Dev in Sampa foi aprovada. Obrigado pelos votos! Espero você lá!

Apresentação no Dev in Sampa

Posted: 13 de jul. de 2010 | . David Lojudice Sobrinho | tags: , , , 0 comentários

Estamos concorrendo com uma apresentação no Dev in Sampa, que acontece no dia 14/08. Vota lá! :)

REST in Sampa: Case CMS Abril
Ao aceitar que organizações são sistemas amplos, orgânicos e complexos, devemos adaptar nossa arquitetura a esta realizade.
Como viabilizar um enterprise system que se adapte com a velocidade necessária as mudanças de requisitos, conflitos de necessidades dentro deste paradigma?
Para tanto, será explorada a teoria de Sistemas Complexos Adaptáveis e Emergência x BDUF, System of Systems e REST Archtectural Style e como estes conceitos estão ajudando a Abril a construir o parque de aplicações que suporta a publicação de mais de 100 sites e provê mais de 300 milhões de requests/mês.

Link Relations /ou: What the rel?

Posted: 8 de jul. de 2010 | . David Lojudice Sobrinho | tags: , , , 0 comentários

Estamos utilizando representações hipermídia (HATEOAS) a algum tempo já. Uma discussão que fica interessante é quando alguém pergunta: O que eu coloco no rel do link?

Aqui vai o que pensamos sobre o assunto e como estamos utilizando aqui na Abril.


No geral, o rel indica qual a relação do link com o atual recurso. O rel="prev" do Atom, por exemplo, indica que o link vai para a página anterior em relação a página atual. Logo a semântica que o rel de um link carrega depende do recurso atual (página atual), do media type (Atom) e do contexto. Veremos...

1. O recurso atual

Todo rel deve dar um significado ao link em relação ao recurso atual:

  • Mudar o estado do próprio recurso: (um PUT para o rel="self", por exemplo)
  • Recursos relacionados: rel="comentarios", rel="materias_associadas"
  • Navegar para a próxima parte de um fluxo: rel="next"

2. Media type

Alguns media types fixaram em suas especificações os valores que o rel pode receber. Para citar alguns, o Atom tem os seus assim como o HTML.

Problema? Imagine um recurso representado em Atom, com o link rel="related". Este link deve indicar "recursos relacionados" nessa representação. Mas e caso estivéssemos usando um outro media type que também tivesse uma predefinição para rel="related", mas com outro significado? Lembre-se que um recurso pode ser representado em vários media types e os links com rel que indicam qual a navegação do fluxo.

Ainda no caso Atom, caso você queira usar algum outro rel que não esteja na lista, é necessário usar uma URI. Algo como rel="http://blabla.com/proxima_semana". A idéia é que a URI leve a documentação da relação.

3. Contexto

O contexto no qual a representação vai ser usada é relevante. Vejo 3 contextos:
  • Machine-2-Machine na Web: o recurso e suas representações estão visíveis na web.
  • Machine-2-Machine em um ambiente fechado (enterprise integration): o recurso e suas representações estão visíveis apenas em um ambiente onde os clients são conhecidos.
  • Human-2-Machine: o recurso e suas representações são lidos por uma pessoa. No caso da web, esta página HTML que você está lendo serve de exemplo. Mas poderíamos pensar na Web API do twitter e um desenvolvedor lendo o recurso raw da API, tentando criar uma automação.

Respondendo a pergunta: O que eu coloco no rel do link?

O rel deve expressar o mais claro possível a relação do recurso atual com o link. De preferência um subjetivo e não um verbo.

O recurso vai ficar exposto na web? Se sim, tente respeitar as especificações do media type para rel conhecido ("prev", "next", por exemplo), mesmo correndo o risco de conflito entre media types. Crawlers podem navegar pelo seu conteúdo e gerar relacionamento entre eles já que o rel é conhecido. No entanto, micro formatos fariam um trabalho melhor aqui. E para rel não conhecido, não utilizar URIs. Além de complicar o código do client, a URI no rel dificulta a leitura do nosso amigo desenvolvedor externo, além de não mudar a atitude dos crawlers.

Caso o recurso não esteja exposto na web, ignore completamente as especificações do media type e de preferência a rel com nomes claros que seus clients consigam entender facilmente (linguagem ubíqua).

Conclusão

A verdade é que a discussão sobre linked data ainda está aberta nos comitês do W3C.

Enquanto não existe um padrão claro, nossa visão tenta ser pragmática, baseada em cenários conhecidos por nós e baseado também em outros casos de serviços na web.

Chris Anderson sobre iPad /ou: Mais um livro?

Posted: 19 de jun. de 2010 | . David Lojudice Sobrinho | tags: , , 0 comentários

Chris Anderson fez uma apresentação na Abril sobre como sua revista Wired foi feita para o iPad.


Ele é um autor que já citei aqui algumas vezes. Suas matérias Cauda Longa e o Free (que depois viraram livro), trazem idéias bem interessantes.

Nessa apresentação que fez para nós ele explicou como foi o processo de repensar a revista para essa nova forma de distribuição e usabilidade. Foi preciso repensar o formato (o que é uma revista), a forma de trabalho (como gerar conteúdo para a revista impressa, online e iPad), as pessoas envolvidas (Agora temos Vídeo, Áudio, Animações, etc.) e a interatividade com outros meios (Comentários, links para o site? Não!).

Foi bem interessante a palestra, mas infelizmente curta (apenas uma hora e meia), pois o tema rende muito mais. Será que sai outro livro? :)

Update: o novo livro já está a caminho. Também baseado em uma matéria da Wired.

Agile Environment /ou: Let's have some fun...

Posted: 20 de mai. de 2010 | . David Lojudice Sobrinho | tags: , , 2 comentários

Alguns times trabalham...



Outros times, tão se divertindo...

Jim Webber na Abril Digital /ou: No caminho certo...

Posted: 11 de mai. de 2010 | . David Lojudice Sobrinho | tags: , , , , 0 comentários

Ontem assistimos a apresentação (short version) do Jim Webber sobre REST aqui na Abril. Apesar de já ter lido o PDF umas mil vezes, ainda assim foi muito legal rever alguns conceitos e aprender outros novos (como usar OpenID e OAuth, por exemplo).


Depois passamos um tempo conversando sobre o que estamos fazendo aqui (System of Systems, REST, Arquitetura Emergente, Restfulie, Scrum em Escala, etc). O resultado da conversa foi muito bacana. Vou tentar postar mais sobre esses assuntos. O mais legal é a confirmação que estamos indo no caminho certo. Cool!

Histórias de Robôs /ou: Prevendo o Data Deluge...

Posted: 1 de mai. de 2010 | . David Lojudice Sobrinho | tags: , , 0 comentários

Estou lendo Histórias de Robôs Vol. 3 e os dois primeiros contos me deixaram impressionado, pois os dois tratam de como os computadores vão ser utilizados para processar grandes volumes de dados.

Em "Uma Lógica Chamada Joe" (1946), uma rede de computadores tem a capacidade de inferir a resposta para qualquer pergunta, mesmo que a resposta ainda seja desconhecida dos homens, pois essa rede possui muitos dados armazenados.

No conto "Sam Hall" (1953), um computador central guarda todas as informações de todos os cidadãos. Tudo. Cada passo.

Os dois contos são muito bem escritos e os problemas sugeridos pelos autores, por causa desse poder computacional imaginado na época (e que hoje é real), faz você pensar sobre onde estamos indo e se já não somos vítimas de algumas desses males.

Recomendo a leitura.

Diagram.Net on Mono /ou: No Mac também rola...

Posted: 24 de mar. de 2010 | . David Lojudice Sobrinho | tags: , , , 0 comentários

Depois do Linux, foi a vez do Mac. Mérito do Mono.

Data Deluge /ou: Você sabia que o dilúvio estava vindo!

Posted: 17 de mar. de 2010 | . David Lojudice Sobrinho | tags: 0 comentários

Meio atrasado, mas ainda em tempo: a revista The Economist fez uma extensa matéria sobre um assunto que o leitor deste blog já acompanha a um tempo.





Parte da matéria pode ser lida aqui. Outro artigo interessante sobre o assunto (aka Big Data) aqui.

System of Systems e os Sistema Complexo Adaptativos /ou: Arquitetura (Quase) Caótica...

Posted: 27 de jan. de 2010 | . David Lojudice Sobrinho | tags: , , 0 comentários

No último post eu descrevi como estamos pensando a plataforma de publicação e gerenciamento de conteúdo na Abril Digital e como o conceito de System of Systems (SoS) se aplica. Neste post quero discutir algumas características de um SoS.

Toda vez que penso nos conceitos de System of Systems (SoS), me vem a mente a imagem de uma grande revoada, aquela formação no ar por um monte de pássaros voando aparentemente sem rumo, que é caótica e concisa ao mesmo tempo. O que isso tem a ver com o SoS? Veremos...

O interessante sobre as revoadas é saber que os pássaros não têm um chefe dizendo para onde ir. Porém, o grupo se orienta no ar de forma organizada. Mas como isso é possível? O que acontece é que cada pássaro segue 3 regras básicas: evitar bater em um vizinhos ou obstáculos, alinhar vôo para coincidir com os vizinhos e voar uma distância média entre os vizinhos. Assim, um fenômeno emerge e temos a revoada. Ou seja, o que vemos é algo que parece ser criado, mas na verdade aquilo se manifesta daquela forma.

Será que conseguimos criar regras básicas para os sistemas e assim criar um SoS que se manifeste moldando as necessidade de negócio? Essa foi a pergunta que me fiz a alguns meses atrás e neste post estão algumas evidencias teóricas e práticas que dão suporte a idéia.

O fenômeno da revoada é estudado como um Sistema Complexo Adaptativo (Complex Adaptive System ou CAS), assim como outros sistemas complexos, que vão da economia a física, passando pela formação do cérebro ou a um time de scrum, "complexos no sentido de que são diversos e feitos de múltiplos elementos interconectados, e adaptativos porque têm a capacidade de mudar e aprender com experiências passadas". É aqui que o SoS se assemelha a revoada: diverso, interconectado e evolui.

Será isso mesmo? Vamos olhar o SoS através da idéia de um CAS e ver se conseguimos observar algumas propriedades semelhantes:

Emergência: Ao invés de ser prevista ou controlada, os agentes do sistema interagem de forma aparentemente aleatória. De todos esses padrões emergem interações que informa o comportamento dos agentes dentro do sistema e do comportamento do próprio sistema. Não há nenhum grande plano e o resultado apenas surge como resultado dos agentes seguirem algumas simples regras locais.

Mas o SoS não tem um grande plano? Não deve estar alinhado com a estratégia da empresa? Essa é a principal caracterisca que emerge! Ela não é controlada diretamente, assim como você não manda todos os pássaros voarem para um lado ou para outro. No entanto, acredito eu, existem mecanismos para direcionar essas características (veremos mais abaixo).

Além disso, como cada sistema é independente no SoS, eu não ficaria surpreso se um novo sistema criasse algo completamente novo, algo que simplesmente surge, emerge, juntando informações e funcionalidades de vários outros sistemas.

Co-evolução: Todos os sistemas existem dentro de seu próprio ambiente e eles também fazem parte desse ambiente. Portanto, conforme seu ambiente muda, eles precisam mudar para garantir melhor ajuste. Mas porque eles fazem parte do seu ambiente, quando eles mudam, mudam o seu ambiente também, e como ele mudou eles precisam mudar novamente, e assim por diante como um processo constante.

No SoS, isso é sutil. Imagine que um sistema foi alterado e agora ele aceita maior número de requisições. Isso vai fazer com que outros sistemas se conectem a ele e assim, alterando a configuração do SoS todo. O SoS ganha essa nova formação, que acaba por interferir em como os outros sistemas se conectam e assim por diante.

Poderíamos extrapolar para um outro exemplo, em que alguém do time de um sistema X foi trabalhar em um outro sistema ou saiu da empresa, deixando a evolução do primeiro mais lenta. Isso influencia não só no sistema X, mas também em como os outros times vêem aquele sistema, fazendo tomarem decisões se vão ou não conectar a ele. Novamente, a evolução de um sistema influenciou o conjunto que influenciou os sistemas e assim infinitamente...

Sub ideal: Um CAS não precisa ser perfeito para que prospere dentro do seu ambiente. Uma vez que um CAS atinge o estado de ser bom o suficiente, ele trocará eficiência por maior eficácia.

Pensar que um SoS não vai atingir seu estado máximo é perturbador. Mas quando se entende a complexidade de uma empresa, em todos os seus aspectos, o ótimo é inimigo do bom. Ter um SoS que evolua até chegar em seu estado quase perfeito é um grande conforto na verdade. Esperar que ele troque eficiência por eficácia é mais confortante ainda.

Variedade: Quanto maior a variedade dentro do sistema, mais forte ele é. Sistemas adaptativos complexos dependem de ambigüidade, paradoxo e contradições para criar novas possibilidades.

Não vejo problema, por exemplo, em ter dois ou mais sistemas com a mesma responsabilidade, mas que se diferenciam nos requisitos. Que ganhe o melhor! O SoS vai atrair um para o centro e o outro será expurgado. Ou não! Talvez os dois façam sentido e ganhem um número de conexões semelhantes um do outro. Assim como a evolução das espécies, só se consegue a evolução do SoS quando existe variedade.

Para estimular a variedade, não há regras explícitas (pelo menos do ponto de vista de arquitetura de sistemas) em como cada sistema deve ser construído, seja a linguagens, tecnologias ou design interno da aplicação. O importante é que o sistema se comporte bem dentro do SoS (ex.: se comunique usando HTTP e Atom/Hypermedia).

Auto-organização: Não existe uma hierarquia de comando e controle em um CAS. Não há planejamento ou gestão, mas há uma constante reorganização para encontrar o melhor ajuste com o ambiente.

O exemplo acima é válido aqui também. Quem diz se o sistema é bom ou não para o SoS é o próprio SoS. O modo dele expressar isso é a através de conexões que um sistema faz a outro sistema. Quanto mais conexões ele receber, melhor é o sistema para o SoS.

Conectividade: As maneiras pelas quais os agentes em um sistema se ligam e se relacionam entre si é fundamental para a sobrevivência do sistema, pois é a partir dessas conexões que os padrões são formados e o feedback disseminado. As relações entre os agentes são geralmente mais importante do que os próprios agentes.

Uma arquitetura baseada em serviços (SOA) tradicional não tem essa característica fundamental, que é a navegação entre os sistemas de forma transparente. No nosso caso estamos apostando no conceito de Hypermedia, no protocolo HTTP e no formato Atom para realizar essas conexões. As conexões são tão importantes para nós que estamos gastando um tempo considerável nesse problema.

Regras simples: CAS não são complicados. Os padrões emergentes podem ter uma rica variedade, mas, como em um caleidoscópio, as regras que regem a função do sistema são bastante simples.

Será que conseguiremos definir essas regras ou elas aparecerão como resultado da interação dos sistemas? A ser respondido. No entanto, acredito que parte da manipulação do comportamento emergente está aqui, ou seja, na definição prematura das regras. Assim, se as regras estiverem alinhadas com os conceitos básicos do negócio, o SoS não tem outra escapatória a não ser emergir com as características esperadas. Um desafio é definir as regras básicas de forma que elas também possam evoluir.

Sistemas Aninhados: A maioria dos sistemas está aninhados dentro de outros sistemas e muitos sistemas são sistemas de sistemas menores.

É normal que um time médio (de 6 ou 8 devs) designado para implementar um "módulo" do SoS implementem alguns sistemas/serviços, ao invés de apenas um, criando um subsistema dentro do SoS. Observar o que acontece nesses subsistemas é importante, pois talvez ali as regras do SoS não estão sendo aplicadas ou evoluções dessas regras apareçam.

À beira do caos: Teoria da Complexidade não é o mesmo que a Teoria do Caos, que é derivada da matemática. Mas o caos tem um lugar na Teoria da Complexidade em que os sistemas existem em um espectro que vai do equilíbrio para o caos. Um sistema em equilíbrio não tem a dinâmica interna que lhe permita responder ao seu ambiente e vai lentamente (ou rapidamente) morrer. Um sistema em caos deixa de funcionar como um sistema. O estado mais produtivo de se estar é à beira do caos, onde há máxima variedade e criatividade, levando a novas possibilidades.

Do ponto de vista de SoS, o caos deve ser administrado de forma a não extrapolar as expectativas e recursos da empresa. Isso não quer dizer que ele não deva existir! Evitar coisas como ESB, middlewares de governança ou qualquer forma de gerenciamento centralizado é uma maneira do SoS a evoluir e a se auto-organizar.

Fronteiras: A auto-organização implica que o sistema está rodeada por uma fronteira que o contém. Esta condição define o "auto" (self) que será desenvolvido durante o processo de auto-organização. [G. Eoyang & D.J. Conway, 1999]

A fronteira do SoS é definida quando se sabe o que é esperado dele do ponto de vista de negócio. Sem essa definição não existe como o SoS se auto-organizar, já que não existe o "auto". Além disso, é da definição da fronteira que será possível pensar as regras básicas, que deverão levar em conta até onde o sistema vai e onde é que ele termina.

Já gastamos um bom tempo definindo as fronteiras com as pessoas de negócio. Agora, o meu papel junto aos outros arquitetos da plataforma está na definição da comunicação dos sistemas e na definição das regras simples. Esperamos com essas definições criar uma terra fértil para os sistemas do SoS, deixando espaço para que eles cresçam e dêem frutos. Estamos regando diariamente!

Ah! Pensar arquitetura dessa forma traz implicações com as áreas de Infra-estrutura, Desenvolvimento e Scrum Office. Parte dessas implicações já apareceu e foram ou estão sendo resolvidas num trabalho em conjunto muito bacana e com idéias tão legais quanto. They got it!

System of Systems, REST, Hypermedia e HATEOAS /ou: Um dia na vida de um integrador de sistemas...

Posted: 18 de jan. de 2010 | . David Lojudice Sobrinho | tags: , , 1 comentários

Há alguns meses fui chamado, junto com o Julio, para revisar a arquitetura da nossa plataforma de publicação e gerenciamento de conteúdo, que é responsável desde a criação de sites até a autorização de usuários e busca de conteúdo pelos editores. Resumindo (muito) a história, encontramos alguns sistemas monolíticos que represavam os requisitos de uma empresa formada por muitas unidades de negócio com necessidades variadas, muitas vezes até conflitantes. Se a lei de Conway é inevitável, tentar trapaceá-la não foi uma boa idéia. O modelo monolítico estava na nossa mira e pronto para ser derrubado.

Precisávamos de um modelo distribuído, com sistemas menores, de baixo acoplamento e alta coesão (já tinha ouvido falar que outros estavam indo nessa direção). O Julio cunhou o termo "System of Systems" e todos entenderam a idéia de uma forma geral. Um sistema que é formado por outros sistemas, onde um requisito de negócio era dissolvido em requisitos menores para sistemas menores, mas que juntos criavam a funcionalidade que o negócio esperava.

Mas isso não é um modelo de desenvolvimento baseado em componentes tão popular nos anos 90 ou um nome diferente pra Web-services? Quase. Sim, existe um trabalho de separação de interesses (separation of concerns), assim como nos componentes e em WS. Porém, diferente dos componentes ou WS, não tínhamos o protocolo comum entre os sistemas, como nos componentes distribuídos (SOAP, CORBA, DCOM, etc). Precisávamos de um protocolo que pudesse acolher nossos requisitos:

  • Distribuído e descentralizador
  • Escalabilidade: lidamos com milhões de requisições/dia. Escalar é preciso!
  • Tolerante a falhas: não queremos deixar de mostrar uma página para o internauta só porque um dos sistemas esta fora. E sim, eles ficam fora.
  • Fracamente acoplados: quanto menos souber de suas dependências e dos que dependem dele, mais utilizado e fácil de evoluir é um sistema.
  • Facilidade de implementação: trabalhamos com diferentes linguagens e tecnologias. Protocolos abertos, com uma boa base de usuários e libs estáveis é essencial.
  • BASE (Basically Available, Soft state, Eventually consistent): privilegiamos a disponibilidade sobre a consistência dos dados (assim como um sistema para web deve ser)
  • Relacionamento entre recursos: queríamos criar uma rede de sistemas, quase caótica (do ponto de vista de governança) e sem repositório central. Pra isso, a informação sobre a relação entre recursos deveria existir no protocolo de comunicação entre os sistemas e ser entendida por qualquer sistema da plataforma.

Estávamos de olho no REST e parecia o caminho natural, mesmo com suas limitações. Sabíamos que é natural fazer CRUD com o REST, mas e o restante? Um sistema não é formado apenas por CRUD dos dados. Existem perguntas complexas que um sistema deve responder, começando por uma busca de uma palavra num texto até cálculos ou transformações de dados específicos de negócio. RPC? Talvez...

Nessa época caiu na minha mão (via @Dimas) a apresentação "REST in Practice - A Tutorial on Web-based Services", do Jim Webber, Savas Parastatidis e Ian Robinson, nomes que já tinha ouvido falar ao pesquisar sobre SOA e REST. Numa primeira visita, eu pensei que a apresentação era sobre a história das tentativas de Web-services e seus formatos para depois exaltar o quão bom o REST é. Na segunda olhada, com mais cuidado (afinal são 302 slides), me chamou a atenção o conjunto dos conceitos de REST com Hypermedia, HTTP como o protocolo de aplicação, Atom e como tudo isso deveria ser a base para uma arquitetura de um sistema distribuído. Afinal, isso tinha dado certo uma vez: a web funciona assim! Aliás, se olhar os requisitos da nossa plataforma ali em cima, vai ver que a semelhança é grande. Ou seja, parecia que eu tinha encontrado o que estava procurando.

Hypermedia é um conceito que foi citado como parte fundamental do REST no doutorado de Roy Fielding (foi neste trabalho que o termo REST apareceu), mas que foi esquecido no meio do caminho. O foco dado foi exclusivamente sobre o recurso, porém, ao esquecer o conceito de hypermedia, deixou-se de lado como conhecer e navegar nesses recursos.

Utilizar o HTTP como protocolo de aplicação e não apenas como protocolo de transporte (discussão antiga do pessoal do SOAP vs REST) já era algo que desejávamos, mas ao olhar o HTTP de perto, encontramos muito mais do que GET, POST, PUT e o DELETE. Ao entender os verbos, os códigos de retorno e os media types, tem-se um protocolo muito mais complexo e pronto para sistemas distribuídos.

E quando menos se esperava, eis que um padrão XML aparece na nossa frente: Atom. Ali no Atom é que se encontram as ferramentas para tornar o hypermedia viável entre sistemas, pois o conceito de links faz parte do padrão.

Parecia que tínhamos encontrado o que queríamos. Bom, pelo menos no campo teórico... Ao tentarmos implementar, esbarramos em alguns problemas com as libs que dão suporte a esses conceitos. Por exemplo, a especificação Atom dá suporte a uma série de features que não encontramos implementadas em nenhuma lib (Ruby ou Java) e que seriam importantes para nós. E se o HTTP é completo (e, como disse antes, complexo) ao dar suporte a sistemas distribuídos, por outro lado as libs acabam escondendo informações ou bagunçando a idéia do protocolo na tentativa de simplificá-lo.

Para nossa sorte, encontramos o Guilherme Silveira, que já estava envolvido nas discussões sobre REST, Hypermedia e HATEOAS (Hypermedia as the Engine of Application State) e estava implementando o Restfulie, uma lib que busca o REST no seu conceito original, ou seja, com os conceitos de hypermedia e transição de estado, além de ser amigável com o protocolo HTTP em toda sua complexidade.

A história ainda não terminou. Na verdade está apenas no início. Estamos começando a implementar esses conceitos nos novos sistemas, refatorando os antigos sistemas monolíticos para sistemas menores, e ainda começamos a ajudar o Guilherme na evolução do Restfulie. Temos um longo caminho pela frente na construção da nova plataforma, que vai inclusive colocar todas essas idéias a prova. Porém, mais do que nunca, acredito que estamos no caminho certo.

Escalabilidade de web sites /ou: Como é que eles conseguem?

Posted: 3 de dez. de 2009 | . David Lojudice Sobrinho | tags: , , 3 comentários

Depois de 6 meses de pesquisa, estou disponibilizando aqui o meu trabalho sobre escalabilidade de web sites que fiz para o meu curso de Pós-graduação.

Apresento no trabalho a análise das arquiteturas de web sites que estão entre os principais sites da internet. Tentei identificar o que faz, do ponto de vista de arquitetura de software, com que eles consigam atender um número muito alto de usuários.

Ai vai: pesquisa e a apresentação


A estrutura empresarial e a qualidade de software /ou: Galera não tá se falando direito...

Posted: 11 de out. de 2009 | . David Lojudice Sobrinho | tags: , , , 0 comentários

Esta cada vez mais claro que o desenvolvimento de software é mais do que uma atividade entre pessoas e computadores: é uma atividade social antes de tudo. É social pois depende de comunicação para acontecer.

Dentro de uma empresa a comunicação entre as pessoas passa por hierarquias, processos, etc. que quanto mais complexos, maior serão os ruídos. Ou seja, a qualidade da entrega é extremamente afetada pela estrutura organizacional (Mythical Man Month). Não só a qualidade é afetada mas também a própria entrega toma forma dessa estrutura (Conway's law). Lembra do Waterfall, RUP, XP-SCRUM, etc.? No fundo todos esses processos tentam atacar o problema de comunicação entre os membros de um projeto, seja usando os fantasmagóricos documentos de levantamento, os enigmáticos diagramas UMLs, continuos integration, daily team meetings e afins.

Mas se a qualidade de um software é influenciada pela organização (e como ela gerencia a comunicação), como medir ou prever essa qualidade? Qual métrica organizacional usar para saber se um software vai ser bem construído? Mas e as outras métricas de software (quantidade de linhas de código, cobertura de teste, complexidade ciclomática)? Elas são boas? Afinal, se a organização influencia tanto assim na qualidade da entrega, essas métricas não fazem muito sentido, certo?

Na tentativa de responder a essas perguntas, o ótimo paper "The Influence of Organizational Structure On Software Quality: An Empirical Case Study" estudou as métricas de software e as organizacionais do desenvolvimento do Windows Vista. Eles analisaram dados do controle de versão (libs, quantidade de updates, etc.), adicionaram dados dos funcionários (hierarquias, quantidade de pessoas no time, tempo de empresa, promoções, etc.) e dados de bugs do Vista depois da entrega. Analisando tudo isso (aprox. 50 milhões de linha de código, milhares de pessoas e muitos bugs!), foi possível mostrar que as métricas organizacionais são mais eficientes que as métricas de software (84% contra 79%, no melhor caso) em prever a qualidade do software entregue.

Lembrando que essa é a primeira pesquisa nesse sentido e talvez os números só se apliquem nesse cenário, mas ainda assim reforça (agora com números) o que antes só se tinha a impressão.

Isso que dizer que na próxima vez que você for fazer um check-in no seu source control, pode aparecer uma janela te perguntando qual seu cargo, quem é seu chefe e quantas pessoas tem na sua equipe e, depois do "ok", a IDE vai te mostrar as partes do código que tem uma grande chance de dar erro. Não porque tem muitos IFs ou o teste não passou por ali, mas porque a "galera não tá se falando direito".

RefList Cache /ou: Piece of cake!

Posted: 17 de set. de 2009 | . David Lojudice Sobrinho | tags: , , , 0 comentários

Quem já usou cache para uma aplicação web sabe: o que no começo parece simple, é mais complicada do que parece.

Um dos maiores problemas de cache é a invalidação. Quando invalidar? Onde invalidar?

Vou contar a história do projeto que participei a um ano atrás, o Gostei.com, onde o uso de memcached é extenso. Tínhamos o seguinte problema: um mesmo post pode aparecer em várias listas, sendo que estas listas poderiam ter ordenações e filtros diferentes. Mas se o post sofresse alguma alteração, como um novo voto, o número de votos tinha que ser igual em todas as listas.








A primeira abordagem foi um pouco ingênua: serializar e guardar no cache a lista inteira (List<Post>), incluindo o post junto. O problema é que a quantidade de votos de um post pertence a classe Post, tínhamos uma quantidade de votos diferente em cada lista (lista diversão-mais_votados e todos-mais_recentes, por exemplo) para o mesmo post. Era impossível saber em quais listas aquele post foi cacheado.

A solução foi usar o que chamamos de RefList Cache. Ao invés de guardar a lista com os posts, cacheamos a lista com os IDs dos posts (List<Guid>) e para cada post existe apenas um lugar no cache (uma key única). Assim, quando um post sofrer alguma alteração, basta atualizar invalidar o cache em um único lugar. Graças a um recurso do memcached (get_multi), é possível ter o RefList e todos os item com apenas duas chamadas.





Piece of cake! Quer dizer... nem tanto. Ainda tem um problema. Nada garante que todos os IDs da RefList vão estar no cache. O que fazer? Um dos recursos da lib que criamos é o conceito de hierarquia de repositório, onde é possível dizer a ordem dos locais onde a lib vai procurar pelo dado (Local Cache, Memcached, DB). Por exemplo, caso metade dos posts estiver no cache, a lib vai tentar pegar a outra metade no banco.

Aqui tem uma apresentação que ajuda a explicar a idéia: PPT.

Sweet! :)

Stil 2009 /ou: Huge Burgers!

Posted: 16 de set. de 2009 | . David Lojudice Sobrinho | tags: , 0 comentários

E eu estive no Stil 2009. Quatro dias intensos de apresentações e workshops acadêmicos sobre computação lingüística (justo Eu, que nunca fui um grande expert na segunda área, como alguns leitores desse blog já notaram).

Como não sou pesquisador nem professor, fui de xereta para entender melhor o que é essa tal "computação lingüística" e ver onde estamos em relação a pesquisas aqui no Brasil. Afinal onde eu trabalho produz muito texto e não é difícil pensar em coisas interessantes que se pode fazer com todo esse texto.

Como podia-se esperar, assisti trabalhos/apresentações excelentes e também trabalhos menores, porém, no geral, me agradou bastante. Conheci bastante gente e pude aprender mais sobre o tema. Aquele livro que fica na minha mesa já não me assusta tanto assim.

Uma coisa chamou bastante a minha atenção: eu era a única pessoa representando uma empresa! Eram mais de 100 pessoas e só uma delas (Yo!) tinha interesses não acadêmicos no que estava sendo apresentado. Existe uma distância entre a academia e as empresas? Não preciso nem comentar...

No mais, São Carlos não tem lá muita coisa pra fazer e, talvez por isso, muito simpática. Ah.. vale destacar o tradicional lanche do interior (#huge #WTF!?!).