Vamos iniciar a publicação de estudos de caso de startups e empresas brasileiras no blog oficial da Amazon Web Services no Brasil. É um prazer ouvir as estórias de quem está empreendendo e utilizando a plataforma da Nuvem da Amazon para alavancar seus negócios. Se você também quer contar sua estória para nós, entre em contato conosco!
Hoje o caso é da empresa Blanq, que tem um produto chamado Simbo. O Lucas Teixeira, um dos sócios, é que nos conta sobre sua empresa, seu produto e sua experiência com a Nuvem da AWS:
Nós somos uma empresa chamada Blanq com pouco mais de um ano de vida. Estamos situados em Londrina, norte do Paraná e atuamos no desenvolvimento de ferramentas voltadas para o mercado imobiliário. Apesar de desenvolvermos ferramentas personalizadas para clientes deste ramo, nosso produto mais importante é um SaaS para imobiliárias e corretores independentes chamado SIMBO (www.simbo.com.br). O produto oferece todo o suporte comercial para estes profissionais, desde a manutenção da carteira de clientes e imóveis até a manutenção multi-usuários da imobiliária e confecção automatizada de um website para exposição destes imóveis. Meu nome é Lucas Teixeira, sou um dos sócios da empresa e responsável pela definição da aplicação, desenho e manutenção da infra estrutura e servidores além de também trabalhar na codificação do sistema.
Os produtos e serviços da AWS estão distribuídos por toda nossa aplicação, desde os níveis mais baixos como servidores e discos, até a outra extremidade do negócio, já no cliente final, no armazenamento de imagens e assets estáticos da aplicação.
Hoje utilizamos uma grande variedade dos produtos Amazon, entre eles:
• Route53
• EC2
• EBS
• ELB
• Cloudwatch
• S3
• Cloudfront
• SNS para notificações do Cloudwatch
• RDS - MySQL
• SimpleDB
• SES
• ElastiCache
• Autoscaling
Utilizamos a linguagem de programação Java e Groovy, e também o framework para desenvolvimento WEB Grails da SpringSource. Todos os nossos sistemas e aplicações estão neste modelo de aplicação.
Nós utilizamos o Java SDK da Amazon direta e indiretamente em nossas aplicações. Diretamente pois todo o nosso mecanismo de deploy e publicação de novas versões e atualizações da aplicação utiliza uma ferramenta que criamos para isto, é uma ferramenta que entende nosso contexto e configuração particular e em cada publicação de nova versão, cria um novo parque de máquinas, testa as instâncias uma a uma para garantir disponibilidade e apenas depois disto, autoriza que novos clientes utilizem estas instâncias enquanto remove antigos servidores dos balanceadores de carga (ELB).
Além disto, digo que utilizamos o Java SDK da Amazon indiretamente, pois nossa aplicação utiliza um plugin Grails (grails-aws: http://github.com/blanq) para intermediar toda a comunicação entre a aplicação e os serviços da Amazon. O plugin foi desenvolvido por nós mesmos, e disponibilizado de modo opensource para a comunidade. Hoje é o plugin usado por todos que desejam este interfaceamento entre aplicações Grails e os serviços da Amazon.
Iniciamos com a AWS obviamente pelo planejamento de baixos custos e necessidade de investir pouco dinheiro no início da empresa. Porém após utilizar e entender os serviços da amazon com prudência, acabamos por nos tornar dependentes da facilidade e confiabilidade que os serviços nos oferecem. Hoje, não temos nem necessidade, e muito menos pretensão de deixar de utilizar estes serviços, uma vez confiamos nisto como diferencial para nosso produto.
Fizemos alguns orçamentos antes da contratação do serviço, e o a única outra alternativa viável tecnicamente, em outro conceituado provedor de cloud/hosting se mostrou inviável financeiramente, uma vez que nossos custos triplicariam por não podermos contar com a possibilidade de aumentar e diminuir o parque de máquinas conforme nossa necessidade (e pagar um preço proporcional por isto).
Em relação a economia no tempo de trabalho, o prinicipal ponto de ganho é em relação a publicação de novas versões de nossa aplicação, após o desenvolvimento de nossa ferramenta de publicação, conseguimos criar um novo parque de máquinas e publicar atualizações em 10 minutos, enquanto um processo normal e manual levaria cerca de 1 hora pra o mesmo resultado.
Acredito que quando você está desenvolvendo aplicações para rodar em um ambiente cloud, você deve se desapegar de tudo que é físico e mantém um estado em sua arquitetura. Aprende a não depender de disco rígido para armazenamento de arquivos, a não ter pontos únicos de falha em sua aplicação como "um servidor de banco de dados", ou então "um servidor de envio de e-mails", e entende que a AWS possui serviços para preencher estes nós de sua estrutura.
A idéia é conseguir desenhar e desenvolver uma aplicação simples e que consiga estar sendo servida por 1 ou por 100 servidores ao mesmo tempo, sem que isto impacte na maneira com que ela funciona ou se comporta.
Do ponto de vista administrativo, nós nos admiramos pela quantidade de serviços lançados com o tempo, e ainda mais com a política de diminuição de preço dos serviços oferecidos pela Amazon de tempos em tempos, e do ponto de vista técnico, a segurança que temos fazendo que nosso produto seja utilizado por todos nossos clientes, dependendo desta infra estrutura é um grande diferencial.
Nós sempre testamos e estudamos os novos serviços que a AWS lança e anuncia. A cada novo produto, nos perguntamos onde é que poderíamos encaixá-lo em nossa arquitetura e o que ganharíamos com isto. Planejamos utilizar tantos bons (e necessários) produtos quanto a AWS anunciar.
Ficamos muito felizes por termos sido escolhidos para compartilhar um pouco de nossa experiência com os clientes e simpatizantes da Amazon Web Services. Através deste resumo, esperamos conseguir dividir não só nosso conhecimento, mas também nossa satisfação em utilizar estes produtos.
-- José Papo
Esta arquitetura nos permitiu que no pouco tempo que este texto foi escrito (cerca de 3 meses), nossa arquitetura pudesse ser duplicada de tamanho, contando hoje com 8 instâncias para atender a todos os nossos clientes. Muito obrigado a AWS.
Posted by: Account Deleted | 07/31/2012 at 04:02 PM