B2B no Mercado Eletrônico: Do SaaS ao PaaS

425 visualizações

Publicada em

Track: Arquiteturas que Você Sempre Quis Conhecer
Abstract:
Fundada em 1994, Mercado Eletrônico é uma plataforma de negócios focada em compras e vendas entre empresas com grandes clientes enterprise, e dezenas de milhares de fornecedores transacionando bilhões anualmente. A plataforma enfrenta desafios arquiteturais típicos de um SaaS, mas com necessidades de customização fora da média.
Vamos mostrar a evolução, ao longo de mais de uma década, de um sistema single-instance, multitenant extremamente customizável, desde simples conjuntos de checkboxes até código sofisticado de customização e metadados.
São mostrados detalhes da arquitetura e implementações como os processadores de fila e brokers, combinando tecnologias proprietárias e open source, além de métricas operacionais, caching, e geolocalização. Em suma, veremos a arquitetura da nova plataforma de execução de aplicações, que efetivamente eleva a solução ao patamar de PaaS, combinando metadados, código customizado, dados compartilhados e entidades bem definidas, com o poder da JVM, código dinâmico e NoSQL.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
425
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Multi instance é apenas hosting glorificado, ou outsourcing de TI.
  • Claro: Podemos usar orientação a objetos.
  • B2B no Mercado Eletrônico: Do SaaS ao PaaS

    1. 1. Do SaaS ao PaaS no Mercado Eletrônico Ricardo Pardini, qCon SP ‘13
    2. 2. Quem? • Ricardo Pardini, CTO, Mercado Eletrônico – Lead Developer (desde 2001) – SysAdmin – Architect – Guilty (forever) • http://pardini.net/blog
    3. 3. • Desde 1994! BBS > Web > SaaS > PaaS • B2B: entre empresas • SRM: o “contrário” do CRM • Procurement: transacional: pedidos, cotações • R$ 60 bilhões/ano • 60k usuários e 100 grandes compradores • Enterprise: grandes clientes corporativos
    4. 4. Enterprise??
    5. 5. Enterprise • “enterprise software is often available as a suite of customizable programs” (Wikipedia) • Grande necessidade de customização • Integração com ERPs também customizados • Restrições “técnicas” (firewalls... browsers...) • No Brasil adoramos customizar
    6. 6. SaaS: Software as a Service • “Era só um website...” • Single-instance • Multi-tenant + Funcionalidade padrão -Custo de operação e investimento inicial • Similar: SalesForce (1999), Basecamp (2004)
    7. 7. Simplicidade (<2001) Comprador Cotação de Preços Fornecedor Pedido de Compra “Complexidades” • Impostos • Integrações
    8. 8. SaaS + Enterprise • Customizar! – Mas, não era padrão? – Manter as customizações ‘vivas’ – GMUDs • Grande necessidade de recursos • Inovar!
    9. 9. “Feature Gating” if (gk_check('abc')) { do_abc(); } else { do_old_stuff(); } Gatekeeper (Facebook) Feature Bits (M.Fowler)
    10. 10. Dados específicos demais ALTER TABLE pessoa ADD COLUMN corDoPagagaio VARCHAR(20); public String getCorDoPapagaio() { /* ... */ } public void setCorDoPapagaio(String cor) { /* ... */ }
    11. 11. Atributos ao resgate
    12. 12. Mais customizações / Limites • Scripting • Processadores de filas customizados • OOP: class per client, interfaces • Limitações – Fluxos e entidades básicas tem de ser respeitados – Disponibilidade de pessoal interno – Audits / GMUDs – Reuso
    13. 13. PaaS: Platform as a Service • Infrastructure + Solution Stack • Heroku, Azure, Force.com, CloudFoundry, AppEngine • Serviços comuns (auth, storage) • Deploy facilitado • Cliente escreve funcionalidade ‘do zero’ • Ou, customiza pré-existente
    14. 14. PaaS no Mercado Eletrônico • Gerenciar customizações em todos os níveis – Look and Feel – Funcionalidades – Modelos de dados • Permitir compartilhamento de pacotes funcionais entre clientes, ou top-down • Agregar funcionalidade padrão comum (CRUD, analytics, APIs – backend as a service) • Desenvolvimento de customizações por terceiros
    15. 15. Arquitetura a um KM de altura Metadados Pré- definições Dados compartilhados Código Custom Composição de Aplicações em Tempo de Execução Customizações Dados Metadados
    16. 16. Pré-definição (“padrão de mercado”) Especialização do Metadado Interfaces e Abstract Classes Implementações Específicas
    17. 17. Metadados • Objetos de dados – Campos, tipos, validações – Similar a tabelas SQL – Eventos • Documentos – Composição de objetos – Listas e relacionamentos complexos – Handlers completos
    18. 18. Materialização • Geração de bytecode Java – Javassist – CGLib – ASM – JSR 199: Java Compiler API • Groovy! – Completo (Generics, Annotations, etc) – Captura o bytecode gerado
    19. 19. Embedded Groovy GroovyClassLoader gcl = new GroovyClassLoader(); Class clazz = gcl.parseClass("class Custom1 implements MyIntf{...}"); Object aScript = clazz.newInstance(); MyIntf obj = (MyIntf) aScript; obj.metodoDaInterface();
    20. 20. Funcionalidades padrão • Equivalente ao Scaffolding, mas em runtime • CRUD • Batch Load/Export • Analytics • API generation – Criação dinâmica de uma Bus do Apache CXF – REST (WADL) e SOAP (WSDL)
    21. 21. Customização • Na materialização, capturar o bytecode gerado • Entregar ao cliente um JAR com modelos e interfaces geradas • Receber outro JAR com suas extensões e customizações – Também dynamic languages da JVM • Maven • Edição online
    22. 22. Runtime • Classloader – Carregar bytecode gerado e customizações – Manter múltiplas versões da mesma classe • Security Manager – Controlar acessos a rede, disco, dados – Definir permissões dependendo do caller
    23. 23. Serviços • Dependency Injection – Spring – Anotações JSR-330 (@Inject) • Internacionalização/Templating • Mailer/Notifier • Auth consumer/Provider OAuth2 • Authorization • Logging/Audit Trail/Exception Logging/Metrics • MVC Controllers e API extensions • Embedded jBPM Engine
    24. 24. DEMO TIME!?!
    25. 25. Problemas...? • “Os 4 problemas”: encoding, timezone, dar nome às coisas, cache eviction. • Descasamento objeto/relacional (^n) • PermGen! • Caching: CoR/CoW vs. GC Overhead • Front-end autogeneration, never good enough
    26. 26. Obrigado!!! • Feature Gating/Feature Bits – http://martinfowler.com/bliki/FeatureToggle.html – http://www.infoq.com/presentations/Feature-Bits • Embedding Groovy – http://groovy.codehaus.org/Embedding+Groovy • Coda Hale, “Metrics, Metrics Everywhere” – http://pivotallabs.com/139-metrics-metrics- everywhere/

    ×