Cuide da sua Tartaruga » esse texto não é sobre tartarugas!

 

A forma como trabalhamos tem passado por transformações profundas, do fordismo às tecnologias mais recentes. A cada ciclo, novas metodologias, ferramentas e formatos são introduzidos no mercado de trabalho, e nós, profissionais, precisamos nos adaptar para continuar entregando resultados e valor. Esse processo de aprendizado contínuo deixou de ser opcional: é condição de relevância. Como exemplos práticos, podemos citar: Inteligência Artificial, Indústria 4.0, Agilidade, Globalização, Internet das Coisas (IoT), entre tantos outros que poderiam continuar essa lista.

Entretanto, todos esses avanços são extensões da nossa capacidade de executar, ou seja, podem ser considerados “formas” de fazer que oferecem mais eficiência e eficácia durante o processo. Vamos a uma breve analogia: imaginemos que, durante a Idade Média, um marceneiro inventasse a serra elétrica (imaginária, lembre-se!). Com a serra, a marcenaria mais que quintuplicou a entrega de móveis. Os concorrentes, automaticamente, também quiseram adotar a novidade para alcançar os mesmos resultados. Alguma correlação com os dias atuais?

Só que os marceneiros concorrentes simplesmente receberam a nova ferramenta com diretrizes básicas para começar a usá-la. É aqui que entra a tartaruga!

Imagine que a incumbência de utilizar a serra para produzir mais seja transmutada em uma tartaruga. Se qualquer um de nós recebesse uma tartaruga para cuidar, qual seria a primeira coisa a fazer para ter sucesso nessa empreitada de “Pai de Pet”? Diria, com toda a convicção, que seria entender como cuidar de uma tartaruga: o que ela precisa para sobreviver, o que ela come, o que ela não gosta, como ela “funciona”. Enfim, informações que facilmente comporiam um Manual de Instruções. Ter domínio desse conhecimento é o básico do básico. E, ainda assim, apostaria que boa parte das pessoas já tropeçaria nessa primeira etapa.

Mas vamos continuar com os demais que estão aptos para cuidar da tartaruga. Mesmo tendo o domínio do conhecimento sobre o que precisa ser feito para garantir a longa vida desse réptil, qual seria a habilidade essencial para aumentar ainda mais essa garantia? Eu apostaria que é o comprometimento. Comprometer-se com a atividade de cuidar da Tag (sim, resolvi dar um nome a ela 😉) proporciona um resultado verdadeiramente eficiente: além do conhecimento técnico, estaremos atentos aos sinais, detalhes e condições que direcionam nosso cuidado. Se a Tag resolver dar um passeio, a acompanhamos para garantir sua segurança. Se ela tentar comer algo impróprio, estamos lá para evitar. Enfim, estaremos no controle da situação, e é aí que a maioria fica pelo caminho.

Voltando à Idade Média: qualquer marceneiro que desejasse utilizar a serra como ferramenta de aumento de produtividade precisaria estar comprometido com sua utilização para garantir resultados eficientes. E voltando à nossa realidade: ter o domínio de qualquer nova metodologia, ferramenta ou tecnologia é apenas metade do caminho. Para conquistar o controle com eficiência e eficácia, precisamos estar genuinamente comprometidos com a atividade-fim. Ou seja: dedicar-se de verdade a cuidar da nossa tartaruga, para que ela viva muitos e muitos séculos, mesmo que nossa responsabilidade seja apenas uma parcela dessa vida.

No fim, o que separa o profissional mediano do profissional de referência não é o acesso à melhor ferramenta ou o maior volume de cursos concluídos. É a disposição genuína de ir além do mínimo necessário, de tratar cada responsabilidade com seriedade, atenção e intenção. Num mundo onde o conhecimento está cada vez mais acessível e as ferramentas cada vez mais democratizadas, o comprometimento se torna justamente o diferencial mais escasso e mais valioso. Ele não aparece no currículo, não é certificado por nenhuma plataforma e não pode ser simulado por muito tempo. Comprometimento é, antes de qualquer coisa, uma postura, e é uma postura que se revela no dia a dia, nas entregas pequenas, nas escolhas invisíveis que ninguém está observando, e é exatamente aí que os melhores se destacam.

