Como fica meu negócio na quarentena?

Em tempos de quarentena, muitas empresas precisam se transformar para manter seu negócio.

Mas como ficam aqueles pequenos negócios, como lojinha de reparos de celular, sapatarias da esquina, aquele vendedor de salgados e tantos outros?

Esses negócios precisam de ajuda, não conseguem se manter e muitos nem sabem o que fazer para operar nesse momento.

Pensando nisso e assumindo que é obrigação de cada um de nós preservarmos nossa economia. Eu posso fazer minha parte.

Como?

Hoje já estou dando prioridade para usar serviços e adquirir produtos desses pequenos empresários. E acredito que todos podem fazer isso.

Mas posso ir além e isso não me custa nada. Se você tem um negócio, ou sabe de alguém que tem um negócio e foi impactado pela quarentena, deixando de operar/funcionar. Ofereço meu contato para ajudar essa pessoa a encontrar uma forma de voltar a operar nos moldes da quarentena.

Como fazer?

Basta entrar em contato pelo email rcelebrone@gmail.com explicando seu negócio, a região que você atua e o perfil do seu cliente. Vou responder com algumas soluções para que você volte a operar, muito provavelmente, online!

Não tem custo algum viu? rsrs só quero ajudar de alguma forma com o que sei e convido outros da área de tecnologia e fazerem o mesmo.

Vamos sair dessa juntos :)

Microsserviços, como definir o contexto?

Como podemos definir um contexto de um microserviço?

No site da AWS, existe a definição: Microsserviços são uma abordagem arquitetônica e organizacional do desenvolvimento de software na qual o software consiste em pequenos serviços independentes que se comunicam usando APIs bem definidas. Esses serviços pertencem a pequenas equipes autossuficientes.
fonte: https://aws.amazon.com/pt/microservices/

Já no site da redhat: Microsserviços são uma abordagem de arquitetura para a criação de aplicações. O que diferencia a arquitetura de microsserviços das abordagens monolíticas tradicionais é como ela decompõe a aplicação por funções básicas. Cada função é denominada um serviço e pode ser criada e implantada de maneira independente. Isso significa que cada serviço individual pode funcionar ou falhar sem comprometer os demais.
fonte: https://www.redhat.com/pt-br/topics/microservices/what-are-microservices

Certo, mas quando sei que uma parte do meu software, pode ser um microsserviço?

Antes de mais nada, antecipo que não existe uma regra, mas sim, algumas praticas que estão funcionando para muitas empresa. Uma delas, talvez a mais difundida, seja a segregação dos microsserviços por contexto de negócio. Essa segregação tem acontecido com frequência por conta do movimento das squads e times scrums que são formadas por contextos de negócio e costumam se tornar responsáveis por determinados contextos de negócio.

E quais fatores eu deveria considerar quando penso em criar microsserviços?

Eu costumo considerar os seguintes fatores:

- Quantidade de desenvolvedores/engenheiros e de times - microsserviços muito pequenos, podem prejudicar a manutenibilidade por aumentar a quantidade de aplicações dentro da corporação.

- Contexto de negócio - por experiencia, tenho percebido uma maior facilidade de trocar informações com os responsáveis de negócio ou product owner.

- Uso individual - esse é um ponto bem importante. Se uma parte do seu negócio pode ser usado independente de outras partes, de forma individual, é coerente pensar em criar um microsserviço para esse contexto. Vou dar um exemplos que surgiu em um bate papo com um colega:

- Discutimos a possibilidade de criar um microsserviço de endereço, mas nos deparamos com a seguinte questão: Onde usaríamos esse serviço, sem necessariamente estar atrelado ao outro microsserviço que possuímos (o microsserviço de usuário). Logo, percebemos que não seria viável quebrar o contexto de endereço para fora de usuário, pois esse contexto não teria uso fora do contexto de usuário. Entendemos que usuário tem um endereço e endereço não é nada sem o usuário (no nosso cenário).

- Código duplicado - entendo também que não é bacana duplicar código em diferentes microsserviços. Então, quando ocorrer essa situação, seria interessante isolar esse contexto, porém, esse contexto, para ser um microsserviço, deveria estar diretamente relacionado ao negócio (para não ferir os principio acima). Então, se não for um contexto de negócio (por exemplo, endereço - no meu caso), poderíamos criar uma simples API ou uma biblioteca para compartilhar o código entre os microsserviços.

A sugestão que posso te dar, é seguir o que busco seguir com minha equipe. Sempre buscamos discutir e pensar juntos. Envolver alguém de negócio, que possua um viés técnico, pode ser interessante.

Ocultar configurações sensíveis da minha aplicação

Como utilizar o cloud secret manager para proteger dados sensíveis e ajudar minha aplicação a estar em conformidade com a LGPD.

Agosto está chegando e a LGPD entrará em vigor, fazendo com que as empresas corram atrás do prejuízo e busquem estar em conformidade em tempo de evitar dores de cabeça.

Lei mais sobre: https://epocanegocios.globo.com/Empresa/noticia/2019/12/lei-de-protecao-de-dados-entra-em-vigor-em-2020-mas-empresas-antecipam-protecao-ao-cliente.html

Algumas ações precisam ser tomadas para que as aplicações e principalmente os dados, estejam de acordo. Uma delas, é o controle de quem tem acesso ao banco de dados da aplicação e como isso é controlado pela organização. Pensando nisso, busquei a um serviço que me permita colocar as chaves que tenho em minha aplicação e que não deveriam estar visíveis para os que possuem acesso ao fonte. Foi então que encontrei o Google cloud secret manager.

Vamos direto ao assunto:

1- Para habilitar a api Secret Manager:

• - https://console.cloud.google.com/apis/api/secretmanager.googleapis.com/overview

