MLOps (Machine Learning and Operations) no Azure

O MLOps (Machine Learning e Operations), de forma similar ao DevOps, é a combinação de práticas e ferramentas que permitem aos times de Data Science e Operações melhorar a implementação de modelos, através da governança de modelos de ML (Machine Learning) e IA, monitoramento, validação, colaboração e comunicação.

MLOps-MSFT
Figura: Microsoft Azure – MLOps

Isso porque segundo Gartner, muitas empresas estão desenvolvendo modelos de Machine Learning, mas apenas 47% deles são publicados em produção. E ainda 88% das iniciativas de IA possuem dificuldades para passar do estágio de teste.

Azure ML é composto de interfaces web e SDK que faz o treinamento e deploy do modelo. O processo (figura abaixo) envolve a gestão dos dados, limpeza dos dados, escrevendo e executando experimentos, publicando os modelos para coletar os dados reais (em produção) e aplicar melhorias nos modelos.

MLOps

  • Experiment: os cientistas de dados realizam diversos experimentos, evoluindo e coletando dados, a procura de respostas para as necessidades do negócio. Fundamento nos conceitos de DevOps e da Engenharia de Software, o MLOps sugere práticas para evitar a promoção de modelos mal escritos a outros ambientes.
  • Develop: o treinamento dos algoritmos (Azure ML Training Services), ETL (Data pipelines) e as práticas de CI/CD para criação dos Pipelines (Azure DevOps Pipelines) de deploy dos experimentos construídos de ML.
  • Operate: inference, monitoramento (com uso de analyse/profile, app telemetry, etc.), testes automatizados e data feedback loop para aprendizado com os dados que levam a melhorias nos modelos.

 

Vantagens

Com os times trabalhando juntos (cientistas de dados e operações), encorajam as operações de negócio data-driven, reduzindo o gap entre a descoberta de insights e ações de implementação. Algumas das vantagens são:

  • Reprodutibilidade e auditabilidade: a criação dos modelos em pipelines específicos e reproduzíveis, possibilitando rollbacks (em caso de erros) e auditorias, caso seja necessário algum rastreamento.

  • Validação: herda conceitos de DevOps como validações automáticas, testes, profiling e gestão de ambientes.

  • Habilita automação e observabilidade ao realizar novas implementações. Permite a comparação entre predicted x expected performance. Coleta as informações que servem de treinamentos aos modelos para melhorias futuras.

 

Fases do MLOps

O framework DevOps para soluções AI no Azure pode ser macro representado dessa forma:

Azure-AI-solutions

E compreende quatro principais fases entre a criação até a implantação dos modelos:

  1. Criação e treinamento dos modelos: use o treinamento com pipelines de aprendizado para criar pipelines reproduzíveis, reunindo todas as etapas (da preparação de dados à avaliação do modelo).
  2. Implantação de modelos: empacotamos o modelo para implantação e a criação de perfil para ajudar a configurar memória, CPU e validar os modelos.

  3. Automatizar o aprendizado E2E: atualizar frequentemente os modelos com Azure Machine Learning e GitHub, testar e implementar continuamente com outros aplicativos e serviços.

  4. Trilha de auditoria: coletar os dados de ponta a ponta para estabelecer uma trilha de auditoria. Por exemplo: dados do publicador dos modelos, data de implementação, uso em produção, etc.

fases-MLOpsFigura: Microsoft Azure – MLOps (adaptada)

 

 

Digital Decoupling – atividades na cadeia de valor

book-unlocking-customer-value-chain O termo Digital Decoupling, abordado no livro Unlocking the Customer Value Chain traz conceitos importantes sobre a cadeia de valor das empresas e como os consumidores lidam com elas, responsáveis por produtos ou serviços do nosso interesse.

Tudo isso é considerado como o principal eixo da 3ª onda de disrupção digital, por conta dos impactos em diversas áreas como varejo, bancário e transportes.

