archives

mindnotes

Acompanhe o vídeo e se prepare para mais conteúdo ainda neste mês!


[s]
Guto

--

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

Essa semana eu encontrei esse post bacana sobre K8S Multi-Cluster.


Vai lá e dá uma lida.

- Simplifing Multi-Cluster in Kubernetes - CNCF Blog

Recomendo a leitura!

[s]
Guto

--

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

O kuma é um service mesh que roda em cima do envoy.


Me siga no twitter @gutocarvalho e acompanhe meus posts sobre Kubernetes, Cloud Native e CI/CD.

Aproveite e siga também a CD Foundation e Cloud Native Foundation.


O kuma funciona no kubernetes, no openshit e também em ambiente de virtual machines e aparentemente suporta múltiplos meshs em um mesmo cluster.

Características de segurança:

  • Mesh / Muli-mesh
  • Mutual TLS (MTLS)
  • Traffic Permissions

Características de controle de tráfego:

  • Traffic Route & Control
  • Health Check
  • Observability
  • Service Discovery
  • Faulty Injection
  • Circuit Breaker
  • Rate Limit
  • Retries
  • Virtual Onbound

Características de observabilidade:

  • Traffic Metrics
  • Service Map
  • Traffic Trace
  • Traffic Log

O Kuma foi construído em volta do projeto Envoy e traz embarcado o Kong Gateway.

Uma das coisas interessantes que li sobre o projeto é que tem a capacidade de funcionar multi-cluster, multi-cloud e multi-zone na mesma cloud.

Ele também traz um dashboard bem intuitivo para trabalhar.

Conversei com alguns Cloud Engineers que falaram muito bem dele.

Tá na fila para estudar!

[s]
Guto

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

Projetos que uso no dia a dia como Cloud Engineer.


Me siga no twitter @gutocarvalho e acompanhe meus posts sobre Kubernetes, Cloud Native e CI/CD.

Aproveite e siga também a CD Foundation e Cloud Native Foundation.


Bora lá descobrir!

Para orquestrar Infra em provedores de nuvem?

  • Terraform

Para orquestrar um sistema operacional?

  • Ansible

Qual plataforma eu uso/prefiro para rodar APPs?

  • Kubernetes

Qual meu K8S Gerenciado preferido?

Em primeiro lugar!

  • EKS

Uma nova opção que tem se mostrado econômica e viável

Qual distribuição preferida para Kubernetes OnPrem?

  • RKE

Qual distribuição preferida para Kubernetes Leve/Edge/IoT?

  • K3S

Runtime para Kubernetes?

  • Docker

Pretente mudar para algum outro runtime?

Sem dúvida estou de olho em alternativas, são elas:

  • CRI-O
  • Containerd

Quais dashboards preferidos para K8S?

  • LENS para Desktop
  • Rancher como Dashboard Web
  • K9S para terminal

E estou de olho no projeto abaixo

  • Kubevious

O que usa para validar seus manifestos YAML ?

  • Kubeval

Para empacotar APPs para Kubernetes?

  • HELM

O que usa para monitorar o cluster e apps em seu Kubernetes?

  • Kube-prometheus-stack (Node Exporter + Prometheus + Grafana)

E como storage de blocos distribuído rodando no cluster?

Quando existe a necessidade eu uso

  • Longhorn

E como storage de objetos rodando no cluster?

Quando existe a necessidade eu uso

  • Minio

E para fazer backup?

  • Velero

E como ferramenta de registry?

  • Harbor

O que usa para gerenciar certificados no Kubernetes?

  • CertManager + LetsEncrypt

O quer usa para service mesh no Kubernetes?

Quando o projeto pede, vamos de

  • Istio

O que usa no kubernetes para autoscaling?

O que já vem pronto

  • HPA

E para complementar?

  • Keptn ou
  • Kaperter

O que usa para manter a qualidade da APPs rodando?

Quando o projeto pede, vamos de

  • Keda

O que usa para centralizar logs do cluster e suas APPs?

  • Grafana Loki

Qual tecnologia de CI/CD usa hoje em dia?

Difícil apontar uma, normalmente eu vou onde me sinto confortável:

  • GitLab CI ou
  • GitHub Actions

