Este post faz parte de uma série chamada NAW (Nova Aplicação Web) que visa acompanhar a criação de um serviço web da idéia ao lançamento. Todos os posts da série iniciam com as letras NAW.

Hoje fizemos mais uma bateria de Brainstorm de nomes para a NAW. Acho que chegamos num nome bom, já registrei o domínio e a partir de agora vou perguntar se esse nome soa bem para uns amigos estrangeiros. Pode parecer neura, mas eu só pergunto sobre o nome depois de tê-lo registrado. Fora o pessoal que foi convidado para fazer parte do grupo, que já tem acesso a um documento no Google Docs com o resultado de todos os brainstorms realizados.

Montando a equipe

Neste momento minha preocupação é montar a equipe que vai trabalhar neste projeto. Passando o carnaval, vou conversar com cada pessoa que eu já convidei para participar da equipe para saber do real interesse e disponibilidade de cada um para esse projeto.
Talvez não role de fazer com eles, não sei se todos vão apostar nisso e terão algum tempo livre para dedicar. Neste caso terei que apresentar a idéia para outras pessoas, mas isso não é um problema, pois já tenho a quem apresentar.

Para tudo temos que ter um plano B e nesse caso já montei um plano C. Caso não consiga fechar a equipe com a galera que já apresentei, irei mostrar para um outro pessoal e caso não role também, já tenho em mente três possíveis investidores para o negócio. A princípio não gosto da idéia de trabalhar com o dinheiro dos outros, mas também não tenho restrições. Esta é minha última opção.

Deixo aqui um rascunho inicial dos cargos que penso estarem envolvidos, veja bem, muito provavelmente uma pessoa vai ocupar um ou mais cargos na equipe.

• Administrador – este cara vai tocar o barco, ou seja, fazer o projeto andar, montar as apresentações, definir estrutura do site, modelo de cobrança, estratégia de divulgação, apresentação das informações, implementação de relatórios e pesquisa de mercado, enfim, pensar em tudo que não é o desenvolvimento em si da aplicação;
• Designer – este cara vai criar uma identidade visual, com logomarca, apresentações, site, template de e-mails, etc;
• Programador Rails – este cara vai desenvolver a aplicação “de frente”, ou seja, a interface que é utilizada pelo usuário
• Programador Perl/Daemons – este cara vai programar a interface entre a aplicação de frente e os serviços que rodam no servidor, bem como daemons de controle e processamento;
• Analista de infra-estrutura e segurança – este cara vai montar o desenho do cluster de servidores, vai pensar nas soluções de virtualização, escalonamento e conectividade entre os servidores e serviços bem como montar um projeto de HA com load balancer, firewall etc..

Eu ainda não sei qual dimensão isso irá tomar, não esqueço a idéia de começar bem pequeno e se preocupar com escala no futuro, mas a natureza desta aplicação me faz pensar que devo pelo menos ter uma equipe de 5 pessoas e montar uma estrutura que seja fácil de escalonar.

Volto a escrever sobre a NAW depois do carnaval.

Abraços a todos

Utilizar web-services é muito bom, mas exige alguns cuidados. Nesta semana tive um problema que nunca imaginei que pudesse acontecer.

A conexão do meu servidor com o servidor do web service foi interrompida de uma hora pra outra.

Demorou um tempo para acharmos a causa e até agora o problema não foi resolvido por completo. Já conseguimos uma solução paleativa, mas de qualquer forma ainda preciso investigar o por quê do problema ter ocorrido.

Depois de muito chat com os donos do web service, detectamos que o firewall deles começou a bloquear as minhas conexões pois estava entendendo como sendo um ataque hacker. Muito estranho, mas o que acontecia é que o meu servidor começou a abrir quatro sockets para cada conexão sendo todos eles com a mesma “source port”. Por este motivo que o firewal começou a bloquear as conexões.

Agora, por que isso começou a acontecer ninguém sabe. Os possíveis motivos seriam: a) atualização de algum pacote no meu servidor, b) alteração na configuração do gateway do meu datacenter, c) mudança de regras no firewall do web service.

Das duas uma, ou meu servidor sempre mandou os sockets desta maneira e o firewall do web service não detectava antes, ou ele passou a mandar a partir de uma atualização de pacote no meu servidor ou a partir de uma mudança no gateway do datacenter.

Como eu não realizei nenhuma atualização no servidor, só restam as opções do datacenter ter alterado alguma configuração no gateway ou o web service ter alterado as regras no firewal.

O problema é que ambos dizem que não realizaram nenhuma alteração!

A solução paleativa, foi utilizar o servidor secundário do web service. Eles me passaram o ip e eu configurei no hosts para que o domínio do web service fosse atendido primeiramente pelo ip secundário. Isso resolveu o problema, mas não corrigiu a causa.Já apliquei um patch do grsecurity no kernel, que corrigiria uma possível falha. Não adiantou. Neste final de semana irei atualizar todos os pacotes do servidor, como solicitado pelo meu datacenter, e verei se isso resolve.

Estou acreditando que meu datacenter forçou essa configuração, para poder monitorar as conexões, uma vez que o meu servidor fazia muitas conexões por minuto ao servidor do web service. Mas só poderei cair em cima deles depois que atualizar meu sistema.

Situação delicada e neste caso o melhor é prevenir. Por isso o motivo deste post. Eu não imaginava que isso pudesse acontecer e me pegou de surpresa… Agora já estou me mexendo para evitar que isso aconteça novamente.

Ai vão algumas dicas para evitar este tipo de problema com conexões à web services.

• Primeiramente é interessante que você tenha ao menos dois servidores de aplicação, neste caso se der problema em um, você terá o outro de backup. O ideal é que cada um destes servidores estejam em datacenters diferentes, pois caso um datacenter aplique uma política de segurança que cause este problema, você terá tempo de tentar resolver o problema e até configurar um terceiro servidor, enquanto o de backup fica em produção.
• Comunique ao web service que você pretende fazer diversas conexões ao serviço deles. Pergunte sobre a política de segurança e sobre as regras do firewall. Se possível passe o IP do seu servidor para que eles possam colocar numa “white list”
• Comunique seu datacenter sobre o número de conexões que serão feitas á um mesmo IP (do web service). Pergunte sobre as políticas de segurança. Solicite que não haja nenhum tipo de interferência nos pacotes enviados do seu servidor para o servidor do web service.
• Prepare um túnel reverso de SSH, desta maneira, caso você não consiga realizar a conexão, você consegue roteá-la por outro servidor, chamado de “middle”, de forma que seu servidor se conecte ao middle e o middle se conecte ao web service.

Bem, espero poder ajudar com a experiência que tive. Deixem seus comentários caso tenham alguma sugestão para este caso.

Abraços e até a próxima.