E o que seria “desacoplar” então?

Está muito relacionado a evoluir os elementos de TI (de sistemas legados) que estão na cadeia de geração de valor e receita, mantendo os elementos que são commodities. E assim, quebrar os elos existentes das atividades na cadeia de valor.

Os sistemas legados não vão desaparecer de imediato! Por isso, a estratégia de desacoplar é muito relevante, considerando que existem milhares de aplicações, regras de negócio e dados que ainda pertencem aos legados.

vantagem é de habilitar a entrega contínua e processos de inovação sem precisar da migração completa dos sistemas legados.

Digital Decoupling

Utiliza metodologias de desenvolvimento, novas tecnologias e métodos de acesso para permitir a construção de novos apps diante dos legados. Entre algumas características do digital decoupling:

  • Arquitetura escalável e flexível para habilitar agilidade e inovação as empresas;
  • Inclui recursos como data lakes, microsserviços, APIs, RPA, DevOps, etc.
  • Permite a entrega de valor frequente

O propósito é desacoplar o sistema core, através de migração das funcionalidades (ou até mesmo de sistemas, caso esteja inserido em um ecossistema) e dados para novas plataformas baseadas em serviços. Por exemplo, o ecossistema educacional que pode ser aberto a provedores de serviços terceiros, permitindo assim criar novas jornadas e experiência de uso aos clientes.

digital-decoupling

Os principais enablers do Digital Decoupling são:

  • APIs: tem por finalidade, integrar sistemas de forma simplificada e padronizada, prover segurança dos dados e facilitar a troca de informações entre aplicações. Pode ser consumido por apps, aplicações externas, dispositivos IoT, etc. A camada de integração é abstraída do sistema legado e compartilhada com todos os canais, provendo um catálogo de serviços reutilizáveis.
  • Decoupling data: permitir a cultura Data Driven através do uso de Fábrica de dados – gestão eficaz dos dados, Big, Fast e Small Data, e também da implementação do Data Driven Analytics. Criar uma plataforma de dados que permite “desbloquear” o potencial dos dados armazenados, utilizando APIs, ML/AI, Data Lake e Smart Views.
  • Infrastructure & Architecture: garantir a alta disponibilidade, segurança e escalabilidade. O Smart Messaging é uma camada recomendada para processamento de “eventos” e filas de mensagens (real time & event based) ou quando necessita da gestão de grandes volumes. Também contempla os serviços de monitoramento das aplicações e cloud services.

A estratégia de desacoplamento em seu ecossistema pode levar a bons resultados, tais como: arquitetura exponencial, gestão de custos e diminuição de débito técnico. Atualmente, muitas organizações adotaram a estrutura “produtizada” com times multifuncionais. E assim, o Digital Decoupling com elementos de valor desacoplados e foco na estrutura operacional deve ser a próxima evolução de como vamos entregar valor para nossos clientes.

digital-decoupling-evolucao

 

Azure DevOps x Zendesk – Integração com service hooks

O Service Hooks é um recurso interessante do Azure DevOps para habilitar ações, baseadas em eventos que acontecem nos projetos do Azure DevOps. Por exemplo, criar uma notificação no Slack (em algum grupo específico) sobre um deploy bem sucedido. Ele funciona da seguinte maneira:

  • Publisher: define um conjunto de eventos.
  • Subscriptions: recebe os eventos e define as ações (Actions) a serem tomadas. Os consumidores (Consumer) são serviços externos que podem executar suas próprias ações, ao ocorrer algum evento.

service-hooks

Há vários serviços disponíveis no Marketplace que permitem a integração com o Azure DevOps Services. Veja a relação dos principais abaixo:

services-azure-devops

Neste post, vamos abordar a integração do Azure DevOps com o Zendesk.

1. Criando os conectores

O primeiro passo é instalar o IntegrateCloud Connector for VSTS no Zendesk. Vá no Marketplace e execute a instalação.