Contudo estou inclinado em usar coisas mais Cloud Native e tenho estudado:

  • ArgoCD
  • Flux
  • Tekton
  • Werf

O que usa para checar a sanidade/saúde do cluster?

  • Popeye
  • Kube Bench

E para checar aspectos de segurança?

  • Kuber Hunter

E no caso de Chaos Test?

É bem nicho, mas tem essa ferramentinha simples e bacana

  • ChaosKube

Para API Gateway?

Quando o projeto pede, vamos de

  • Kong

Para Tracing

To de olho no

  • Grafana Tempo + OpenTelemetry

Amarrando as pontas

Acho que é isso. A lista é longa e mostra como o Cloud Enginner tem que ser flexível e estudar muito para integrar tudo e manter sua aplicação rodando em nuvem da forma mais estável, saudável, performática e segura possível ;)

Volto para atualizar se tiver mais alguma coisa em mente!

[s]
Guto

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

Saiba como iniciar sua jornada Cloud Native!


Me siga no twitter @gutocarvalho e acompanhe meus posts sobre Cloud Native e CI/CD.

Siga a CD Foundation e Cloud Native Foundation no twitter.

Revisor: Ricardo Pegoraro



Esse mapa sugere um caminho com 10 passos para você entrar no mundo Cloud Native sempre utilizando tecnologias open source para sua jornada.

Abaixo do mapa eu comento livremente passo a passo! :)

Cloud Native Trail Map

Passo 1: Containerização


Aqui nesse passo a ideia é atuar para que sua aplicação rode em containers. No futuro é interessante pensar em desacoplar sua APP para rodar pequenas partes do seu software de forma separada usando o conceito de microserviços.

Normalmente nesse passo usamos Docker e escrevemos os primeiros Dockerfiles.

Passo 2: Construir sua esteira CI/CD

Neste passo a ideia é criar uma esteira para que essa faça o build da sua imagem automaticamente quando houver uma atualização no seu código. Essa esteira deve fazer o buildtestar sua app e fazer o deploy para staging e depois para produção, já rodando sua aplicação em uma plataforma de containers.

Aqui algumas pessoas já estão usando um pouco de docker-compose para facilitar o uso de Docker.

Um excelente solução para construir sua esteira é usar o projeto ArgoCD.

Passo 3: Começar a orquestrar sua APP

Aqui a ideia é ir além do Docker, começando a utilizar um orquestrador de containers como Kubernetes ou Nomad. Utilizando um orquestrador você já vai rodar suas apps em um ambiente mais robusto, com estrutura de cluster com diversos benefícios como disponibilidade, escalabilidade, descoberta e muito mais.

É importante escolher uma distribuição certificada pela CNCF e usar ferramentas adequadas para armazenar suas imagens e empacotar sua aplicação.

Sugestões de ferramentas são Kubernetes para o cluster de containers, HELM para empacotamento de suas apps e Harbor para armazenamento de suas imagens.

Mudando para um cluster você terá que ajustar suas esteiras para que o deploy seja feito neste novo ambiente, na esteira você também vai adicionar um passo para armazenar a imagem no registry e empacotar sua APP no formato HELM.

Passo 4: Observabilidade e Análise

Do passo 1 ao passo 3 você estará se preparando para entrar no universo Cloud Native, se chegou no passo 3 já é uma grande vitória. Entrar no passo 4 significa que você já atingiu uma certa maturidade para rodar seu software e agora precisa de dados para melhorar e manter tudo funcionando da forma mais adequada.

Aqui vamos pensar em monitoração, métricas, logs e tracing de aplicações.

Para monitoramento geralmente utilizamos o prometheus para coletar e consolidar os dados, o grafana para visualizar esses dados em dashboards, para logs podemos usar o fluentd e para tracing o opentracing.

Usamos essas ferramenta para ver se tudo está funcionando, para avaliar a saúde de nossa aplicação e sua performance, afinal, não tem como melhorar algo se não temos métricas para comparar a evolução – ou regressão -  de alguma coisa.

Passo 5: Service Proxy, Discovery and Mesh