O Arquiteto Econômico

No cenário tecnológico em constante evolução, a figura do Arquiteto de Soluções tem papel fundamental na concepção e implementação de infraestruturas digitais inovadoras e eficientes. Este profissional desempenha um papel estratégico ao projetar ecossistemas que não apenas atendem às demandas de negócios, mas também antecipam as necessidades futuras das organizações. No epicentro de suas responsabilidades, foram criadas sete leis fundamentais que moldam a abordagem do arquiteto de soluções de nuvem. Estas leis transcendem os limites da tecnologia, incorporando princípios de inovação, sustentabilidade e consciência financeira. Em um mundo cada vez mais consciente dos recursos, o Arquiteto de Soluções desempenha um papel na promoção da sustentabilidade, ao incorporar práticas que minimizem o consumo de energia, otimizam recursos e reduzem pegadas ambientais, esses profissionais moldam o futuro da tecnologia de maneira responsável. Além disso, a consciência dos custos assume uma importância central, equilibrando a inovação com a eficiência financeira para garantir que as soluções propostas não apenas atendam, mas também otimizem os investimentos gerando agregação de valor. 

LEI I - Faça do Custo um Requisito Não Funcional

Torne o custo um requisito essencial. Muitas empresas falham ao não considerar o custo em todas as fases do negócio, desde o design até a operação.. Esse requisito, muitas vezes negligenciado, se os custos ultrapassarem a receita, a viabilidade do negócio fica em risco. Ao ponderar as implicações de custo desde o início, as soluções podem ser desenvolvidas de maneira eficiente, equilibrando recursos, tempo de lançamento e eficácia operacional, garantindo assim a sustentabilidade financeira.

LEI II - Custo de Soluções Conectados ao Negócio

A durabilidade de uma solução depende de como seus custos estão alinhados ao modelo de negócios. Ao projetar, devemos considerar as fontes de receita, como o número de pedidos em e-commerce. À medida que os pedidos aumentam, os custos de infraestrutura também crescem. Se a arquitetura for sólida, é possível explorar economias de escala. Como arquitetos de solução, devemos pensar na receita e usar esse conhecimento para escolhas informadas, evitando o crescimento desenfreado que pode resultar em problemas.

LEI III - Arquitetura é Tomar Decisões com Trocas

Projetar é uma série de escolhas difíceis. Na arquitetura, cada decisão implica em sacrifícios. Custo, resistência e desempenho são requisitos que frequentemente entram em conflito. Como diz o ditado, "Tudo falha o tempo todo." Defender-se contra falhas exige investir em resistência, mesmo que isso afete o desempenho. Encontrar o equilíbrio certo entre as necessidades técnicas e comerciais é o ponto que precisa se alinhar com sua tolerância a riscos e orçamento. Lembre-se, ser econômico é maximizar o valor, não apenas cortar gastos, o que exige decidir o que você está disposto a pagar.

LEI IV - Custos Desconhecidos Surgem de Soluções Não Monitoradas

Sem atenção e medição cuidadosas, os reais custos de operar uma solução permanecem invisíveis, permitindo práticas desperdiçadas. Tornar os medidores mais visíveis pode mudar comportamentos significativamente. Apesar do investimento necessário para observação, a falta de monitoramento adequado é uma visão de curto prazo. O ditado "Se você não pode medir, não pode gerenciar" destaca a importância de rastrear uso, gastos e erros para uma gestão de custos eficaz. Ao colocar métricas críticas de custo em destaque para engenheiros e parceiros de negócios, práticas sustentáveis emergem organicamente, permitindo a identificação de gastos excessivos e ajuste de operações para redução de despesas. O retorno do investimento em observabilidade geralmente supera os custos, incentivando práticas sustentáveis.

LEI V - Arquiteturas Conscientes dos Custos Implementam Controles de Gastos

