Do Monólito ao Micro Serviço

 

Praticamente todas as empresas possuem aplicativos que foram construídos para solucionar seus problemas internos e esses foram, em sua maioria, construídos incorporando o máximo de funcionalidades possíveis para que atendessem o maior número possível de requisitos do negócio. Isso gerou grandes blocos, conhecido como monólitos, que precisam ser geridos do ponto de vista de manutenção, estrutura, estabilidade e principalmente evolução. Com as diversas necessidades de atualizações, essas aplicações têm se transformado cada vez mais em obstáculos do que facilitadores do processo, um exemplo,  simples implementação de uma regulamentação, como a LGPD, começou a exigir esforços gigantescos para sua concretização, isso tudo porque existe um alto grau de complexidade para essa manutenção.

E usando este ponto como partida, é que normalmente começa a jornada de transformação de uma aplicação, porque qualquer um que seja da área de tecnologia, já ouviu falar dos micro serviços, seja do seu conceito, dos benefícios, das referência de mercado ou até mesmo dos resultados de sua implementação que facilitam as adaptações às mudanças. Entretanto, essa jornada exige requisitos mínimos para garantir seu sucesso, entre eles, domínio do processos de negócios, mapa de contexto, definição de padrões, arquitetura de referência, abordagem DevOps e mais importante a observabilidade dos KPIs, logo diante de tantos requisitos, a simples incorporação dessa transformação se torna arriscada sem planejamento, e estando as empresas migrando para o modelo ágil se faz necessário algum plano antes da ação. Listamos algumas estratégias que podem guiar na obtenção dos requisitos em tempo de execução, ou seja, criar um plano de vôo em tempo de vôo.

Comece Algo Novo com o Novo

Sempre que uma aplicação monolítica necessitar de uma nova funcionalidade você deverá criar um micro serviços para atendê-la e não incorporá-la ao seu monólito, entretanto sabemos que a maioria das funcionalidades com certeza se utilizarão de informações essenciais  da aplicação, para isso devemos criar uma interface entre o micro serviço e a aplicação, também conhecida como "Glue Code", que nada mais é que um código para unificar ambos sistemas, que poderá no futuro ser trocado ou ajustado, além de oferecer uma barreira de segurança para que o micro serviço incorpore comportamentos e conceitos do legado. No diagrama abaixo exemplificamos a arquitetura sugerida.

A implementação de novas funcionalidades como micro serviços fará com que seu monólito não cresça mais e ao mesmo tempo oferecerá oportunidades de surgirem novas estruturas independente e acopláveis.

Separe as Camadas

Pensar em separadas as camadas de apresentação das de lógicas e acesso a dados oferecerá uma estratégia para encolher sua aplicação monolítica e muitas informações da situação atual. A ideia é simplesmente separar em um ou mais interface, sendo uma delas, o front-end e as demais em back-ends, preferencialmente em formato de API. Uma vez separados, o front-end irá fazer chamadas remotas ao back-end, o diagrama abaixo mostra essa transformação. 

Pode parecer puro retrabalho visto que estamos somente fazendo uma separação física, porém após essa estratégia, você terá várias API que poderão ser consumidas por outros sistemas e que ainda oferecerão estruturas isoladas que facilitarão a manutenibilidade, além de poder escalar separadamente os recursos para suas execuções.

Essas são algumas estratégias iniciais que podem oferecer o primeiro passo para iniciar essa transformação, oferecendo ao longo da sua implementação insumos e conhecimentos iniciais para contextualização do caminho que será necessário para atingir a maturidade na utilização de micro serviços. 

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Benefícios de uma Solução MDM

Por conta da transformação digital, as maiorias das empresas estão cada vez mais conscientes que seus dados são um dos ativos mais importantes, a cada dia que passa o volume de dados aumentam exponencialmente e através da aplicação da metodologia Data-Driven, que basicamente é a utilização de dados para orientação de ações que geram novos dados que geram novas ações, logo se tornou essencial o gerenciamento de dados como um dos focos principais das organizações. Por conta dessa importância, podemos entender o quanto é vital para qualquer empresa, independentemente de seu tamanho,  um processo que envolva a coleta, sanitização, normatização, garantia de qualidade, governança e principalmente a transmissão dos dados entre todas as partes interessadas.