Bom agora que já temos nossa APP rodando em um cluster Kubernetes, com pipeline para entregar software, monitoramento e métricas de nosso software é hora de pensarmos em usarmos mais de nossos clusters.

Podemos explorar mais os recursos de serviço discovery, service mesh e load balancing, cada qual em seu quadrado para ajudar nossa aplicação a se manter consistente e escalar.

As sugestões aqui são Envoy (Proxy), CoreDNS (Discovery) e Linkerd (Mesh).

Passo 6: Network Policy & Security

Pensar em rede segurança é importante, manter seu cluster seguro é essencial. O kubernetes oferece recursos muito flexíveis para fazer o design de sua rede interna, e além disso, temos excelentes ferramentas para tratar da segurança de nosso cluster, desde a segurança de acesso aos recursos do cluster, configurações do cluster indo até a avaliação de vulnerabilidades das APPs rodando.

APPs para ajudar: CNI (rede), OPA (Policy) e Falco (security).

Passo 7: Storage e Banco de dados distribuídos

Quando a gente precisa de mais resiliência e disponibilidade para nossos bancos, rodar o banco no cluster começa a fazer muito sentido, em especial se compararmos com um banco rodando em uma arquitetura single-instance.

Temos tecnologias Cloud Native para por exemplo rodar bancos de dados com o MySQL de forma distribuída no cluster como o Vitess, temos ainda projetos como o CrunchyData para rodar um ambiente HA de Postgres (completo) em nosso cluster.

A parte de persistência de dados também ganha uma atenção especial, no caso de banco de dados ou de qualquer outra aplicação “stateful” que necessite persistir dados.

Para atender a demanda de persistir dados temos soluções robustas como LongHorn e OpenEBS que são soluções de block-storage que podem ser utilizadas combinados com o Vitess, CrunchyData ou qualquer outra app.

Temos ainda soluções de storage de objetos como Minio e CEPH que são compatíveis com aplicações S3-Like, dentre outras soluções.

Além de tecnologias de bancos de chave-valor como ETCd que consegue armazenar e distribuir dados através dos nós do nosso cluster.

Passo 8: Stream e mensageria

Existem excelentes soluções como NATs e gRPC para rodar em nossos clusters. O gRPC é uma solução universal de framework RPC e o NATS é um sistema de mensageria que nasceu na era Cloud Native.

Passo 9: Container Registry e Runtime

Armazenar imagens de suas aplicações e dependências se torna fácil com Harbor.

Quer experimentar algum outro runtime diferente de Docker? Temos opções como Containerd, e CRI-O que podem substituir a altura e manter seus padrões cloud-native sem perder código já feito para o Docker.

Passo 10: Distribuição de software

Caso precise distribuir software de forma segura, o projeto Notary, baseado no TUF (The Update Framework) pode te ajudar.

Quer ver o mapa atualizado?

https://raw.githubusercontent.com/cncf/trailmap/master/CNCF_TrailMap_latest.png

[s]
Guto

--

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.

 


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

Entenda para que serve e como usar!


Me siga no twitter @gutocarvalho e acompanhe meus posts sobre Cloud Native e CI/CD.

Siga a CD Foundation e Cloud Native Foundation no twitter.

Revisor: Ricardo Pegoraro





Fala pessoa, tudo em paz?

Talvez você já tenha visto o Cloud Native Landscape, mas ainda tem dúvidas sobre ele.

Para que serve isso?

Esse landscape é um grande mapa de projetos que compõe esse universo Cloud Native, são centenas de projetos open source em constante expansão através de contribuições de suas comunidades.

O Landscape é uma grande vitrine de projetos. Essa vitrine te ajuda a encontrar soluções open source para seu projeto Cloud Native de forma simples e fácil.

Como está organizado?

O Landscape está separado em categorias e sub-categorias, sendo elas:

- App Definition And Development
  - Database
  - Streaming & Messaging
  - Application Definition & Image Build
  - Continuous Integration & Delivery


- Orchestration & Management
  - Scheduling & Orchestration
  - Coordination & Service Discovery
  - Remote Procedure Call
  - Service Proxy
  - API Gateway
  - Service Mesh

