Engenharia de Software para Cientistas de Dados — Pt. 1, Arquitetura

Um guia para não-especialistas

Uma vez que entendemos o que são e quais as funções das interfaces — contratos à nível de código — podemos agora começar a entender como nasce um microserviço para Ciências de Dados, e como ela escala com a aplicação dos princípios SOLID.

Isso é muito interessante, porque você vai começar a entender como uma Cientista ou Analista de Dados Sênior, Head, CDO visualiza toda arquitetura e infra de Dados, conseguindo interferir em todos os níveis de abstração do sistema.

A ideia é muito natural e até simples, uma vez que você entende a motivação das interfaces.

Acho que tudo pode se resumir na seguinte frase:

Um sistema de software escalável, resiliente e consistente se estrutura como um fractal.

Talvez seja simples até demais, e você já esteja se indagando:

Mas o que é um fractal?

E qual sua relação com o meu trabalho em software, sistemas de Ciência de Dados?

Volte ao desenho, do triângulo inicial, observe com calma os lados.

Note que para cada lado, o mesmo triângulo inicial cresce nele.

E essa é a sacada, o fractal é toda estrutura que as partes repetem o Todo.

Se as partes replicam o Todo, elas respeitam uma regra de replicação e construção. A rigor, as partes respeitam interfaces.

Nazaré, prestes a ter uma epifania súbita em Engenharia de Software.

Talvez agora você já está começando a visualizar melhor o porque é possível para um humano entender a organização de um sistema de software inteiro.

Não é que os Seniores memorizaram todas formas de programação, a maioria acaba, inclusive, se esquecendo de boas práticas mais específicas de programação, seja num framework ou linguagem específica, depois de um tempo de gestão.

Mas tem um conjunto de coisas que eles não perdem de vista:

Quais contratos/interfaces que o sistema e seus sub-sistemas obedecem, e quais os principais estabelecidos na comunidade.

Essa visão diz que se você entende as principais restrições, e quais restrições o seu sistema deve obedecer para melhorar, você só precisa replicar esse princípio em todas partes dele, e esse é o segredo da escalabilidade.

Quer reduzir custos?

Seus modelos em produção demoram tempo demais treinando?

Você gasta muito tempo desenvolvendo um código e pouco explorando os dados?

Quer reduzir a latência do seu modelo de Machine Learning em produção?

Repense as interfaces que você está usando.

Será que a organização atual não gera muito overhead?

Teve segregação de responsabilidade em excesso?

Você está definindo os contratos de forma consistente?

Se o sistema no nível macro está bem estruturado, aí sim você vai analisar as partes do sistema.

E vai pensar exatamente como antes.

Pensando pelo contorno do seu sistema, pelo que torna ele conciso, seguro, você não precisa decorar ele todo a baixo nível.

É só pensar da mesma forma em todos os níveis.

E essa é uma perspectiva diferencial entre cientistas e desenvolvedores mais experientes.

Como isso se aplica a um sistema de Ciência de Dados?

Quando vamos produzir um sistema de software, desde jobs simples para dashboards até infraestruturas inteiras de Dados, ETL ou Machine Learning, é importante ter em mente algumas coisas:

1. O serviço de Dados está potencialmente presente em TODAS as àreas da empresa, nós coletamos o extrato da produção de cada time, retornando-o em insights ou acionáveis;
2. Supomos que a empresa vai crescer, em número de colaboradores, serviços, e em requisições para nosso sistema e clientes, ou seja, teremos mais carga sobre o sistema e mais Dados disponíveis;
3. Deve ser fácil para outros colegas, novos ou antigos, que ao entrarem na empresa consigam visualizar o impacto, a entrega de valor da nossa área na empresa e nas funções diárias;
4. Novos entrantes podem e devem repensar, ajudar a refatorar, melhorar nossa infraestrutura de código, desde o código em si, à arquitetura.

Ou seja, o futuro é cheio de complexidades e possibilidades. Se não impormos restrições, contratos no nosso sistema, ele cresce caoticamente.

E essa caoticidade torna cada vez mais difícil de manter e evoluir o sistema, como uma bola de neve, que gera um esforço muito maior no futuro para arrumar.

Dessa forma, a perspectiva estratégica de uma equipe de Dados na produção da sua infraestrutura, jobs, deve ser respeitar alguns princípios fáceis de serem decorados sobre sistemas de Software e que se replicam como um fractal.

Nascem os princípios SOLID

Até certo momento na década de 70, os sistemas de software eram totalmente expostos (sem segurança alguma), monolíticos (todo sistema no mesmo script) e desde então passaram a usar os conceitos de abstração e modularidade.

Boas práticas foram sendo coletadas, recicladas, mudadas de nome — por puro branding, diga-se de passagem — mas alguns cientistas e engenheiros perceberam invariantes nessas evoluções.

No livro Arquitetura Limpa do Tio Roberto, que citei no artigo anterior, ele apresenta o modelo de arquitetura SOLID, que resumiria em 5 princípios as características de um software escalável:

https://devscopeninjas.azurewebsites.net/2017/04/28/solid-principles/

1. Princípio da Responsabilidades Única: Uma entidade, função, módulo, microserviço tem uma e somente uma entidade ou regra de negócio responsável por ela;
2. Princípio do Aberto-Fechado: Uma entidade, função, módulo ou microserviço deve ser aberto para ser “estendido”, mas fechado para modificações;
3. Princípio de Substituição da Liskov: Uma superclasse pode ser substituída por subclasses que herdam dela, sem interferir na corretude do programa, em tempo de compilação ou execução;
4. Princípio da Segregação de Interfaces: É melhor ter uma interface definida para cada um dos vários atores, do que uma interface genérica para vários;
5. Princípio da Inversão de Dependência: Um entidade, função, módulo não deve depender de implementações, mas sim de abstrações da implementação.

São simples princípios que podem até parecer meio genéricos, mas que limitam o suficiente o desenvolvimento para que esteja dentro das melhores convenções de programação até o momento.

Particularmente, o Princípio da Responsabilidade Única ( referenciado às vezes como SRP ), tem implicações diretas no desenvolvimento diário de um Cientista/Analista de Dados.

Quando entendemos bem como funciona pensar por ele, começamos a visualizar melhor como se define os limites de uma funcionalidade no sistema de Dados, e assim a definição de testes, funções de alta qualidade são construíveis com naturalidade.

Nessa perspectiva não só você evolui profissionalmente, como também ganha em escalabilidade e manutenabilidade do seu código, contribuindo muito nas boas práticas e qualidade das entregas dos seus times na sua carreira.

Por essas e outras, o abordaremos no próximo artigo.

Próximos capítulos…

Como foi dito no artigo anterior, nessa série de artigos vamos detalhar dos princípios SOLID às arquiteturas Lambda, Service-Oriented (SOA), Microserviços e algumas outras principais arquiteturas de desenvolvimento no contexto do serviço de Dados.

Caso seja conveniente, com o feedback de você podemos fazer artigos de outros temas, tal como a Thamys Abrahão, Cientista de Dados do nosso time começou uma série de pipelines para Machine Learning, talvez futuramente podemos comentar sobre modelos específicos de Machine Learning e Deep Learning de forma acessível.

Estamos abertos a responder dúvidas, discutir sugestões, e qualquer coisa podem me mandar um e-mail [victor.souza@passeidireto.com] ou perguntar aqui mesmo no post :)

Abraços e bons estudos!