E é nesta solução desse problema que se encaixa perfeitamente um MDM, Master Data Management, em tradução livre ficaria, Gerenciamento de Dados Mestres. Essa solução fornecerá todos os requisitos mencionados anteriormente, como também a consolidação da oferta de dados em uma única fonte, que ofertará os benefícios: 

Qualidade dos Dados

No processo de coleta dos dados para transferência para o MDM é possível garantir através de regras de aceitação e da eliminação de dados inválidos. Como resultado os usuários poderão trabalhar com dados consistentes, uniformes e de melhor qualidade, o que tornará os processos de negócios mais eficientes e confiáveis.

Duplicação de Dados

Eliminando qualquer chance de conter dados duplicados, o que nos cenários atuais sem a centralização de dados é extremamente comum e leva a dúvidas em relação qual dados é mais confiável, o MDM irá construir uma única fonte de dados altamente confiável e proverá aumento na eficiência do negócio.

Precisão dos Dados

Sem dados inválidos ou duplicados, as discrepâncias no dados não existiram e aumentaram o nível de precisão dos mesmos, reduzindo os riscos de processamento de informações incorretas, como também o fator de normalização das estrutura facilitando a recuperação e entendimentos dos dados.

Redução de Custos

Uma vez que teremos uma solução gerenciando todos os dados mestres da empresa, automaticamente iremos reduzir os locais que precisam estar processando os dados, monitoramento da utilização,  sem contar a eliminação do impacto negativo ao negócio quando um dado impreciso é compartilhado.

Conformidade dos Dados Verídicos

Cada dia que passa os regulamentos e as políticas sobre dados estão ficando cada vez mais rígidos, com isso é fundamental que qualquer negócio tenha total controle (gerenciamento) sobre os dados, pois a não conformidade pode acarretar multas pesadas, como regulamentadas pela LGPD. A aplicação de um gerenciamento dos dados diminui as chances de violações de segurança e possibilita a conformidade regulamentar.

Tomada de Decisão em Dados

Já sabemos como as empresas estão aumentando a utilização dos dados para tomadas de decisões, informações incompletas e incorretas possibilitando à administração tomar decisões mal direcionadas que impactam o crescimento da empresa a curto e longo prazo. O simples fato de ter acesso a dados com qualidade, ajudará todos os gestores a desenvolverem estratégias eficazes.

Estamos num bom momento para considerar uma abordagem de MDM para gerenciamento de dados nas empresas. Já existem algumas ferramentas no mercado despontando com maturidade para oferecer um bom pacote de serviços, como também é possível implementar uma solução interna totalmente adaptada para o contexto do negócio. O que eu sei é, o gerenciamento de dados é um caminho inevitável para qualquer organização que queria estar no futuro entregando valores para seus clientes.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

TDD no SQL com tSQLt

 

A utilização de teste é uma realidade muito comum no desenvolvimento de aplicativos, porém banco de dados é tratada como uma forma de exceção quando falamos da utilização do método desenvolvimento orientado a testes, principalmente pela falta de uma ferramenta integrada que possibilite a criação de testes, classes, além da metrificação dos resultados da execução dos testes.

O tSQLt é uma ferramenta que oferece uma estrutura de testes para ser aplicado em banco de dados SQL, o tSQLt permite implementar testes de unidade em T-SQL, também fornece recursos como: testes dentro das transações, agrupamento dos testes em classes, saída em texto simples ou XML e o principal de criar clonar de tables, views, functions e procedure para utilizar em simulação nos testes sem interferir nas estruturas reais.

O processo para utilização é bem simples e vamos demonstrar desde a instalação e criação de um teste e sua execução.

1. Instalação do tSQLt

• Baixe tSQLt do site tSQLt.ORG