- Runtime
  - Cloud Native Storage
  - Container Runtime
  - Cloud Native Network

- Provisioning
  - Automation & Configuration
  - Container Registry
  - Security & Compliance
  - Key Management

- Special
  - Kubernetes Certified Service Provider
  - Kubernetes Training Partner

- Plataform
  - Certified Kubernetes Distribuition
  - Certified Kubernetes Hosted
  - Certified Kubernetes Installer

- Observabilty & Analysis
  - Monitoring
  - Logging
  - Tracing
  - Chaos Engineering

Como usar?

É simples, precisa de uma solução de storage, procure uma na seção de storage, precisa de um proxy, tem uma seção para isso, basta pesquisar, testar e encontrar a solução que se encaixa com seu projeto.

 Outros Landscapes

E ainda temos dois projetos separados que também tem seus próprios landscapes
  
  - Serverless Landscape
  - CD.Foundation Landscape

Bora para os sites?

Acesse o CNCF Landspace
Acesse o Serverless Landscape
Acesse o CD.Foundation Landscape

[s]
Guto

--

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

Essa é outra daquelas perguntinhas marotas de entrevistas, bora entender isso direitinho para responder com segurança!

VCS?

VCS significa version control system, ou sistema de controle de versões.

O GIT é o mais famoso hoje, o qual faz parte do grupo dos distribuídos.

Mas qual a diferença entre sistemas centralizados e distribuídos?

VSC Centralizado

O sistema centralizado, como o nome diz tem um servidor ou serviço central e funciona na arquitetura cliente/servidor. Este servidor tem todas as versões do código.

Para trabalhar em um projeto você precisa instalar o cliente e fazer o download de todo o código e sempre vai depender do servidor para gravar suas modificações, se ele não estiver no ar você não consegue fazer seus commits, e isso te impede de trabalhar.

A dependência do serviço no ar para trabalhar por si só já é algo que pode incomodar, além disso, temos um problema maior ainda, uma vez que todo o código está no servidor, perdeu o servidor, perdeu o código e aí ninguém trabalha mesmo.

Em resumo, se o servidor estiver fora, ninguém faz nada.

Os VCS centralizados podem até ser mais simples de instalar, manter e usar, mas o risco de um ponto único de falha é muito grande para assumir hoje em dia.

Exemplos de sistemas centralizados:

  • SVN
  • CVS
  • Perforce

VCS Distribuído

No VCS distribuído todo mundo tem a cópia do software em sua máquina, pode trabalhar localmente e depois enviar e integrar seu código em um repositório intermediário usado para isso, no caso do GIT chamamos esse locais de remotes.

Como todo mundo tem o código, temos múltiplos backups e caso o repositório de alguém se corrompa, podemos facilmente pegar a cópia de outro desenvolvedor e seguir trabalhando.

Como temos uma cópia local, podemos trabalhar offline e depois enviar e integrar o código com dos nossos colegas, e saiba que trabalhar local é bem mais rápido.

A criação de branchs é rápida e objetiva pq é tudo local e não precisa contatar um servidor central toda a vez que for criar uma branch.

A única coisa que precisa ficar claro é a curva de aprendizado pode ser maior do que sistemas mais simples e centralizados, contudo, o poder, a flexibilidade, a segurança e a velocidade de trabalhar superam esse detalhe.

Exemplos de sistemas centralizados:

  • GIT
  • Mercurial
  • Bazaar

Amarrando as pontas

Hoje o GIT se tornou padrão do mercado, todo mundo usa, conhece e sabe trabalhar, contudo, não é incomum encontrar empresas usando Mercurial o segundo mais popular entre os distribuídos.

Espero que tenha te ajudado a entender a diferença :)

[s]
Guto

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

Se você está se inscrevendo para vagas de Cloud Engineer ou DevOps Engineer esse termo pode aparecer em sua entrevista, vamos entender de forma simples o que é.

É um arquitetura client-server bem conhecida e está organizada da seguinte forma:

  • Presentation Layer (GUI)
  • Application Layer (Business)
  • Data Layer (Persistence)

