Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Desafio de crescer

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Desafio de crescer

  1. 1. Os desafios de crescer: um estudo de caso da plataforma de educação a distância redu Guilherme Cavalcanti Líder Técnico da plafaforma de aplicativos
  2. 2. Apresentações • Guilherme Cavalcanti • Desenvolvedor Web desde 2007 • Granduando, CIn-UFPE • Co-fundador do Redu • Líder técnico do time da plataforma de aplicativos @ Redu • Twitter/Delicious/Github: • /guiocavalcanti
  3. 3. Histórico do Redu • Plataforma de educação a distância construída numa estrtura de rede social 2010 @ Porto Digital 2009 @ CIn
  4. 4. Equipe • 15 pessoas • Designers • Desenvolvedores • Pesquisadores • Negócio Estamos contratando! jobs@redu.com.br
  5. 5. Redu-labs • CCTE • 11 pesquisadores associados
  6. 6. Principais funcionalidades
  7. 7. Principais funcionalidades
  8. 8. Principais funcionalidades
  9. 9. Principais funcionalidades
  10. 10. E muito mais • M-learning • Visualizações semânticas • Construção de conteúdo de muitos para muitos
  11. 11. Introdução
  12. 12. Overview da arquitetura Main server Database Job queue management system Asynchronous e-mail delivering system Analytics server Database Analytics aplication Private REST API Models Main application Web front-end Public REST API Models Controllers Resource conversion server Document engine Video engine Static files server Static files Websocket server PubSub Engine
  13. 13. Technology stack Main server Database Analytics server Analytics aplication Main application Resource conversion server Document engine Static files server Websocket server
  14. 14. Estratégia • Plataforma de aplicativos • Visualizações semânticas • Velocidade na entrega de funcionalidades
  15. 15. Contexto e Problemas
  16. 16. The mythical man-month • Equipe de desenvolvimento • Dezembro de 2011: 4 pessoas • Janeiro de 2012: 12 pessoas x3
  17. 17. Problema 1: Velocidade • Afetou seriamente a velocidade • Acentuou problemas que já existiam
  18. 18. Problema 1: Velocidade Main application Web front-end Public REST API Models Controllers • Excessivamente acoplado • Problemas de deploy • Complexo de modificar • Reuso pobre
  19. 19. Problema 2: Plataforma de aplicativos • Tudo deve ser uma plataforma para novos aplicativos • Disponibilizar API pública
  20. 20. Service oriented architecture
  21. 21. Composição de serviços • Isolamento de funcionalidades em termos de serviços • Comunicação através da rede
  22. 22. Serviço For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interaface. Werner Vogels, Amazon
  23. 23. Resultados esperados • Times podem ser menores • Usar as tecnologias que mais se adequam ao problema • Zero downtime deployment • Complexidade dividida entre serviços • Redução dos caminhos de comunicação • Todas as funcionalidades já seriam plataform- enabled
  24. 24. Premissas
  25. 25. Premissas • Justificam o particionamento de uma funcionalide para um serviço
  26. 26. Velocidade • Irá acarretar um aumento da velocidade na entrega de valor?
  27. 27. Transversalidade • Será utilizado em vários serviços? • Ferramentas de infraestrutura (ex.: e- mail delivery, document conversion)
  28. 28. Requisitos bem definidos • Ciclo construção-feedback estável?
  29. 29. Frequência de leitura e escrita • Muito acessado ou atualizado? • Ponto único de otimização
  30. 30. Proposta 0.0.1-alpha
  31. 31. Arquitetura proposta Server Main application Service Server Service Service Service Relational databases Graph database Document database Messge bus • Aplicação principal se comunica via HTTP • Serviços se comunicam através de um message bus
  32. 32. Exemplo: activity stream • Aplicação • Logica de UI • Chama o serviço propriamente dito • Serviço • Regras de negócio e comunicação Server Activity Stream application Server Activity Stream service Databases server Document database Authorization service Message bus
  33. 33. Base de código isolada • Times pequenos e isolados • Liberdade de escolha de SGBD • Decisões de projeto mais descentralizadas • Menos caminhos de comunicação
  34. 34. Obrigado :)
  35. 35. Referências • http://confreaks.com/videos/675-rubyconf2011-rails-services-in-the-walled-garden http://www.slideshare.net/kaiwren/rails-services-in-the-walled-garden • http://www.amazon.com/Service-Oriented-Design-Addison-Wesley-Professional-Series/dp/0321659368 (redu- dev/architecture/) • http://www.eventials.com/rubyconfbr/recorded/ M2UzZTJkMzY2MzdiNTg2NTUxNWM1MzI3NWY1YjRhMzYjIzQwMQ_3D_3D?lang=en http://www.eventials.com/presentation/download/ M2UzZTJkMzY2MzdiNTg2NTUxNWM1MzI3NWY1YjRhMzYjIzQwMQ_3D_3D • http://lanyrd.com/2011/mwrc/sdcgz/ (We need to found this video), presentation: http://www.slideshare.net/ ChrisWyckoff/refactor-your-monolithic-rails-app-to-a-soa • http://lanyrd.com/2011/mwrc/sdchb/ (We need to found this video) • http://rubysource.com/soa-for-the-little-guys/ • http://blog.8thlight.com/uncle-bob/2012/02/01/Service-Oriented-Agony.html • About thrift (infrastructure to enable cross language communication) http://thrift.apache.org/static/files/thrift-20070401.pdf http://thrift.apache.org/

×