instalacao-integrate-cloud-azure

Você irá precisar de um Token (do lado do Zendesk) para permitir a integração com o Azure DevOps. Acesse no Zendesk a [Engrenagem de Admin] > Canais > API e ative o acesso por token, conforme imagem abaixo. Salve este token.

API-zendesk

Feito isso, acesse o Azure DevOps e configure o Service Hook do Zendesk para permitir a manipulação dos work items externamente. Para isso, acesse Project Settings > Service Hooks e adicione um novo Serviço do Zendesk.

  • A tela seguinte solicita Area Path e Work Item Type desejado.
  • Na última tela, insira a conta, usuário e token gerado no Zendesk.

new-service-hooks

Também adicione um token do lado Azure DevOps para prover a autorização da configuração do Service Hook, feito acima. Acesse “Personal access tokens” e insira um nome para ele. Salve este token também.

token-service-hooks

2. Integração de work items

Na sequência, crie um novo ticket (ou acesse algum já criado) no Zendesk e configure a área de Aplicativos (lado direito da tela). Insira a URL da conta do Azure DevOps e o Token que acabamos de gerar no passo anterior.

ticket-zendesk

Feita a autenticação, a tela abaixo (do IntegrateCloud Connector for VSTS) irá aparecer. Preencha o Projeto (Area Path) e a  Sprint (Iteration) que deseja publicar esse work item. Salve a modificação.

integratecloud-connector-vsts

Veja que o ticket criado no Zendesk agora foi criado como work item (pode ser do tipo task / bug / epic / feature / user story) no Azure DevOps. Pronto! A integração entre os dois está funcionando.

board-azure-devops

Lembrando que o Service Hooks é um recurso para para habilitar ações, baseadas em eventos e que pode ser utilizado na integração com diversos sistemas (conforme mostrado no início do artigo). Aqui fizemos uma demonstração com o Zendesk.

Priorização de requisitos e projetos – product management

Com a evolução contínua no modelo de negócios, onde as empresas precisam de adaptação rápida e time to market, um bom critério de priorização é primordial para avaliar os projetos (ou requisitos dos times) e evitar desperdícios, além de maximizar ao máximo a entrega de valor ao negócio.

Muitas empresas ainda estão viciadas no ciclo de receber/trabalhar/entregar muita demanda, porém isso entrega valor ao negócio? E quanto aos critérios de priorização? Desta forma, vamos abordar algumas técnicas de priorização que ajudam a direcionar o esforço das equipes, baseado em critérios.

Outro ponto é a aplicabilidade. As técnicas abaixo foram criadas com um propósito específico (a serem utilizadas em projetos ou requisitos), mas podem ser adaptadas a outros níveis (time, programa ou portfólio). Também vale avaliar se o mercado é B2C ou B2B, pois a validação de hipóteses com os usuários finais podem gerar indicadores que servem como critério de priorização (tais como conversão, churn, uso, etc.).

MoSCoW

O MoSCoW (Must haveShould haveCould have and Won’t have) é uma das técnicas de priorização, geralmente utilizada com timeboxing – deadline fixado e o foco é nos requisitos mais importantes. Ajuda a comunicar o que será feito de imediato ou não.

  • Must Have (Deve Ter): são as funcionalidades imprescindíveis para o projeto. Devem ser refinadas (ou aprofundadas) para melhorar o entendimento do time.
  • Should Have (Deveria Ter): é importante ter, mas não são imprescindíveis.
  • Could Have (Poderia Ter): seria bom ter, mas não são essenciais. Porém, entregá-las pode ser um diferencial ao cliente.
  • Won’t Have for Now (Não Terá por Enquanto): por hora não será feito, já que não gera valor ao negócio naquele momento.

moscow

RICE

Outro acrônimo para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e divididos pelo último. Isso ajuda a medir o impacto de cada tarefa no todo e a determinar a prioridade mais alta do backlog.