Fazendo uma APP seguindo esse modelo nos dias de hoje geraria algo como:

  • Frontend (HTML, JS, CSS)
  • Backend (Python, C)
  • Database (PostgreSQL, Mongo)

Atualmente seria um Backend desenvolvido com a estratégia API-FIRST, um Frontend leve e moderno usando algum framework JS consumindo as APIs e Endpoints do Backend que estará gravando os dados em sistemas SGBDS modernos, sendo estes relacionais e não relacionais de acordo com o tipo de dado e contexto a ser persistido.

Quais as vantagens?

  • Pode-se atualizar os componentes de forma separada e independente
  • Como os componentes são separados, o desenvolvimento é simplificado e independente, podendo inclusive ser feito por times distintos
  • Podemos trabalhar com objetivo de melhorar a escalabilidade em cada componente de forma independente, o que vai aumentar a resiliência e disponibilidade da aplicação
  • Teremos mais segurança já que o o frontend nao fala diretamente com o banco

Esse é o básico do básico sobre o assunto, mas suficiente para responder.

Refs

[s]
Guto

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

A ideia aqui é falar sobre a diferença de Load Balancer (LB) na camada 4 e 7, perguntinha comum em entrevistas de emprego para quem está disputando uma vaga de Cloud Engineer ou Cloud Architect. Antes de entrar no assunto vamos relembrar algumas coisinhas básicas.

Relembrando do Modelo OSI?

É um modelo referência para comunicação entre sistemas computacionais composto por 7 camadas.

  • Application (HTTP, FTP, SSH, NTP, NFS, SNMP...)
  • Presentation (SSL, TLS...)
  • Session Layer (RCP, SOCKS, NetBios...)
  • Transport (TCP, UDP...)
  • Network ( IP, IPSEC, ICMP, IGMP, RIP...)
  • Data Link ( PPP, ARP, WIFI, Ethernet...)
  • Physical ( 1000BASE-TX, RJ45...)'

Só precisa lembrar que é um modelo conceitual e referencial, nunca foi implementado, quem virou realidade foi o TCP/IP que é uma versão mais simples e de alguma forma parecida com esse modelo.

Relembrando o Modelo TCP/IP

É um modelo mais enxuto e muito funcional.

  • Application (HTTP, HTTPS, SSH, SSL, TLS...)
  • Transport (TCP, UDP...)
  • Internet ( IP, ICMP, IGMP... )
  • Link ( ARP, NDP... )

Esse foi o modelo que se tornou o padrão, sendo o que é usado até hoje.

Qual a diferença entre Load Balancer na camada 4 ou 7?

Quando fazem essa pergunta estão falando do modelo OSI pq é a única que tem 7 camadas.

A camada 7 é a camada mais alta do modelo OSI, chamada de aplicação, nessa camada no caso do LB estamos falando do HTTP que é o que importa para LB geralmente.

A camada 4 é camada de transporte onde temos o TCP que o que importa quando estamos falando de LB geralmente.

Camada 4

O balanceamento nesta camada leve em conta as informações de endereçamento de cada pacote – dos primeiros que recebe – para tomar decisões de roteamento, contudo ele não lê ou inspeciona os dados do pacote.

Aqui estamos falando dos dados brutos, estamos falando dos pacotes de fato. Neste cenário o LB vai receber pacotes em uma porta TCP qualquer, por exemplo a 80 e repassar para outro IP na mesma porta ou em outra porta que for definida. O balanceador pode encaminhar pacotes para vários IPs diferentes de acordo com as regras estabelecidas pelo administrador.

Pode-se ainda definir configurações de estratégia de balanceamento como RR (round-robin), persistência de sessão, definir pesos, prioridades, tempo de timeout, nível máximo de tolerância a falhas e outras regras que a tecnologia escolhida oferecer e suportar.

O único tratamento – de fato – que ele vai fazer é um NAT que irá mudar quando necessário o ip de origem e o ip destino dos pacotes.

Camada 7

Já nesta camada o LB baseia todas as decisões de roteamento usando características e informações presentes nos pacotes, e falando especicamente de HTTP temos o cabeçalho HTTP, o conteúdo da mensagem, a url, o tipo de dados (imagem, texto, áudio, vídeo...) e os cookies.

