Mostrando postagens com marcador system of systems. Mostrar todas as postagens
Mostrando postagens com marcador system of systems. Mostrar todas as postagens

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...

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.

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!

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.