2 - Para criar uma Secret:

• - https://console.cloud.google.com/security/secret-manager
• - crie uma secret com o nome MINHA_SECRET

3 - Para criar versões de Secret:

• - https://console.cloud.google.com/security/secret-manager/secret/MINHA_SECRET

Passo a passo:

• Crie o projeto “minha-secret” e habilite a api Secret Manager e crie uma conta de serviço que tem permissão de view.
• Depois exporte a conta de serviço (download do JSON). Ex: minha-credencial.json.
• Para conectar local (durante desenvolvimento), execute o comando a seguir para configurar a conta de serviço no seu sistema: export GOOGLE_APPLICATION_CREDENTIALS="minha-credencial.json"
• Então crie uma web api e no controller faça a implementação para ler a secret MINHA_SECRET.
• Crie a secret (step 2 acima).
• E no código, faça o seguinte na controller:

Em produção, você terá de criar uma variável de ambiente no seu container GOOGLE_APPLICATION_CREDENTIALS apontando para o arquio JSON (e por favor, delete o JSON do container antes de provisionar.

É isso, espero ter colaborado :)

Como fazer rollback de uma aplicação que roda no kubernetes

Como fazer rollback de deployments no kubernetes

Sempre falo bastante sobre estrategias de CI/CD, uso do Auto DevOps do gitlab e como o kubernetes é legal. Mas, o que muito ocorre e pouco se fala, é: O que fazer quando da ruim e preciso fazer rollback rapidão?
Eu achei um artigo bem detalhado e que explica tudo muito bem, mas para aqueles que pulam para a flag verde no stackoverflow, vou resumir colocando os passos para operar um rollback de um deployment no kubernetes.

Bora lá

Vou partir da premissa que você já usa o kubectx e o kubens (por favor!) e também que nosso deployment possui o nome "app".

Seguem os passos:

# "acessar" o cluster
kubectx [cluster]

# "acessar" o namespace
kubens [namespace]

# verificar os deployments do namespace 
kubectl get deployments

# verifica a revisão (versão) do deployment que quero operar um rollback
kubectl describe deployment/app | grep deployment.kubernetes.io/revision:

# verificar o histórico de revisões (versões) do deployment que desejo fazer rollback
kubectl rollout history deployment/app

# faço rollback pra revisão que desejo
kubectl rollout undo deployment/app --to-revision=25

# acompanho e aguardo os pods e o deployment ficarem disponíveis
kubectl get deployments,pods

# verifico se a revisão foi alterada (vai incrementar)
kubectl describe deployment/app | grep deployment.kubernetes.io/revision:

Ref: https://learnk8s.io/kubernetes-rollbacks

Configurando auto escalonamento usando gitlab com Auto DevOps

Como usar o helm requests e limits com Auto DevOps do Gitlab

Já falei bastante aqui no blog sobre o Auto DevOps. O que poderíamos fazer para permitir que nossas aplicações (que já fazem uso de todas as praticas dos 12 fatores, rodam na nuvem em clusters de orquestração de container, possuem capacidade de tolerância a falha) possam chegar ao próximo passo e escalar de forma inteligente ainda fazendo uso do Auto DevOps?
- Agora é o momento de fazer com que nossa aplicação use apenas o recurso que ela realmente necessita e deixe o resto para quem quiser usar ou para eventuais sobrecargas que exijam "auto escalonamento" :)

Para aqueles que usam o auto DevOps do gitlab e já perceberam que nem tudo é configurável, apresento-lhes a variável HELM_UPGRADE_EXTRA_ARGS do .gitlab-ci.yaml. Essa varável nos permite apontar um arquivo para modificar outros valores dos nossos arquivos yaml gerados pelo Auto DevOps. E um desses valores (que vou falar aqui), é o resources.

Para usa-la, basta inclui-la em variables no .gitlab-ci.yaml:

variables:
  - HELM_UPGRADE_EXTRA_ARGS: "--values helm-values.yaml"

*percebam que passei o nome de um arquivo depois de "--values"

Certo, seguem os passos:
- Junto ao arquivo .gitlab-ci.yaml, vamos criar um arquivo chamado: helm-values.yaml
- Dentro do arquivo helm-values.yaml, vamos incluir as informações de resources (recurso que minha aplicação tem disponível para trabalhar e o limite acima disso).

Dentro do helm-values.yaml:

resources:
  requests:
    memory: "150Mi"
    cpu: "50m"
  limits:
    memory: "195Mi"
    cpu: "65m"

*para encher linguiça, vou apenas deixar aqui a explicação e sugiro que você leia antes de brincar com requests e limits: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container

Outra forma de configurar o upgrade helm

É possível usar um nome e path padrão. Se usado, o gitlab entende e não precisamos colocar a variável no .gitlab-ci.yaml. para isso, basta criar o arquivo helm: .gitlab/auto-deploy-values.yaml com o mesmo conteúdo do a helm-values.yaml mencionado acima.

Variável criada e arquivo helm preparado

Faremos o deploy via Auto DevOps e dessa forma, possibilitamos nosso cluster escalar nossa aplicação caso ela atinga determinadas métricas (podendo crescer ou diminuir) de acordo com a demanda.

Para configurar o auto scale no seu objeto deployment, faça o seguinte:
- kubectx [nome do cluster]
- kubens [nome do namespace]
- kubectl get deployment
*aqui irá listar seus deployments
- kubectl autoscale deployment [nome do deployment] --min=1 --max=3 --cpu-percent=85
*min, max e cpu são apenas exemplos. Você pode configurar de acordo com sua necessidade.

É isso o/ flwss

Ref:. https://gitlab.com/gitlab-org/gitlab-foss/issues/65497