DevOps e SRE, qual a diferença?
Fala galera! Seis tão baum?
Já faz um tempo que estou me programando para trazer conteúdo relacionado à DevOps e SRE (Site Reliability Engineer), são dois conceitos que ganharam muita força nos últimos anos.
Mas afinal o que é DevOps, o que é SRE, e qual é a diferença entre essas duas metodologias.
Opa, metodologia, cultura, conceito? Uai, DevOps e SRE não são títulos? 😲
Calma, meu jovem Padawan!
Não é um título
Sim, DevOps e SRE não são títulos e sim uma prática. Por definição deveria ser assim, na prática não é.
Hoje em dia é comum ver títulos de DevOps Engineer e Site Reliability Engineer em todo lugar, para os puristas isso definitivamente é um aborrecimento, mas a verdade é que essa batalha já foi perdida LoL 😂.
Vou explicar um poco de cada conceito para que essa questão fique mais clara a você.
É um título
O mercado está a procura de DevOps Engineer e Site Reliability Engineer, e hoje são os cargos de tecnologia mais bem pagos do mundo, então meu amigo, se é o tipo de trabalho que você quer fazer mete ficha e se torne um DevOps Engineer ou Site Reliability Engineer.
Se os recrutadores e o Linkedin já entende que é um título/cargo, aproveite o momento e fique longe desta batalha!
Bom, antes de mais nada, vamos entender o que é DevOps e o que é SRE, só assim vamos chegar próximo a pergunta de 1 milhão de dólares: Qual é a diferença entre DevOps e SRE.
O que é DevOps?
A definição oficial de DevOps foi cunhado pela primeira vez por Patrick Debois em 2008, o objetivo que eles queriam obter com o DevOps era quebrar as barreiras entre as equipes de desenvolvimento e operações.
O DevOps surgiu em conexão com o movimento ágil como resultado da necessidade de aumentar a frequência e velocidade de lançamentos de produtos mantendo ou melhorando um determinado padrão de qualidade.
DevOps (sigla em inglês para Dev - desenvolvimento - e Ops - operações -) é um conjunto de práticas que agrupam desenvolvimento de software (Dev) e operações de TI (Ops). O objetivo é acelerar o ciclo no vida de desenvolvimento de software e fornecer entrega contínua de alta qualidade.
Veja, começa ficar claro que DevOps não é um título e sim uma abordagem para o desenvolvimento de software.
Resumindo, não é título, não é metodologia, não é software, mas sim um modo de trabalhar para melhorar e integrar práticas, processos e sistemas.
E é por isso que você já deve ter escutado que DevOps não é cargo e sim uma cultura.
Gosto muito da definição da Microsoft para DevOps:
DevOps é a união de pessoas, processos e produtos para automatizar a entrega de softwares, viabilizando continuamente a entrega de valor para os usuários.
Dito isso, já podemos trazer a representação clássica do infinito DevOps. LoL
Alguns dos princípios básicos na adoção do DevOps
A adoção de práticas DevOps requer uma mudança cultural e afeta toda a organização.
- Ação centrada ao cliente
As equipes de DevOps usam ciclos curtos de feedback com clientes e usuários finais para desenvolver produtos e serviços centrados nas necessidades do usuário. As práticas de DevOps permitem coleta e resposta rápidas ao feedback do usuário por meio do uso de monitoramento em tempo real e implantação rápida.
- Foco no resultado final
Esse princípio envolve entender as necessidades dos clientes e criar produtos ou serviços que resolvam problemas reais. As equipes não devem criar software com base em suposições sobre como os consumidores usarão o software. Em vez disso, as equipes de DevOps devem ter uma compreensão holística do produto, desde a criação até a implementação.
- Responsabilidade de ponta a ponta
Quando cada membro de uma equipe se move em direção a um objetivo e é igualmente responsável por um projeto do início ao fim, eles trabalham de forma coesa e procuram maneiras de facilitar as tarefas de outros membros
- Equipes autônomas e multifuncionais
A premissa principal por trás do DevOps é a colaboração. Os membros de uma equipe de DevOps são responsáveis por garantir entregas de qualidade em cada fase do produto.
As equipes de desenvolvimento e operações se unem em uma equipe funcional que se comunica, compartilha feedback e colabora durante todo o ciclo de desenvolvimento e implantação.
- Melhoria Contínua
Em uma cultura DevOps, um forte foco é colocado na melhoria contínua para minimizar o desperdício, otimizar a velocidade, os custos e a facilidade de entrega e melhorar continuamente os produtos/serviços oferecidos.
- Automatize tudo o que puder
Automatizar o maior número possível de procedimentos de desenvolvimento, teste, configuração e implantação é a regra de ouro do DevOps. Ele permite que os especialistas se livrem do trabalho repetitivo demorado e se concentrem em outras atividades importantes que não podem ser automatizadas por sua natureza.
Habilidades principais responsabilidades do DevOps Engineer
Embora não seja uma regra que para ser um DevOps Engineer você seja um administrador de sistemas ou desenvolvedor, é muito importante que você tenha experiência em ambos os lados.
- CI/CD (continuous integration CI e continuous delivery CD)
- Infraestrutura como código (IaC)
- Contêiner e orquestração
- Gerenciamento de serviços em nuvem
- Scripts
- Automação e tetes
Olhando para a lista acima, você deve estar se perguntando: vixe, isso é muita coisa! E a resposta é sim!
E é por essa razão que as posições de DevOps Engineer ou um Site Reliability Engineer não são de nível básico.
É necessário anos para coletar todas essas habilidades.
DevOps Engineer ou Site Reliability Engineer não são funções de nível iniciante, é uma função de nível avançado. É extremamente importante manter isso em mente.
Antonio, eu já vaga de DevOps Engineer Júnior!
Postei e sai correndo…
Estou lhe desanimado a se tornar um DevOps Engineer? De forma alguma, só estou lhe orientando a manter os pés no chão e continuar focado no seu desenvolvimento profissional, a medida que você vai acumulando experiência, o caminho vai se tornando natural.
O que é SRE (Site Reliability Engineer)?
O conceito de SRE surgiu em 2003 por parte da equipe de engenharia do Google e é creditado ao engenheiro Ben Treynor Sloos. Ele descreve o termo SRE como “o que acontece quando um engenheiro de software é encarregado do que costumava ser chamado de operações”
Com foco na confiabilidade do sistema, o objetivo do SRE está em encontrar formas para aprimorar o design e a operação dos sistemas para fazê-los mais escaláveis, confiáveis e mais eficientes. Em geral, uma equipe SRE é responsável pela disponibilidade, latência, desempenho, eficiência, gerenciamento de mudanças, monitoramento, resposta a emergências e planejamento de capacidade dos serviços sob sua supervisão.
Ufa, tudo isso? Postei e sai correndo [2]…
Resumindo, a equipe de SRE garante que a plataforma ou serviço esteja disponível para os clientes sempre que quiserem usá-la.
O Google publicou um livro sobre SRE, ele está disponível gratuitamente on-line. Sugiro fortemente a leitura, em especial as seções 2 e 3, princípios e práticas.
Segue o link para os livros: SRE Books
De acordo com o Google, os princípios fundamentais do SRE são:
- Adoção do risco: fornece abordagens neutras ao Service Management usando orçamentos de erro.
- Objetivos de nível de serviço: fornece recomendações para indicadores desintegrados a partir de contratos e examina como o SRE usa os termos.
- Eliminação de esforço: afastando-se de tarefas mundanas e repetitivas que são desprovidas de valor.
- Monitoramento de sistemas distribuídos: sempre evite fechar os olhos para o que está acontecendo na organização por causa da confiabilidade.
- Engenharia de versões: considere cuidadosamente as versões para garantir que elas sejam consistentes e não contribuam com indisponibilidades.
- Simplicidade: um sistema muito complexo pode reduzir a confiabilidade e dificultar o dimensionamento para um local mais simples.
Hierarquia de Confiabilidade do Serviço
Diferenças entre DevOps e SRE
Verdade seja dita, não há muitas diferenças entre os dois. Ambos se baseiam nos mesmos princípios.
SRE e DevOps não são conceitos concorrentes. Em vez disso, SRE e DevOps são dois lados da mesma moeda com um propósito compartilhado.
Simplificando, DevOps está mais para escrever e implantar código. Já o SRE, é mais abrangente, adotando uma perspectiva mais ampla e com foco no ‘usuário final’.
Comparação lado a lado
| DevOps | Site Reliability Engineer |
|---|---|
| Entrega | Operações |
| Automação | Resposta a incidentes |
| Criação de ambientes | Post Mortems |
| Gerenciamento de configurações | Monitorar eventos e alertas |
| Infraestrutura como código | Plano de capacidade |
| Foco primário: Velocidade de entrega | Foco primário: Confiabildiade |
Semelhanças entre DevOps e SRE?
Sem dúvida! A verdade é que SRE e DevOps têm muitas coisas em comum, ambos são metodologias implementadas para monitorar e garantir que tudo funcione conforme o esperado.
Ambos acreditam no trabalhando em equipe e na responsabilidade compartilhada, desde a escrita do código até a implantação, produção e manutenção.
Como a maior parceria heroica dos quadrinhos!
Batman e Robin
Qual caminho escolher?
Resposta de Sênior: Depende. LoL 😂
Brincadeiras à parte, essa é uma pergunta que ninguém pode responder por você!
Meu conselho: não se prenda a siglas ou títulos. O mais importante é olhar para cada “cargo” e entender qual se alinha melhor com você e que trará benefícios para sua carreira.
No fim, o mais importante é o resultado que você entrega e não o título que você carrega.
É isso galera, espero que gostem.
Forte abraço a todos!