Fórmula: R * I * C / E

  • Reach: qual o alcance desta tarefa (pessoas impactadas)?
  • Impact: o grau do impacto nas pessoas
    • Impacto Massivo: 3
    • Grande Impacto: 2
    • Médio: 1
    • Baixo: 0,5
    • Impacto Mínimo: 0,25
  • Confidence: quão confiante estamos nas estimativas
    • Alta confiança: 100%
    • Confiança média: 80%
    • Baixa confiança: 50%
    • Mínima confiança: 20% ou menor
  • Effort: o tempo necessário para concluir a tarefa

 

BASICO

A BASICO possui seis critérios que apoiam a priorização de projetos e processos. Cada critério é pontuado de 1 a 5 e o resultado é a soma dos critérios (1 = pior cenário; 5 = melhor cenário). As maiores notas são priorizadas.

  • Benefícios para a empresa
  • Abrangência dos resultados
  • Satisfação do cliente interno
  • Investimento necessário
  • Cliente externo satisfeito
  • Operacionalidade simples

 

GUT

Outra opção é a GUT que possui três critérios e pontuação de 1 a 5 também para classificar a prioridade dos projetos.

  • Gravidade: classifica as ações que você precisa realizar conforme o impacto que elas terão em outras atividades ou projetos;
  • Urgência: considera o tempo restante para resolver cada situação;
  • Tendência: é uma projeção da velocidade que um problema não resolvido pode levar para piorar.

gut

 

WSJF (Weighted Shortest Job First)

A técnica WSJF, criada por Don Reinertsen e recomendada no SAFe, apoia a priorização de features, maximizando o custo do atraso (COD – Cost of Delay) e a duração do trabalho. E assim, em regra geral:

  • Features com a mesma duração = priorizar as que possuem maior custo do atraso, pois assim minimizaria o custo total.
  • Features com o mesmo custo de atraso = priorizar as que podem ser lançadas mais rapidamente, pois assim minimizaria o custo do atraso.

Como o custo do atraso e duração das features podem variar muito de uma para outra, o WSJF contribui muito na priorização com a seguinte fórmula:

  • WSJF = Cost of Delay / Job Duration (Job size)

E o custo de atraso é calculado da seguinte forma:

  • Cost of Delay = User Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

WSJFFonte: SAFe (Scaled Agile Framework)

 

Technical Certainty x Business Agreement

Entre as diversas matrizes que existem para priorização de requisitos, a matriz da Tech and Business Review da Lean Inception é uma que sintetiza bem o valor do negócio x esforço para construção das features. Possui nove quadrantes.

  • Technical Certainty: como o time de desenvolvimento avalia a complexidade para criar a funcionalidade.
  • Business Agreement: quão bem o negócio concorda com o que entra na feature.

As features de certeza técnica baixa (E) e valor de negócio baixo ($) são descartadas do MVP de imediato. Assim como, certeza técnica média (EE) e valor de negócio baixo ($); também são descartadas as features do quadrante certeza técnica baixa (E) e valor de negócio médio ($$). As demais serão avaliadas conforme a técnica da Lean Inception.

business-effort-matriz

Outras técnicas

  • Modelo Kano
  • QFD (Quality Function Deployment)
  • Opportunity Scoring
  • Buy a feature
  • Matriz de Eisenhower (Urgência X Importância)
  • Matriz Esforço x Impacto
  • Matriz de Custo x Benefício

Disciplined Agile Delivery (DAD) vs Scrum vs SAFe

Já abordamos o Disciplined Agile Delivery (DAD) em posts anteriores, e um resumo de como está estruturado – em três fases: Inception, Construção e Transição. Os aspectos de arquitetura e design (Inception) e DevOps (Transição) são alguns dos pontos interessantes do DAD.

