DevOps vs SRE: entenda as principais diferenças

Neste artigo você vai ver:

DevOps e SRE são dois termos bastante usados atualmente no mercado de tecnologia e que sempre são confundidos. Apesar de se relacionarem, não fazem obrigatoriamente referência ao mesmo conceito, muito menos as pessoas que atuam com isso. 

Tem interesse em saber, de uma vez por todas, a diferença entre DevOps e SRE? Então continue lendo.

Devops

O termo foi sugerido por Andrew Shafer e Patrick Debois em 2008. Apesar de ter demorado alguns anos para virar um conceito comum, nos dias atuais, praticamente todas as empresas contam com DevOps

E resumo, esse é um método de desenvolvimento de software onde o principal objetivo é aprimorar a capacidade de distribuir em alta velocidade aplicativos e serviços.

Entenda os 4 pilares da cultura DevOps

  • Colaboração: é o passo além da comunicação, aqui o objetivo é facilitar a integração entre as equipes (de diversas áreas). Esse pilar busca alcançar um processo simplificado, colocando em prática soluções colaborativas que resolvam ou minimizem os problemas enfrentados.
  • Afinidade: é importante que o time tenha os mesmos objetivos organizacionais, empatia e aprendizagem entre diferentes grupos de pessoas.
  • Ferramentas: usadas para acelerar processos e economizar custos. Porém, devem sempre se encaixar nos métodos de trabalho.
  • Dimensionamento e escala: os conceitos de DevOps podem ser aplicados em vários tipos de organizações independente do estágio: crescimento, amadurecimento e até retração.

Em outras palavras, quando usamos o termo DevOps para se referir a uma pessoa profissional, falamos de quem segue as boas práticas sugeridas pelo movimento DevOps, porém isso não representa um cargo. Tanto devs, analistas ou outras pessoas que atuem na área de engenharia podem ser profissionais DevOps.

Quer saber mais sobre DevOps? Então eu recomendo ouvir essa edição do ZupCast:

Site Reliability Engineering (SRE)

Já o conceito de SRE existe desde 2003. Quem criou foi Ben Treynor, fundador do Site Reliability Team do Google.

Segundo Treynor, o SRE é “o que acontece quando um engenheiro de software é encarregado do que costumava ser chamado de operações”. É uma disciplina que envolve aspectos da engenharia de software e os aplica a problemas de infraestrutura e operações. Seu principal objetivo é criar sistemas de software escaláveis e altamente confiáveis.

O cargo de Site Reliability Engineer é responsável pela disponibilidade, eficiência, gerenciamento de mudanças, monitoramento, resposta a emergências e planejamento de capacidade. 

O papel dessa função é criar uma ponte entre desenvolvimento e operações. Assim, aplicando uma mentalidade de engenharia de software aos tópicos de administração do sistema e buscando automatizar ao máximo os processos.

Por exemplo: 

Uma empresa mais nova pode precisar do suporte de uma pessoa SRE para controlar as interrupções gerais.

Entretanto, outras empresas que estão mais maduras nessa jornada podem ter eliminado as interrupções em toda a organização. Assim, nesse caso, as pessoas SREs podem gastar mais tempo aprimorando ou validando métricas de serviço relacionadas aos negócios.‍

Quer tirar de letra o Site Reliability Engineering (SRE)? Então assista a esse Zup Open talks com o Daniel Colchete sobre o tema e como funciona no Google.

DevOps e SRE: quais as diferenças? 

Em 2018, o Google escreveu um artigo sobre DevOps e SRE explicando que:

“Não são dois métodos concorrentes para desenvolvimento e operações de software, mas sim amigos íntimos projetados para quebrar as barreiras organizacionais e oferecer um software melhor mais rapidamente.”

Porém, ainda hoje essa diferenciação não está clara no mercado, e até o Google criou sua própria definição. 

DevOps e SRE na prática

Veja um exemplo de um pipeline de um processo de entrega contínua automatizado (no Jenkins ou em uma outra plataforma como Travis ou Bamboo). Ambos poderiam ser planejados por profissionais com bom domínio das práticas DevOps.

Arte colorida mostrando o Ideal Continuous delivery process, onde os Continuous Integration Servers são o Jenkins, Travis e Bamboo. Ele segue, respectivamente, a ordem Source code management, Build tools, Code quality analysis, Testing frameworks, Store valid binaries; packages, Configuration Management and deployment tools e Deployment environment.

Os times de desenvolvimento e de operações escolheriam em conjunto as ferramentas que usariam para cada parte do pipeline. Já a pessoa com foco em Site Reliability Engineer seria quem garantiria como tudo isso seria feito.

No exemplo acima, a pessoa SRE cuidaria de cada pedaço do pipeline separadamente em um primeiro momento. Assim, o segundo passo seria juntá-los ao longo do ciclo de vida do projeto, melhorando o modelo para tornar cada vez mais perto do planejamento inicial (quanto mais automatizado melhor).

Em outras palavras, é a pessoa SRE que vai construir e implementar essas soluções de acordo com as métricas definidas pelo time ou empresa. Além disso, também vai monitorar essa infraestrutura ao longo do seu amadurecimento. 

Portanto, através desse exemplo, entendemos que as pessoas SREs precisam ter um ótimo conhecimento das práticas e da cultura DevOps. Assim, terão mais facilidade na hora de encontrar as propostas de estrutura mais adequadas às necessidades. 

Conclusão

Como pudemos acompanhar, quando profissionais de SRE com um conhecimento de DevOps temos um ciclo de desenvolvimento de software ágil, seguro e estável.

Quer receber em primeira mão conteúdos como esse por e-mail? Então inscreva-se agora mesmo em nossa newsletter.

Quero saber sua opinião! Então, deixe seu comentário com dúvidas e questionamentos sobre o assunto.

foto Guillaume Falourd
Back-end Developer
Zupper tentando transformar o complexo em simples através de conteúdos diversificados, com intuito de impactar o mercado de TI e as pessoas ao seu redor da melhor forma possível.

Este site utiliza cookies para proporcionar uma experiência de navegação melhor. Consulte nossa Política de Privacidade.