• Acesse ou crie um novo banco de dados

• Execute o script tSQLtClass.SQL no banco de dados

Installed at 2020-10-24 18:23:21.390

+-----------------------------------------+

|                                         |

| Thank you for using tSQLt.              |

|                                         |

| tSQLt Version: 1.0.5873.27393           |

|                                         |

+-----------------------------------------+

2. Efetuar a criação de “Classes” para agrupar o teste

EXEC tSQLt.NewTestClass 'UnitTestClass';

Esse comando irá criar uma classe que poderá ser utilizada para executar somente os testes que estiverem associadas à ela, na prática o SQL criará um “Schema” com esse nome.

3. Criando um teste

CREATE OR ALTER PROC [UnitTestClass].[Test Exists Function CalculateBestQuote]

AS

BEGIN

  --Arrange

 

  --Act

  

  --Assert

   EXEC tSQLt.AssertObjectExists @ObjectName = N'fnCalculateBestQuote'

END

GO

Importante, toda procedure que representa um teste deve obrigatoriamente iniciar com a palavra “Test”, como o banco de dados podem conter estrutura que podem não existir, diferente de código estático, existe um Assert específico que efetua a validação da existência do objeto, no caso do exemplo, ele está verificando se a function “fnCalculateBestQuote” existe no banco de dados.

4. Executando os testes

   EXEC tsqlt.RunTestClass 'UnitTestClass'

Através do comando, todos os testes que estão associados a classe referida, será executado exibindo as mensagens de erros, os resultados esperados e um resumo dos testes.

[UnitTestClass].[Test Exists Function CalculateBestQuote] failed: (Failure) 'fnCalculateBestQuote' does not exist

 

+----------------------+

|Test Execution Summary|

+----------------------+

 

|No|Test Case Name                                           |Dur(ms)|Result |

+--+---------------------------------------------------------+-------+-------+

|1 |[UnitTestClass].[Test Exists Function CalculateBestQuote]|    127|Failure|

-----------------------------------------------------------------------------

Msg 50000, Level 16, State 10, Line 1

Test Case Summary: 1 test case(s) executed, 0 succeeded, 1 failed, 0 errored.

-----------------------------------------------------------------------------

5. Criando a function 

CREATE OR ALTER FUNCTION fnCalculateBestQuote

(

    @BaseValue decimal(10,2),

@Fator decimal(6,2)

)

RETURNS Decimal(15,2)

AS

BEGIN

    RETURN @BaseValue / @Fator * 2;

END

GO

Após a execução dos testes e da falha, devemos escrever o código que satisfaça a regra de negócio esperada.

6. Executando o teste novamente

EXEC tsqlt.RunTestClass 'UnitTestClass'

O resultado dos testes será com sucesso

+----------------------+

|Test Execution Summary|

+----------------------+

 

|No|Test Case Name                                           |Dur(ms)|Result |

+--+---------------------------------------------------------+-------+-------+

|1 |[UnitTestClass].[Test Exists Function CalculateBestQuote]|      6|Success|

-----------------------------------------------------------------------------

Test Case Summary: 1 test case(s) executed, 1 succeeded, 0 failed, 0 errored.

-----------------------------------------------------------------------------

Portanto, agora ficará mais fácil detectar bugs antes mesmo de conectar com seu código de backend, simplesmente executando os testes no banco de dados.

Existem várias funções desenvolvidas para validações, além claro da parte de clonar tabelas e afins para criar massa de testes, existe uma vasta documentação em https://tsqlt.org/full-user-guide/

Na GFT praticamos TDD em sessão de Coding Dojo que ocorrem a cada 15 dias em sessões online, elas são abertas para todos participarem, basta acessar //meetup.com/GFTBrasil, escolher o melhor dia e horário para você praticar.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Logs, quem são, onde vivem, o que comem?

Logs são apontamento de atividades gerados por sistemas. O armazenamento pode ser feito em arquivos, base de dados, ferramentas. Eles comem, ops, servem como fonte de informações que permitem analisar o histórico de comportamento do programa, como identificar erros, indicar falhas de sistema ou ainda fornecer insumos para previsibilidade de eventos futuros.