Em uma arquitetura econômica, o foco está na monitorização sólida e na habilidade de economizar. Soluções bem planejadas possibilitam ações para melhorias. Para alcançar isso, desmembre as aplicações em blocos ajustáveis. Uma abordagem comum é classificar os componentes por importância. Os da Classe 1 são essenciais; otimize, mesmo que custe caro. Já os da Classe 2 são importantes, mas dá para reduzir temporariamente sem grandes problemas. Os da Classe 3 são "legais de ter"; faça de um jeito mais barato e fácil de controlar. Definir essas classes permite trocar entre custo e outras necessidades. O controle detalhado dos componentes otimiza custos e experiência. Tudo, desde a infraestrutura até linguagens e bancos de dados, deve ser ajustável. Planeje e construa sistemas com foco em receitas e lucros. A otimização de custos deve ser mensurável e impactar positivamente os negócios.

LEI VI - Melhoria Contínua na Otimização de Custos

Mesmo após a implementação, revisitar soluções é essencial para melhorar gradualmente a eficiência, a essência está em questionar e explorar continuamente. Linguagens de programação oferecem ferramentas para analisar o desempenho do código, permitindo mudanças que economizam milissegundos. Pequenas otimizações, ao longo do tempo, se transformam em grandes economias em grande escala. Na operação, a maior parte do tempo é dedicada a executar sistemas existentes. Identificar oportunidades para analisar o uso de recursos e reduzir desperdício é essencial. 

LEI VII - Sucesso Sem Desafios Gera Presunção

Quando equipes de software triunfam sem grandes obstáculos, a confiança excessiva nas abordagens anteriores pode se instalar. Há a tendência de presumir que as tecnologias atuais sempre serão as melhores, o que pode desencorajar a busca por opções mais eficientes ou inovadoras. Isso ocorre especialmente ao lidar com linguagens de programação, onde a declaração "Somos adeptos do Java" pode sufocar a criatividade. O sucesso não questionado alimenta acomodações prejudiciais por meio de pressuposições, sendo essencial sempre buscar maneiras de questionar, otimizar e melhorar.

As leis apresentadas acima não apenas fomentam benefícios financeiros e inovação, mas também destacam fortemente a importância da sustentabilidade na utilização de recursos em nuvem. Além de otimizar custos e impulsionar práticas inovadoras, essas diretrizes visam garantir uma abordagem ambientalmente consciente e eficiente. Ressalto que todo o conteúdo deste artigo foi baseado nas valiosas informações do site "https://thefrugalarchitect.com/". Encorajo todos os arquitetos de soluções a incorporarem essas leis simples em suas práticas, assegurando não apenas a perenidade de suas soluções tecnológicas, mas também contribuindo para a sustentabilidade e longevidade das organizações que servem.

Marcelo Goberto de Azevedo 

Arquiteto Soluções 

//marcelogoberto.com.br

Arquitetura Eficiente: Lições do Caos no Resultado do ENEM 2023

No dia 13 de novembro de 2023, o Instituto Nacional de Pesquisas Educacionais Anísio Teixeira (INEP) anunciou a data oficial de divulgação do resultado do ENEM 2023. De acordo com os dados do INEP, mais de 2 milhões e 700 mil estudantes aguardavam ansiosos pelos resultados, considerando-se automaticamente parte do público interessado nessa informação crucial.