Também fornece mais flexibilidade nas recomendações do projeto, através dos melhores processos para cada tipo de projeto (dependendo do que será construído), ao invés de prover um plano prescritivo. O DAD possui quatro modelos de ciclo de vida: agile/basic, lean/advanced, continuous delivery, and exploratory.

Outros frameworks muito conhecidos e utilizados em agilidade são: o Scrum para desenvolver, entregar e manter produtos complexos e o SAFe (Scaled Agile Framework), que sincroniza o alinhamento, a colaboração e a entrega para um grande número de equipes.

Papeis

O DAD atribui o Team Lead como responsável por manter o time focado no cumprimento dos objetivos, remoção de impedimentos e a expertise em processos ágeis. Também inclui o Architecture Owner para decisões e prioridades técnicas. Os papeis secundários geralmente ocorrem em necessidade de escala.

DAD

Papeis primários
• Team Lead
• Product Owner
• Architecture Owner
• Team Member
• Stakeholders

Papeis secundários
• Independent Testers
• Specialists
• Domain  Expert
• Technical Expert
• Integrator

 

 

 

SAFe

Time
• Product Owner
• Scrum Master
• Time de desenvolvimento

Programa
• Product Management
• Release Train Engineer
• System Architect

Large Solution
• Solution Management
• Solution Train Engineer
• Solution Architect

Portfolio
• Lean Portfolio Management
• Epic Owners
• Enterprise Architect

Scrum

Time Scrum
• Product Owner
• Scrum Master
• Time de desenvolvimento

 

 

 

 

 

 

 

 

 

Artefatos

Enquanto o Scrum possui artefatos direcionados ao time (backlog do produto e da sprint, burn down e incremento), o DAD e SAFe são mais abrangentes em relação a perspectiva do projeto.

DAD

• Business and Technology Roadmap
• Initial Requirements and Architectural Vision
• Iteration Backlog

 

 

 

 

SAFe

Portfolio
• Investment Themes
• Business and Architecture Epics
• Portfolio Backlog and Vision

Programa
• Product Roadmap
• Program Backlog
• Architecture Runway
• Business and Architecture Features

Time
• Team Backlog
• Team PSI Objective
• Sprint Goals

Scrum

• Product Backlog
• Sprint Backlog
• Gráfico Burn Down
• Incremento

 

 

 

 

 

 

 

Processos

Em processos, o Scrum também possui uma boa estrutura a nível de time, enquanto o DAD e SAFe são mais abrangentes, por considerarem custos, sincronização entre times e estratégia de priorização de projetos.

DAD

Inception
• Formação de time, visão comum, escopo inicial, estratégia técnica, de custos, riscos e release plan

Construction
• Desenvolver a Potentially Consumable Solution, endereçando necessidades dos stakeholders (e mudanças) considerando a qualidade e uso da arquitetura acordada

Transition   
Deploy e o uso da solução
• Melhorias nos processos, ambientes e infraestrutura

SAFe

Portfolio
• Temas estratégicos, épicos, portfólio e budget aos value streams

Large Solution
• Capabilities, Large Solution (Backlog e Kanban)
e Solution Planning / Demo

Programa
• Features, Program Backlog, WSJF, PI (Program Increment) – System Demos e Inspect and Adapt

Time
• User Stories, Team Backlog, Sprint Backlog e conduzir as Sprints

Scrum

•  User Stories, Sprint Backlog e Sprints (Planning, Daily, Review e Retro) e criação do incremento

 

 

 

 

 

 

 

Por fim, vimos acima uma breve explicação e comparação entre DAD, SAFe e Scrum, que podemos resumir da seguinte forma:

  • DAD: é híbrido entre os métodos existentes e fornece flexibilidade para usar várias abordagens. Considera aspectos de iniciação e implementação (full delivery lifecycle). É people-first, learning-oriented e Hybrid agile.
  • SAFe: é mais prescritivo e fornece uma estrutura em diferentes níveis (time, programa e portfólio) que pode facilitar a transição para uma estrutura ágil, além de ser aplicável a um grande número de times (ágil em larga escala).
  • Scrum: aplicável a times individuais, usado para gerenciar o trabalho em produtos complexos. Consiste de times Scrum associados a papéis, eventos, artefatos e regras.