Além destas informações, o administrador pode definir configurações de estratégia de balanceamento, persistência de sessão, definir pesos, prioridades, tempo de timeout, nível máximo de tolerância a falhas e outras regras que a tecnologia escolhida oferecer e suportar.

E não é só isso, o balanceamento na L7 pode ir além, usando características de reverse-proxys ele permite por exemplo, enviar requisições específicas para um determinado servidor, habilitar compressão de dados (GZIP) e criptografia na comunicação (TLS/SSL), coisas que não podem ser feitas em um LB do tipo L4.

Amarrando as pontas

Sabemos que o custo computacional do L7 é bem maior que o L4, contudo, hoje em dia isso é praticamente imperceptível para a maioria das aplicações e cenários. Só vamos começar a perceber o custo computacional com aplicaçoes de missão crítica ou em sites com acessos na casa dos centenas de milhares por segundo. Ainda assim, os benefícios são maiores IMHO.

Refs

[s]
Guto

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]

Se você está se inscrevendo para vagas de Cloud Engineer ou DevOps Engineer esse termo pode aparecer em sua entrevista. Eu confesso que hoje em dia eu não vejo a turma falando disso, parece uma questão superada do ponto de vista de engenharia de software, posts com esse termo datam de 2014 e achei alguns até mais antigos, no entando, parece que os recrutadores adoram perguntar isso, então bora lá entender o que é para saber responder :)

O que é?

Basicamente é o nome que se dá para aquele momento que os objetos em seu CACHE expiram e seu ambiente começa a tomar requests sem parar, frontend, backend e em especial sua database serão bastante exigidos pois seu CACHE praticamente sumiu.

Imagine centenas de milhares de processos fazendo requests no seu frontend, backend e indiretamente no seu banco de dados, tudo vai ficar bem lento, o load vai subir muito, especialmente se você não tiver uma estratégia de escalabilidade configurada, e isso pode gerar até uma indisponibilidade de suas APPs gerando um enorme prejuizo financeiro e de imagem.

Como previnir isso?

Geralmente o pessoal usa os semáforos ou “semaphore lock”. Nesse caso, quando um valor expira o primeiro request a requisitar o valor gerar um tipo de LOCK, com isso o valor vai ser regerado, enquanto isso, caso outros processos solicitem o mesmo valor, estes vão receber um conteúdo mais antigo (stale content) até que o novo valor seja regerado e armazenado no cache. Quando o novo valor estiver no cache, o lock será removido e o conteúdo novo servido para os novos requests.

Mas servir conteúdo antigo ou desatualizado não é ruim?

Acredite, ruim seria sua aplicação ficar indisponível, servir um conteúdo desatualizado por poucos segundos será o menor dos seus problemas.

Amarrando as pontas

Cada stack ou linguagem tem ferramentas, técnicas métodos para implementar o semaphore lock, isso é algo a ser tratado em nível de código de aplicação – geralmente.

Essa é uma pergunta mais do ponto de vista de arquitetura e engenharia de software do que de infraestrutura, mas é importante entender o conceito e responder corretamente ao entrevistador.

Refs

[s]
Guto

Este post é do tipo #MindNotes, entenda aqui.

Se gostou manda um alo no twitter @gutocarvalho.


Gostou do conteúdo?

Você também me encontra nessas redes!

Mastodon

@gutocarvalho@bolha.us

PixelFed

@gutocarvalho@bolha.photos

Lemmy

@gutocarvalho@bolha.forum

WriteFreely

@gutocarvalho@bolha.blog @notamental@bolha.blog @poesias@bolha.blog @contos@bolha.blog

Bookwyrm

@gutocarvalho@bolha.review

Peertube

@gutocarvalho@bolha.tube

Friendica

@gutocarvalho@bolha.network

Quer saber mais sobre mim?

Visite meus sites!

E meus blogs:

Conhece o Coletivo Bolha?

Então vem conhecer o bolha.io ou bolhaverso!

Nós temos muito mais para compartilhar contigo!

Quer apoiar nosso trabalho? Você pode!

Te vejo no mastodon da bolha.us!

[s]