No entanto, no dia 16 de janeiro de 2024, poucas horas antes do tão aguardado momento da liberação dos resultados, uma situação “inesperada” ocorreu. Milhares de estudantes, ávidos por avaliar seus esforços no exame, começaram a acessar o site, resultando em uma sobrecarga que desencadeou reclamações e memes nas redes sociais. Às 9 horas, horário oficial, o portal do estudante (https://enem.inep.gov.br/participante/) tornou-se inacessível. Durante uma transmissão ao vivo realizada pelo órgão, foi anunciado que as notas estariam disponíveis às 10h30min do mesmo dia. O resultado? Horas intermináveis de instabilidade no portal, exigindo dezenas de tentativas individuais de cada estudante e gerando uma demanda muito além do necessário. 

Diante desse contexto, é essencial refletir sobre os caminhos alternativos, do ponto de vista arquitetural, que deveriam ser considerados, principalmente com foco na objetividade de atingir a melhor experiência para os alunos que estão "desesperados" pelos seus resultados, os quais podem moldar seus destinos de maneira permanente.

Envio dos Resultados por E-mail

Uma abordagem eficaz seria automatizar o envio dos resultados diretamente para os e-mails cadastrados durante o processo de inscrição. Este método aproveita a robusta infraestrutura de segurança já implementada no processo de credenciamento, garantindo a confidencialidade das informações. Além disso, ao reduzir a dependência do portal, a carga nos servidores seria significativamente aliviada, evitando gargalos de acesso massivo. Isso não apenas proporcionaria uma experiência mais fluida para os usuários ansiosos, mas também garantiria a entrega segura e pontual dos resultados, eliminando a incerteza e a frustração associadas às falhas técnicas.

Implementação de uma CDN Personalizada

Observando o comportamento atual do site, uma solução viável seria a implementação de uma CDN (Content Delivery Network) personalizada. Ao distribuir os dados estáticos, como imagens e folhas de estilo, por uma rede global de servidores, a latência seria reduzida, melhorando significativamente o desempenho do site. Isso não só aceleraria a entrega de conteúdo para os usuários, mas também aliviaria a carga nos servidores principais. Ao adotar uma abordagem mais distribuída, mitigaríamos efetivamente os efeitos negativos de picos de tráfego, proporcionando uma experiência mais estável e responsiva para os alunos ansiosos pelo resultado.

Armazenamento em Cachê no Modelo Chave-Valor

A proposta aqui é utilizar um sistema de armazenamento em cache, seguindo o modelo chave-valor, para otimizar a recuperação de resultados individuais. Dado que a grande maioria dos estudantes está interessada apenas em cinco números específicos (suas notas em cada bloco e a nota de redação), armazenar essas informações em um cache distribuído, onde a chave seria associada ao CPF do estudante e o valor seria o conjunto de resultados, permitiria consultas extremamente rápidas. Essa estratégia reduziria drasticamente a carga nos servidores de banco de dados, proporcionando uma resposta quase instantânea aos alunos que acessam o portal. Essa abordagem, além de eficiente em termos de desempenho, é altamente escalável e adaptável a períodos de pico de tráfego.

Alteração Temporária do Processo de Autenticação

Para contornar possíveis desafios relacionados ao envio automatizado de e-mails, especialmente em momentos de alta demanda, uma alternativa seria a implementação temporária de um formulário simplificado. Esse formulário permitiria aos estudantes inserir seu e-mail e CPF, gerando um registro em um serviço de mensageria. Um processo escalável seria encarregado de validar esses dados em relação aos registros cadastrados, efetuando o envio de e-mails com os resultados. Essa abordagem não apenas preserva a segurança, mas também introduz um mecanismo eficiente de fila, garantindo uma distribuição controlada e equitativa dos resultados. Essa mudança temporária no processo de autenticação minimiza a pressão sobre os servidores e oferece uma alternativa prática para lidar com volumes excepcionais de acesso.

Certamente, essas soluções podem parecer simplistas à primeira vista. Contudo, na área de TI, devemos lembrar que a simplicidade frequentemente supera arquiteturas complexas que, quando submetidas ao teste real, tendem a falhar de maneira significativa, prejudicando usuários, clientes, negócios e lucratividade.

Mais valioso do que uma arquitetura tecnológica supercomplexa e “update” são aquelas que proporcionam um valor tangível ao público final, indo além do simples acumulo de recursos tecnológicos. Essa abordagem não apenas garante a estabilidade em momentos cruciais, mas também constrói uma base sólida para o sucesso contínuo.

Marcelo Goberto de Azevedo 

Arquiteto Soluções 

//marcelogoberto.com.br

FinOps 101

 

A cada dia que passa vemos o potencial e a exponencialidade da utilização de recursos em nuvem, porque as organizações precisam garantir inovação e rapidez na entrega de valores dos seus produtos para o mercado. Entretanto, atrelado diretamente ao aumento da utilização em escala da nuvem estão os valores dos gastos, os famosos custos de operação (OpEx). Alguns estudos apontam que as organizações desperdiçam em média um terço dos investimentos com a nuvem, simplesmente pelo fato que elas não adotaram uma abordagem eficiente para gerenciar esse diferente modelo de custos. 

A palavra mágica para esse modelo diferente é gerenciar, basicamente, é habilitar a organização a fomentar uma cultura aliada com inteligência de gerenciamento de custos da nuvem com o propósito de gerar o melhor retorno sobre o investimento (ROI). O mercado adotou o termo FinOps para descrever esse movimento na área de tecnologia. A implementação da cultura FinOps é uma jornada sem fim e cíclica, porque ela não se trata de atividade únicas e pontuais que resolvem o problema de gerenciar os custos, ela deve ser trilhada e incorporadora juntamente com a estratégia de negócio da organização para geração de valor.

Ciclo de Vida de FinOps

Partindo de um ponto inicial, como no título desse artigo, que referimos ao número 101, que em sua forma interpretativa, quer dizer um introdutório sobre um tema, FinOps exige que alguns temas estejam colocados como foco desde o início da jornada da implementação.

Alocar e rastrear os custos de nuvem

Se existe uma ação que podemos considerar a mais importante para FinOps, sem dúvida alguma, é a questão de alocação e rastreabilidade dos custos, isso porque todas as demais ações necessitam de informações precisas e atualizadas para tomadas de decisões eficazes. Logo, quanto antes estivermos com os recursos de nuvem devidamente identificados de uma forma normatizada e condizente, mais cedo será possível começar a rastrear os custos da nuvem e gerar transparência e visibilidade.

Promover a responsabilidade dos custos da nuvem

Cada centavo gasto com a nuvem com certeza foi originado por uma demanda de negócio, seja ela perene ou temporária, por isso que é essencial que cada custo seja direcionado para seu responsável, seja direto e/ou indireto. Isso com certeza irá criar uma consciência em todos sobre os impactos financeiros, sejam de decisões arquiteturais, escalabilidade, disponibilidade, ou qualquer outro que possa ser ajustado. Porque essas decisões podem gerar custos, e por consequência diminuir o retorno sobre o investimento do produto, diminuindo sua geração de valor. 

Incorporar os custos da nuvem no contexto de negócios

A flutuação dos números dos gastos com a nuvem não dizem nada quando não estão associados aos números do negócio, essa falta de correlação permite que os números totais ou segmentados dos custos da nuvem nada respondem ou indicam, seja no melhor ou pior cenário de investimento. Para que seja possível calcular o retorno sobre o investimento, é crucial que os gastos sejam associados com números proveniente dos resultados, por exemplo, quanto uma determinada estrutura de recursos está custando ao final do mês, frente às mensalidades cobradas de usuários que se utilizam do produto que está utilizando essa estrutura.

Essas são temas centrais que precisam ter foco desde o início da implementação de FinOps. No livro “O Caminho das Pedras da Cultura FinOps”, além de tratar desses temas, ainda oferece outras ideias, conceitos básicos, princípios, nível de maturidade, terminologia, estrutura de times, responsabilidades, entre outras tantas informações que devem levadas em consideração para compor um plano personalizado para uma organização durante a habilitação da cultura FinOps de forma que possam transformar os gastos com a nuvem de um passivo em um ativo da organização.

Marcelo Goberto de Azevedo 

Cloud Leader na GFT Brasil

//marcelogoberto.com.br

As Três Leis do TDD

 

Já enumerei as principais razões para utilização da metodologia de Desenvolvimento Orientado a Testes neste artigo (link) e também como praticar em sessões de Coding Dojo neste outro artigo (link), dessa vez quero abortar as leis do TDD (Test Driven Development), essas leis que podemos entender como regras são fáceis de entender e principalmente nos fornecem uma forma simples de validar o que estamos fazendo.

Essas regras foram definidas por Robert C. Martin (Tio Bob), principalmente no intuito de auxiliar no processo de iniciação na utilização da metodologia TDD, essas três regras são mecânicas, você deverá aplicá-las porque irá lhe forçar a escrever código de melhor qualidade e aumentará a facilidade de manutenibilidade.

Lei 1: Você não pode escrever nenhum código fonte, antes de escrever uma especificação de teste que falhe

Isso quer dizer basicamente, o principal e o óbvio para a metodologia, nenhum código pode ser criado, ou classes, ou interfaces, ou seja nada, antes que a especificação do testes seja escrita e falhe, que obviamente irá falhar porque não tem nenhum código para ser validado.

Lei 2: Você não pode escrever mais do que um teste para falhar (e não compilar é falhar)

Muitas vezes já queremos adiantar todas as possíveis soluções e cenários plausíveis para garantir que o que iremos desenvolver irá cobrir os testes e atendendo os resultados esperados, porém esses testes não são testes unitários, são especificação de testes de comportamento, ou seja, você terá que primeiro escrever uma especificação de teste, essa especificação falhará, você então irá codificar para passar no teste e só depois você poderá escrever uma nova especificação de teste para um novo comportamento, dessa forma a cada nova especificação, codificação, estará sendo criado uma pilha de testes que continuaram sendo validados sobre o que está sendo desenvolvimento com qualidade e sem quebras.

Lei 3: Você não pode escrever código fonte mais do que o suficiente para passar no teste que está falhando

Essa talvez seja a regra mais difícil de executar, porque como programador é natural durante o processo de implementação, já tentamos adiantar passos e prever condicionais, situações e comportamentos, porque dessa forma conseguimos escrever códigos que aceleram a implementação final, porém a metodologia nos obriga a dar um passo de cada vez para que possamos ter ciência e principalmente cobertura de todo o processo, com isso fica bem claro que o código fonte que devemos implementar tem que ter o propósito de fazer o teste ser passado e somente isso. Um exemplo básico para ilustrar, caso escreva um teste que precise validar a soma de dois valores (exemplo 1 e 3), sua função deve simplesmente retornar 4, isso fará o teste passar. O motivo por trás disso é forçar você a pensar e dar pequenos passos e ser muito mais produtivo do que tentar codificar em grandes etapas.

Essas três leis podem parecer simples e talvez irão criar um processo moroso inicialmente, entretanto a principal função do TDD é garantir qualidade de código gerado e principalmente cobertura de testes focadas na solução do problema. Ter implementações menores oferecem um poder de concentração maior num único ponto, o que potencializa sua capacidade de resolver o centro do atual problema, com o ponto resolvido, você passa para o próximo e assim até o final. É exatamente para isso que servem essas três leis.

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

Dicas para melhorar o entendimento das SQL Querys

Consultas em SQL são basicamente códigos no final, logo é importantíssimo termos a preocupação de oferecer um código claro e objetivo para aumentar a manutenibilidade dele por outros desenvolvedores. Comandos mal formatados e/ou com escritas confusas podem aumentar mais erros e uma falta geral de motivação para revisar seu trabalho. Para quem simplesmente escreve a consulta pode fazer sentido e até funcionar, porém é fundamental que o código esteja num melhor formato possível para aumentar sua qualidade, vamos a alguma regras que podem ajudar.

Seja consistente e corente com a formatação

SELECT primeiroNome, count(*) from
Usuários WHERE ultimo_nome = 'silva' Group by primeiroNome

Vamos analisar alguns pontos:

• Veja que algumas partes estão em maiúsculas e outras não, procure manter um padrão único, por exemplo todas as palavras reservadas.
• É confuso identificar o que é coluna ou o que é comando
• A coluna do SELECT está em "camelCase", a usada no WHERE está "snake_case" e o nome da tabela em "PascalCase", crie um padrão geral, se começou errado, conserte.
• A utilização de caracter especial em definição de nomes, como na tabela Usuários

Veja um exemplo como deveria ser:

SELECT primeiro_nome, COUNT(*) from
usuarios WHERE ultimo_nome = 'silva' GROUP BY by primeiro_nome 

Use e Abuse da Identação 

SELECT g.id, COUNT(u.id) FROM usuarios u JOIN gruopos g on u.grupo_chave
= g.chave WHERE u.nome = 'Marcelo' AND  u.sobrenome
= 'Silva'  GROUP BY g.chave ORDER BY COUNT(u.chave) desc 

Para uma consulta pequena pode não fazer diferença para leitura quando tudo está sem um padrão de separação, agora imagine aquelas longas procedures com todos os comandos encavalados, não é mesmo?

Veja se o resultado fica melhor para o entendimento: 

SELECT 
	  g.id
	, COUNT(u.id) 
FROM usuarios u 
	JOIN gruopos g on u.grupo_chave = g.chave 
WHERE 
	    u.nome = 'Marcelo' 
	AND u.sobrenome = 'Silva'
GROUP BY 
	g.chave 
ORDER BY 
	COUNT(u.chave) desc

Dica: A utilização da virgula (,)antes de cada campo no SELECT, ou das conjunções AND / OR no WHERE, GROUP BY, ORDER BY facilita a identificação visual onde se inicia ou termina o grupo de campo, além de fornecer uma forma agíl de comentar um campo 

Se você utilizar 2 ou 4 espaços não surti efeito considerável, o importante é só manter o padrão em toda a codificação, a simplesmente utilização dessa formatação farão seu colegas adorarem ver suas consultas quase como obras de arte. 😃

Utilize sempre "Aliases" 

SELECT
    u.chave
    , u.nome
    , t.chave
    , t.nome
    , (SELECT COUNT(*) FROM titulos where nome = t.nome)
FROM usuarios u
    JOIN titulos t on u.titulo_chave = t.chave 

O resultado dessa consulta será: 

chave	nome	chave	nome	count
1	Marcelo Goberto	4	Arquiteto	6

Novamente num cenário minimalista é possível identificar o que é cada conteúdo, agora imagine isso num longo resultado com várias colunas, por isso é fundamental que você nomeie cada coluna para que possa facilitar o entendimento.

Veja como fica o resultado da mesma consulta acima com ajustes 

SELECT
   u.chave AS usuario_chave   
   , u.nome AS usuario_nome
   , t.chave AS titulo_chave
   , t.nome AS titulo_nome
   , (SELECT COUNT(*) FROM titulos where nome = t.nome) AS qtde_titulos
FROM usuarios u
   JOIN titulos t on u.titulo_chave = t.chave

O resultado dessa consulta será 

usuario_chave	usuario_nome	titulo_chave	titulo_nome	qtde_titulos
1	Marcelo Goberto	4	Arquiteto	6

Utilize números nas clausulas GROUP BY e ORDER BY 

Neste caso essa é uma preferência pessoal que acredito que auxilia muito no organização de uma consulta, veja um exemplo com essa aplicação 

SELECT
   nome
    , sobrenome
    , COUNT(*) AS total
FROM usuarios
GROUP BY 1, 2
ORDER BY 3 desc 

Algumas vantagens na adoção desse formato são:

• Economia de linhas: a utilização de muitas colunas em GROUP ou ORDER não aumentará sua consulta, pois todos estarão enfileiradas
• Manutenção: Se desejar trocar o agrupamento ou a ordenação, basta trocar as colunas de lugar dentro da clausula SELECT

Esses foram alguns pontos que sempre considero na hora de escrever uma consulta, não existe um melhor padrão ou formato único para SQL, mas com certeza existe o desafio que procurar fazer um ótimo trabalho que possa ter sua manutenção facilitada para os próximos e quem sabe para nós mesmo, porque se todos tivermos um consenso que garantir sempre um excelente padrão de código, todos se sairão ganhando.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Arquitetura de Nuvem Básica

Alguns conceitos que todos desenvolvedor deveria saber antes de iniciar no mundo da nuvem.

O diagrama abaixo é uma representação de uma aplicação web básica bem estruturada, caso você não seja um desenvolvedor da nuvem, provavelmente achará complicado.

A seguir vamos conhecer cada um desse componente e dar uma introdução para que você possa ter o conhecimento necessário quando incluí-lo na arquitetura do projeto. 

1. DNS

A sigla DNS (Domain Name System), é a tecnologia que permite a internet. Esse componente permite que todos os IP e domínios possa ser referenciados e encontrados. Imagine uma gigante lista telefônica da internet, é através dela que é possível encontrar onde está um determinado  endereço. Quando informamos um domínio em nosso navegador, por exemplo  www.pudim.com.br, esse endereço será pesquisa nesta lista telefonica para encontrar onde deve ser direcionado a navegado, por trás é sempre um IP, no caso desse endereço é o 54.207.20.104.

2. LOAD BALANCE

O Load Balance é um componente essencial para a arquitetura de nuvem, uma das principais características das aplicações em nuvem é sua escabilidade horizontal, ou seja, podemos criar inúmeras instâncias (replicas) das aplicações para atender um grande demanda de requisições, garantindo assim a disponibilidade. E neste cenário que o Load Balance entra, porque ele será o responsável por distribuir essa demanda entre todas as instâncias existentes, garantir um as regras neles definidas sejam atendidas para evitar sobrecarga em determinada instância e prover alta performance das requisições.

3. WEB APP SERVER

Esse são os servidores de aplicativos web, basicamente é onde a aplicação está instalada e responderá ao usuário através do recebimento da requisição e fornecerá uma resposta HTML. Por ser o cérebro da aplicação, será responsável por se comunicar com uma variedade de outros componentes, como banco de dados, filas, cachês, microserviços e muito mais. As implementações no servidor requer uma escolha de uma linguagem (C# .NET , Node.js, Ruby,  Scala, Java, etc). 

4. DATABASE

Basicamente todo aplicativo utiliza banco de dados para armazenar informações. É através deles que podemos armazenar e atualizar os dados capturados ou gerados pela aplicação. No modelo nuvem, principalmente com microserviços, é bem comum utilizarmos vários banco de dados. Além disso atualmente existe duas versão de banco de dados, sendo a mais utilizada o banco relacional (SQL Server, Oracle, MySql, etc) e banco não relacional (CosmoDB, MongoDB , DynamoDB, etc), basicamente a diferença é que o relacional oferece maior consistência e confiabilidade e não relacional tem como vantagem uma escalabilidade maior, com a informação agrupada e armazenada no mesmo registro. 

5. CACHE SERVER

O serviço de cache basicamente fornece a consulta e persistência de dados em praticamente tempo real. Os aplicativos geralmente utilizam consulta ao banco de dados que são executadas várias vezes e retornam o mesmo valor, para evitar o processamento dessa informação, o cachê armazena esse resultado em memória e o mantêm disponível pelo tempo configurado para a aplicação, efetuando assim um grande ganho de performance. 

6. JOBS

A maioria dos aplicativos da precisa trabalhar de forma assíncrona, ou seja, que não esteja associada à resposta à solicitação de um usuário. Para isso são utilizado as "filas de trabalho", é através delas que rotinas são agendadas para serem executadas de tempos em tempos para realizar trabalhos que não necessitam que aconteçam diretamente associados a usuários. As opções de linguagem e estruturas subjacentes são tão numerosas quanto para os servidores da web e na sua grande maioria podem ser criados no conceito "serverless ", que são algoritmos que são executados sem servidor e com orientação para eventos. 

7. STORAGE

Esse repositórios são uma maneira simples e escalável de armazenar e acessar dados na nuvem. Eles são perfeitos para qualquer tipo de informação que você armazenaria num sistema de arquivos local, com o beneficio de ser acessível por meio de http de qualquer local. E ainda pode contar com a configuração de redundância para garantir sua alta disponibilidade. 

8. CDN

A CDN (Content Delivery Network) é uma tecnologia que oferece uma maneira de permitir o acesso a arquivos estáticos (html, css, javascript, imagens, etc) mais rapidamente do que permitir que o usuário tenha que chegar até a aplicação web para receber seu conteúdo. Basicamente ele funciona distribuindo uma cópia do conteúdo mais atual entre muitos servidores em todo mundo, assim quando um usuário efetuar o acesso ao aplicativo web, esse conteúdo será entregue pela CDN mais próxima ao usuário e evitando assim consumo de tráfego do servidor, isso irá garantir uma latência bem menor para o usuário e uma melhor experiência.

Trabalhar com a nuvem é simples e complexo ao mesmo tempo. Esses elementos apresentados são uma pequena parte das inúmeras possibilidades que existem para montar uma arquitetura, porém espero que seja útil para dar o ponta pé inicial na sua utilização. Acredite que o futuro das aplicações será inevitavelmente estar na nuvem.

Marcelo Goberto de Azevedo 💫

Arquiteto na GFT Brasil
//marcelogoberto.com.br/