Service Design e o entendimento do perfil dos consumidores

Dentre as várias definições que encontramos sobre Service Design, o Wikipedia resume  como: “a atividade de planejar e organizar pessoas, infraestrutura, comunicação e componentes materiais de um serviço de forma a melhorar sua qualidade e a interação entre a empresa provedora do serviço e os consumidores.”

Fundamentado em práticas de Design, o Service Design visa o entendimento do perfil dos consumidores (todas as pessoas envolvidas no serviço) e suas necessidades para prover um serviço que atenda as expectativas e tenha relevância a quem utilizar. E assim, baseado em levantamentos (perguntas), cria-se um framework de como o serviço irá funcionar.

Onde está inserido o Service Design?

Enquanto o UI Design foca em como o usuário interage com o produto, o UX Design busca compreender os aspecto emocionais que fizeram o usuário a ter essa interação. Já o Service Design abrange com tudo e todos que interagem na entrega de um serviço.

service-design

 

Estágios do Service Design

Existem diferentes propostas de estágios para Service Design, de acordo com a adaptação ou autor referenciado. Um resumo do que tenho utilizado:

  • Pre-work: envolve a criação dos times, comunicação, objetivos, ground rules e planejamento das atividades.
  • Observation: compreender como os serviços estão sendo utilizados e obter os insights iniciais. Utiliza-se ferramentas de pesquisa, etnografia do público e personas.
  • Understanding/thinking: geração de ideias para cocriar soluções, protótipos, testes e visualizar comportamentos. Técnicas como customer journey mappingprototyping são utilizadas. Também role-playing, roteiros, entre outros, que possibilitem reconstruir um caso de uso do serviço com o máximo de fidelidade.
  • Implementing: implementação e testes. Quais métricas determinam o sucesso? Este entendimento direciona as mudanças necessárias para que o novo serviço seja operacionalizado. A ferramenta de Blueprint (Service Blueprint) é utilizada nesta fase.
  • Maintenance and continuing feedback loop: mesmo após a implementação, continuamente monitorar, aprender e refinar (se necessário) a próxima criação.

Princípios e leituras sobre o Service Design

service-design-thinking O livro This is Service Design Thinking aborda cinco princípios para maximizar a qualidade dos serviços:

  • Centrado no usuário
  • Cocriativo
  • Sequencial
  • Evidenciado
  • Holístico

Livros relacionados

  • This is Service Design Thinking
  • Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers
  • Design Thinking: Integrating Innovation, Customer Experience, and Brand Value
  • Designing for the Digital Age
  • Building Design Strategy: Using Design to Achieve Key Business Objectives

Ferramentas do Service Design

Algumas ferramentas muito utilizadas pelos Designers ou pessoas que estão utilizando o Service Design:

  • Service Blueprints
  • Customer Journey Maps
  • Design Ethnography
  • Value Proposition Canvas
  • Surveys
  • Scenarios

E muitas outras no site https://servicedesigntools.org/tools.

Concluindo

O Service Design mostra-se uma boa opção quando precisamos desenvolver ou otimizar serviços, afim de melhorar a interação com os consumidores, por exemplo aumentar o NPS seria um tema apropriado para ir com o Service Design.

E por que não utilizar o Design Thinking? O Design Thinking coloca o usuário ao centro e auxilia com a abordagem divergente e convergente para resolver problemas. Trata-se de empatia e human centricity, mais utilizada para o entendimento de usuários em particular.

NoOps é aplicável a sua organização?

Em 2011, a Forrester já publicava um artigo sobre NoOps e como a automação de algumas operações – build, deploy, testes, etc. levaria mudanças as equipes de infra, reduzindo a necessidade de interação com outras equipes e até mesmo da redução de recursos, substituídos por estes processos automatizados.

