Desafio de crescer

35
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

Transcript of Desafio de crescer

Os desafios de crescer: um estudo de caso da plataforma de

educação a distância redu

Guilherme CavalcantiLíder Técnico da plafaforma de aplicativos

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

Histórico do Redu

• Plataforma de educação a distância construída numa estrtura de rede social

2010 @ Porto Digital

2009 @ CIn

Equipe

• 15 pessoas

• Designers

• Desenvolvedores

• Pesquisadores

• Negócio

Estamos [email protected]

Redu-labs

• CCTE

• 11 pesquisadores associados

Principais funcionalidades

Principais funcionalidades

Principais funcionalidades

Principais funcionalidades

E muito mais

• M-learning

• Visualizações semânticas

• Construção de conteúdo de muitos para muitos

Introdução

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

Technology stack

Main server

Database

Analytics server

Analytics aplicationMain application

Resource conversion server

Document engine

Static files server

Websocket server

Estratégia

• Plataforma de aplicativos

• Visualizações semânticas

• Velocidade na entrega de funcionalidades

Contexto e Problemas

The mythical man-month

• Equipe de desenvolvimento

• Dezembro de 2011: 4 pessoas

• Janeiro de 2012: 12 pessoasx3

Problema 1: Velocidade

• Afetou seriamente a velocidade

• Acentuou problemas que já existiam

Problema 1: Velocidade

Main application

Web front-end

Public REST API

Models

Controllers

• Excessivamente acoplado

• Problemas de deploy

• Complexo de modificar

• Reuso pobre

Problema 2:Plataforma de aplicativos

• Tudo deve ser uma plataforma para novos aplicativos

• Disponibilizar API pública

Service oriented architecture

Composição de serviços

• Isolamento de funcionalidades em termos de serviços

• Comunicação através da rede

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

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

Premissas

Premissas

• Justificam o particionamento de uma funcionalide para um serviço

Velocidade

• Irá acarretar um aumento da velocidade na entrega de valor?

Transversalidade

• Será utilizado em vários serviços?

• Ferramentas de infraestrutura (ex.: e-mail delivery, document conversion)

Requisitos bem definidos

• Ciclo construção-feedback estável?

Frequência de leitura e escrita

• Muito acessado ou atualizado?

• Ponto único de otimização

Proposta0.0.1-alpha

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

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

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

Obrigado :)

Referências

• http://confreaks.com/videos/675-rubyconf2011-rails-services-in-the-walled-gardenhttp://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=enhttp://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/