Gerenciar análise em escala de nuvem

Hoje, o DevOps mudou a cultura de como as pessoas pensam e trabalham, acelerando a taxa na qual as empresas percebem valor, ajudando indivíduos e organizações a desenvolver e manter práticas de trabalho sustentáveis. O DevOps combina desenvolvimento e operações e geralmente é associado a ferramentas de engenharia de software que dão suporte a práticas de CI (integração contínua) e CD (entrega contínua). Essas ferramentas e práticas incluem gerentes de código-fonte (como Git, Apache Subversion ou Team Foundation Version Control) e gerenciadores automáticos de build e entrega (como o Azure Pipelines ou o GitHub Actions).

O DevOps combinado com a observabilidade é fundamental para fornecer uma plataforma ágil e escalonável. O DevOps oferece às equipes a capacidade de implementar controle do código-fonte, pipelines de CI/CD, infraestrutura como código, fluxos de trabalho e automação. Embora a observabilidade permita que os proprietários de negócios, engenheiros de DevOps, arquitetos de dados, engenheiros de dados e engenheiros de confiabilidade do site detectem, prevejam, impeçam e resolvam problemas de forma automatizada e evitem eliminar o tempo de inatividade que, de outra forma, interromperia a análise de produção e a IA.

Controle do código-fonte

O controle de versão garante que o código e as configurações persistam e que as alterações sejam rastreadas e versionadas. A maioria dos sistemas de controle do código-fonte também tem processos internos para revisão e trabalho em diferentes ramificações de um repositório de código. Atualmente, o tipo de controle do código-fonte mais popular atualmente é o Git, que é um sistema de controles de versão distribuída que permite que os indivíduos trabalhem offline e sincronizem com repositórios centrais. Os provedores de Git normalmente também usam branches e seguem as diretrizes de pull requests para suporte ao fluxo de alterações e revisões.

As ramificações de código isolam alterações ou o desenvolvimento de funcionalidades, sem interferir em outros trabalhos que ocorrem simultaneamente. O uso de branches deve ser promovido para desenvolver recursos, corrigir bugs e experimentar com segurança novas ideias. Pull requests mesclam as alterações feitas de um branch para o branch padrão e suportam um processo de revisão controlado. Para fins de segurança, o ramo principal deve usar pull requests para garantir revisões de código.

Pipelines de CI/CD

A CI permite que as equipes testem e criem código-fonte automaticamente e permite iterações rápidas e loops de comentários para garantir a alta qualidade do código no CD. Pipelines são maneiras de configurar a CI de alterações (código de software ou código de infraestrutura) e CD das alterações empacotadas/compiladas. Isso também é conhecido como build e versão. O CD descreve a implantação automática de aplicativos em um ou mais ambientes. O CD geralmente segue um processo de CI e usa testes de integração para validar todo o aplicativo.

Os pipelines podem conter vários estágios com várias tarefas e podem ter fluxos de aprovação simples e complexos para garantir a conformidade e a validação. Os pipelines podem ser configurados com vários gatilhos automáticos, de acordo com a preferência. Para implantação de IA e escala empresarial, as etapas de produção sempre devem ter a pré-aprovação humana e isso é integrado ao modelo de operação. Os pipelines de CI/CD devem ser criados com o GitHub Actions ou o Azure Pipelines e devem ser gatilhos automatizados.

Infraestrutura como código

O termo código em IaC geralmente levanta preocupações em equipes de TI sem experiência em desenvolvimento, mas IaC não se refere a escrever código como os desenvolvedores de software costumam fazer. No entanto, ele adota muitas das mesmas ferramentas e princípios dos processos de desenvolvimento de software para fornecer infraestrutura em um formato previsível.

A IaC ajuda a infraestrutura a ser provisionada, configurada e gerenciada como parte de um pipeline de DevOps com controles de alteração completos, histórico de auditoria, testes, validações e processos de aprovação, garantindo que as tarefas possam ser delegadas às funções apropriadas para o projeto sem comprometer a segurança e a conformidade.

As duas abordagens para IaC são declarativas e imperativas:

• Declarativo refere-se a especificar o estado desejado da infraestrutura e permitir que um mecanismo de orquestração execute as ações necessárias para alcançá-lo. No Azure, isso é feito com modelos do Azure Resource Manager. Camadas de abstração de terceiros, como o Terraform, também estão disponíveis para essa abordagem.

• A abordagem imperativa refere-se à execução de comandos específicos em uma ordem definida. Para o Azure, isso pode ser feito com a interface de linha de comando ou o PowerShell, mas os kits de desenvolvedor de software de linguagem de programação nativa, por exemplo, .NET, Python e Java, também estarão disponíveis se forem necessárias soluções integradas.

Nos modelos do Azure Resource Manager, o provisionamento principal está na seção de recursos e a configuração dos recursos individuais é definida em uma seção de propriedades . Para um Azure Data Lake Storage Gen2, a configuração tem a seguinte aparência:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.MachineLearningServices/workspaces/datastores",
            "name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
            "apiVersion": "2020-05-01-preview",
            "location": "[parameters('location')]",
            "properties": {
                "DataStoreType": "adls-gen2",
                "SkipValidation": "[parameters('skipValidation')]",
                "ClientId": "[parameters('clientId')]",
                "ClientSecret": "[parameters('clientSecret')]",
                "FileSystem": "[parameters('fileSystem')]",
                "AccountName": "[parameters('accountName')]",
                "TenantId": "[parameters('tenantId')]",
                "ResourceUrl": "[parameters('resourceUrl')]",
                "AuthorityUrl": "[parameters('authorityUrl')]"
            }
        }
    ]
}

Fluxos de trabalho e automação

As equipes devem usar pipelines de CI/CD em vários estágios para garantir que o código desenvolvido esteja sem erros e pronto para o ambiente de produção. Algumas práticas recomendadas são ter um ambiente de desenvolvimento, um ambiente de teste e um ambiente de produção. Esses estágios também devem ser refletidos no Azure usando serviços separados para cada ambiente.

A equipe de plataforma é responsável por fornecer e manter modelos de implantação para dimensionar rapidamente dentro de uma organização e simplificar as implantações para equipes que não estão familiarizadas com IaC. Esses modelos servem como uma linha de base para novos artefatos dentro do cenário e precisam ser mantidos ao longo do tempo para representar as práticas recomendadas e os padrões comuns dentro da empresa.

As implantações para testar e produzir só devem ser gerenciadas por meio de um pipeline de CI/CD e uma conexão de serviço com permissões elevadas para impor práticas recomendadas comuns (por exemplo, modelos do Azure Resource Manager).

Próximas etapas

Automação de plataforma