São muitas as alternativas para que os logs sejam criados. A captura de registro de logs devem ser desenhada para atender um equilíbrio que todos registros sejam sucintos e minimamente didáticos para solução de um problema. É obrigatório que toda uma aplicação seja coberta por registros de log de erros, isso garante o mínimo do mínimo. 

Para informações pertinentes e relevantes um registro de log deve ser composto pelos seguintes propriedades:

Data Evento

Essa data refere ao momento do registro do Log, de preferência com fuso horário ajustado para a audiência.

Aplicação

Nome da aplicação que está gerando a mensagem de log.

Nível

Todo log deve pertencer obrigatoriamente a um nível, é fundamental o entendimento desses níveis, porque alguns não são aplicados em todos ambientes.

• TRACE: Esse nível deve ser utilizado para rastrear algo pontual em produção e nunca devem ficar habilitados definitivamente em produção.

• DEBUG: Nesse nível pode ser logado qualquer coisa durante o desenvolvimento, porque esse tipo só será registrado em ambiente de desenvolvimento.

• INFO: Os logs desse nível devem basicamente rastrear pontos de fluxo do aplicativo.

• NOTICE: Todos esses logs serão criados para monitoramentos em produção.

• WARN: Neste nível são os logs de alertas (monitoramento) para potenciais problemas que podem gerar erros, como falta de espaço, lentidão. Porém não causam a interrupção da execução do aplicativo.

• ERROR: Todas as condições de erro gerados dentro do programa, quando um fluxo fluxo de execução é interrompido devido a uma falha.

• FATAL: Os logs neste nível devem ser utilizados para acionar contingências, pois descrevem um aplicativo irrecuperável ou falha do sistema que requer atenção imediata.

Categoria

Todos os logs devem conter obrigatoriamente uma categoria, essa categoria deve ser utilizada para agruparem logs dentro do mesmo contexto, que facilitem a extração dentro de um comportamento. Outro fator importante, é utilizar um nível hierárquico respeitando o princípio simples de responsabilidade.

Mensagem

As mensagens devem ser escritas em inglês, isso se deve ao fato das ferramentas de análise de logs estarem preparadas para analisar palavras e frases associados ao idioma inglês, além de evitar problemas com acentuação que ocorre muito no idioma português.

O conteúdo da mensagem devem ser ricos no sentido que ofereçam informações que auxiliem no entendimento do logs, muitas vezes quem estará interpretando a mensagem não necessariamente tem o conhecimento do negócio.

Sempre adicione contexto as mensagens, todo registro de log deve conter por si só, todas as referências necessárias para auxiliar no entendimento da sua geração.

A grande maioria dos logs atualmente são analisado por ferramentas de monitoria, e lembrando que essas leituras são feitas por máquinas, é importante que o conteúdo das mensagens sejam acessíveis a humano e máquina, logo é importante normatizar os dados para facilitar o entendimento de ambos, uma forma é elegante é tipificar através do formato JSON o conteúdo.

Nenhuma informação sensitiva devem ser armazenadas em nenhum nível de logs, seja nome do cliente, número de documento, senhas, tokens, ou seja, nenhum dados que possa identificar ou expor informações. Os logs não passam por nenhum tipo de validação de conteúdo, por conta que as informações são muito genéricas, logo é sua responsabilidade não armazenar informações que ferem as leis (LGPD).

Regra de ouro para definir o que registrar numa mensagem de log?

Simplesmente pense em algo que alguém terá de lê-lo um dia ou mais tarde. Mais importante, é pensar em quem vai ler essas linhas, pois isso define o conteúdo, contexto, categoria e nível da mensagem.

Usuário

Essa informação diz a respeito do usuário que está utilizando a aplicação no momento do log, seja um colaborador ou até mesmo um processo automatizado.

Ambiente