Claro que, após todos estes anos, e com os resultados obtidos pela disseminação do DevOps (foco na colaboração entre os times e automação) nas organizações, vimos que não é simples e tampouco mágica manter uma área de operações “rodando” em automático. E por isso, hoje o drive está muito relacionado ao trabalho eficiente, melhorando os resultados obtidos pela automação e forma de atuação no trabalho.

Agora em 2019, talvez o conceito de que DevOps possui foco em colaboração e NoOps em automação esteja mudando, pois é mesmo possível automatizar todas as tarefas de infraestrutura? E nas práticas DevOps já não existe forte colaboração entre os times mesmo com automação de inúmeros processos?

Aplicabilidade

Neste novo patamar atingido por serviços Cloud, os recursos podem ser abstraídos da infraestrutura subjacente, e as atividades de provisionamento e implantação de infraestrutura agora são gerenciadas por meio de serviços de infraestrutura e plataforma sob demanda.

O NoOps segue então como tendência ao ambiente que seja automatizado e abstraído da infraestrutura, podendo ser gerenciado por equipes menores e eficientes. Torna-se impossível viabilizar operações em grande escala com execução manual de atividades. A Deloitte Insights traz análises de adoção nas organizações.

É então mais recomendável a ambientes de TI homogêneo com pouca diversidade no nível da infraestrutura. O stack diversificado de tecnologia (aplicações e infraestrutura) e o comum histórico das mudanças no nível de infraestrutura (dinâmicas e distribuídas) tornam muito mais complexa a adoção NoOps nestes ambientes.

DevOps e NoOps

DevOps (by Microsoft) “É a união de pessoas, processos e produtos para permitir a entrega contínua de valor aos nossos usuários finais. A contração de “Dev” e “Ops” refere-se à substituição do Desenvolvimento e Operações em silos para criar equipes multidisciplinares que agora trabalham em conjunto com práticas e ferramentas compartilhadas e eficientes. As práticas essenciais do DevOps incluem planejamento ágil, integração contínua, entrega contínua e monitoramento de aplicativos”.

NoOps significa nenhuma operação. O foco é automatizar todas as tarefas de manutenção associadas ao desenvolvimento e à execução de uma solução. Isso não é uma missão simples, mas possível, considerando que os provedores de serviços terceiros podem executar tarefas de implantação, gerenciamento e manutenção, tal como o EKS da Amazon. E assim, não há necessidade de alta interação entre os times para tornar possível a conclusão do trabalho.

Os provedores de nuvem continuam subindo o stack, assumindo muitas tarefas de administração de sistemas, tais como aplicação de patches, backup e gerenciamento de banco de dados, entre outras. 

Fonte: Appdynamics 

Traditional Ops e NoOps

As operações de TI não desaparecem apenas com a adoção de plataformas em cloud  pública. Entre algumas evoluções na gestão operacional:

  • Automação: na maior parte das tarefas operacionais, sendo norma e não mais exceção.
  • Proativo: o uso de informações preditivas orientadas por IA para monitorar e otimizar serviços de TI, para que as equipes de Ops possam se concentrar em iniciativas voltadas para o cliente.

traditional-ops-noops
Fonte: https://blog.opsramp.com/devops-noops

Na prática

Além das considerações de aplicabilidade (citadas anteriormente) em relação a manutenção e ambientes legados, outro ponto de atenção é a absorção de novas atividades aos desenvolvedores. Além do interesse em administrar suas próprias soluções, vale verificar o processo para não gerar gargalos.

Como NoOps é habilitado por tecnologia, existem algumas opções PaaS como Heroku e serviços cloud na AWS e Azure. Serverless computing e replicable infrastructure são também boas soluções para resolver a parte da infraestrutura e as ferramentas tradicionais de implantação.