Deve sempre identificar o ambiente em que log foi gerado (Desenvolvimento, Homologação, Pré-Produção, Produção, ...)

Outro ponto importante, é a centralização dos logs, pois permitirá  aumentar a segurança e praticidade, sendo que os logs centralizados ficam mais fácil para fazermos consultas em busca de erros e análise e controlar a permissão de acesso.

Lembre-se também de criar uma regra de retenção, porque os logs contém uma volumetria muito alto e se não for criado essa política, com o tempo muitas informações não mais necessárias estarão aumentando o tempo de consulta e dificultando a localização de dados relevantes.

E ainda, cada vez que um código for refatorado é importante criar mensagens de log. Procure manter uma sincronia entre os comentários e o registro de log, porque não há nada pior ao solucionar problemas para obter mensagens irrelevantes que não têm relação com o código processado.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Um Programador Mais Eficiente

Um desenvolvedor, também conhecido popularmente como programador ou ainda, engenheiro de software, ou para o mais hipster, coder. É o responsável por organizar códigos e linguagens de programação dentro da tecnologia da informação. Em todos anos que não seja bisexto comemoramos o Dia do Programador no dia 13 setembro e nos anos bisextos no dia 12 setembro, isso porque a data é celebrada no 256º dia do ano.

Gostaria de elencar algumas dicas que podem ajudar qualquer desenvolvedor a aumentar sua eficiência na entrega de código, vou fazê-la por ordem de grandeza na minha opinião:

1. KISS, não é banda de rock, é um acrônimo para “Keep it simple, stupid”, que em bom português fica “Mantenha isto simples, estúpido” , pode parecer um pouco agressivo, entretanto é muito válido, porque você iria criar complicado, se é você mesmo amanhã que irá ter que dar manutenção! Pegou?

2. Comente com riqueza e qualidades todos códigos, seja um facilitador da vida das próximas gerações de desenvolvedores, que quando tiverem contato com esses códigos eles lhe farão agradecimentos em memória.

3. Nunca, jamais, em tempo algum, despreze testes únicos, esses são de total responsabilidade de um desenvolvedor e são eles que vão garantir sua paz no futuro, acredite.

4. TDD, acredite, parece difícil, complicado, trabalhoso demais, mas, uma vez que você se apropria, todos os seus problemas acabam antes mesmo da codificação.

5. Aproprie-se da solução primeiro, antes de sair escrevendo código, um parêntese, o TDD te força a saber antes de fazer.

6. Coma SOLID com farinha no café da manhã, no almoço e no jantar, até que este conceito faça parte de você, isso irá garantir uma excelência na sua entrega.

7. Quando for utilizar algo externo, adquirida domínio do conhecimento de sua utilização, isso irá economizar longas horas tentando, além de mostrar o caminho para melhor aplicação.

8. Utilize o google, “Stack Overflow”, programação em par, você não é uma ilha e pode conseguir ajuda em muitos lugares, entrentanto, aprenda com essas oportunidades.

9. 99% dos problemas de tecnologia tem solução, muitas vezes não enxergamos na hora é porque estamos demais envolvidos por ele, aprenda a praticar pausas estratégicas para dar um tempo para o cérebro absorver, processar e encontrar possíveis soluções. 

10. Pode parecer piegas, mas é a realidade, escrever código no fundo é uma arte, a arte de organizar os comandos para que se executem com harmonia resultando numa linda sinfonia, ou seja, tenha paixão por cada nota.

Nesta data tão especial temos muito que comemorar, pois agora existem outros cargos e  funções no cenário de tecnologia, como arquiteto de soluções, designers de interface, gerente de projetos, cientista de dados, DBAs, engenheiro de redes, entre outros que compartilham conosco o título de “Menino(a) do Computador”.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Aprendendo com Coding Dojo

Todo aquele que precisa executar uma prática que exige conhecimento de movimentos específicos para alcançar resultados esperados, tem que ter um espaço seguro e confiável para treinar e aplicar cada movimento, seja novo ou conhecido e além de ter um ou mais mestres para orientar e também avaliar a performance da aplicação do aprendizado. Tá, mas o que isso tem há ver com tecnologia? Tudo meu pequeno padawan, os desenvolvedores também precisam ter um espaço seguro e confiável para treinar e melhorar suas habilidades, esse local é Coding Dojo.

A palavra Condig é o termo em inglês para “programando” ou “gerando código”, já a palavra Dojo, (pronuncia-se Dojô) é uma palavra de origem japonesa e significa “local de treinamento”. Logo, o Coding Dojo nada mais é que do um “local de treinamento de código”.

Esse espaço tem como suas principais características ser um ambiente colaborativo, que estimula o aprendizado de forma divertida e principalmente sem nenhum tipo de competitividade entre os participantes. Existem três modalidades:

Randori

Esse é o formato mais “tradicional” por que todos participação, no início o mestre da sessão propõem um desafio a ser resolvido e todos os participantes deverão resolvê-lo utilizando uma única máquina, utilizando o sistema de rodízio de pares. Neste par existirá um piloto que irá operar a máquina e o copiloto que irá auxiliá-lo, a plateia neste momento só acompanha, a cada tempo de minutos pré-definidos previamente, o copiloto virá piloto e alguém da plateia se torna o co-piloto. Se utilizado o TDD a plateia somente poderá efetuar interrupções quando todos os testes estiverem verde. Importante, o mestre pode servir como um consultor da tecnologia e não dá solução do problema. Ao final todos devem entender a solução, pois durante toda a sessão o piloto e copiloto devem estar sempre narrando seus pensamentos.

Kata

Aqui o mestre assume a postura de palestrante, ele irá demonstrar o problema e já partir para aplicação da solução, que pode estar parte pré desenvolvida e ser complementa durante a sessão. Todos os participantes podem a qualquer momento efetuar interrupções para expor dúvidas. O resultado final é que todos ao final devem ser capazes de efetuar a implementação da solução. 

Kake

Muito parecido ao Randori, a principalmente diferença é que não existe um rodízio de pessoas, e sim de duplas, cada dupla trabalha em sua máquina e ao fim do turno as duplas trocam de máquinas e continuam o desenvolvimento da dupla anterior, esse ambiente exige mais conhecimento avançado da tecnologia ensinada.

Benefícios

A utilização do Coding Dojo em um ambiente corporativo aumenta o engajamento do time de desenvolvimento, estimula a aquisição de novos conhecimentos e principalmente desenvolve os valores dos profissionais participantes:

• Participação: Exemplifica a importância da participação de todos na resolução do problema, porque todos podem opinar.

• Cooperação: O problema tente a ter uma solução melhor e mais rápida com a colaboração entre todos, pois vários aspectos são levados em conta por conta da experiência pessoal de cada participante.

• Coragem: Estimula a coragem de enfrentar novos desafios, pois o ambiente sendo seguro até o mais tímidos ganham espaço e oportunidade para praticar a interlocução de suas ideias, sem o julgamento do dia a dia.

• Simplicidade: Como existem vários níveis de experiências entre os participantes, a simplicidade é importante ser mantida para que todos estejam avançado em conjunto, porque é vital que ao final todos estejam treinados para implementação a solução.

• Respeito: Esse valor é muito praticado, porque todos os participante devem respeitar a proposta de solução de um problema, porque todos acabamos aprendendo que existem várias formas de resolver um problema.

Sempre ao final do Coding Dojo é importantíssimo a execução de uma breve retrospectiva pelo responsável para verificar se os principais objetivos foram alcançados, porque além de ser ambiente de ensinamento seguro, é também altamente adaptável ao público, ou seja, caso os resultados não estejam sendo satisfatório, podemos adaptar o formato para facilitar a aplicação do conhecimento.

Onde Treinar?

Aqui na GFT praticamos a cada 15 dias em sessões online, elas são abertas para todos participarem, basta acessar o atalho abaixo, escolher o melhor dia e horário para você praticar conosco.

https://www.meetup.com/GFTBrasil

Oss

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br