Pontos Principais
-
Um fluxo de trabalho de IDE na nuvem oferece excelente conveniência em termos de ser acessível em qualquer dispositivo ou local.
-
Quando configurado corretamente, é indiscutivelmente mais seguro do que um fluxo de trabalho local, pois nenhum código ou ferramenta é armazenado localmente.
-
A velocidade de integração aumenta dez vezes, já que estações de trabalho completas podem ser automatizadas e ativadas com um único comando.
-
Os sistemas operacionais locais tornam-se irrelevantes, permitindo que os usuários usem o hardware e os sistemas operacionais mais adequados para seu fluxo de trabalho.
-
O desenvolvimento baseado em nuvem abre um mundo de flexibilidade, abstraindo seu ambiente de engenharia de todos os recursos e dependências locais.
Com o recente anúncio de produtos como Visual Studio Codespaces e GitHub Codespaces, fica claro que há uma demanda por fluxos de trabalho de engenharia baseados em nuvem. Embora trabalhar em uma máquina local possa parecer seguro e familiar, o fluxo de trabalho de um IDE na nuvem oferece aos usuários benefícios significativos, como potência e flexibilidade.
Por vários meses, tenho usado IDEs auto-hospedados na nuvem (saiba mais no projeto no GitHub, em inglês) em uma variedade de provedores de nuvem pública. Tenho feito isso por meio da versão de código aberto do Code Server do pessoal talentoso da Coder. Trabalhar na nuvem é agora meu fluxo de trabalho principal para meu trabalho pessoal e profissional como engenheiro de DevOps. Com uma instância acessível remotamente do VSCode e seu terminal integrado, tudo que eu preciso é um navegador da web para começar a trabalhar.
Este artigo cobre cinco motivos pelos quais um IDE na nuvem, seja auto-hospedado ou gerenciado, pode ser exatamente o que você ou sua empresa precisam para levar a produtividade para o próximo nível.
Um: Conveniência
Trabalhar na nuvem não é um conceito novo. Todos usamos produtos como Google Drive, Dropbox, iCloud, e Office 365 na última década ou mais. A conveniência de armazenar seu trabalho na nuvem e poder voltar e continuar de onde você parou é uma virada de jogo.
Com IDEs na nuvem entrando em cena, nós, engenheiros, agora podemos desfrutar da mesma conveniência e produtividade. Não preciso mais ficar preso ao hardware local intercalando chaves, fazendo malabarismos com diferentes versões de ferramentas e linguagens, e tentando alcançar a compatibilidade ideal entre minhas máquinas Mac e Linux.
Com meu IDE remoto na nuvem, posso trabalhar de qualquer dispositivo e local, desde que tenha uma conexão com a Internet e um navegador. Embora uma conexão de Internet necessária possa soar como uma desvantagem, no mundo atual de equipes distribuídas, programação em pares, e fluxos de trabalho de CI / CD, uma conexão de Internet geralmente já é uma obrigação na maioria dos cenários.
Descarregar meu fluxo de trabalho em uma instância remota também significa que a carga associada não é mais um fardo para minha máquina local. Reduzir a carga da CPU, memória, e disco rígido melhora significativamente o desempenho, temperatura, e a vida útil da bateria do meu laptop.
Trabalhar no navegador também oferece outros benefícios convenientes. O principal é um ambiente de trabalho isolado. Por exemplo, eu uso o Firefox como navegador pessoal e o Chrome como navegador de trabalho. Agora posso conter todo o meu ambiente de trabalho em um único navegador. Isso fornece um nível excepcional de conveniência, mas também toca no meu segundo ponto, a segurança.
Dois: Seguranca
Conforme mencionado anteriormente, trabalhar na nuvem significa que meu ambiente de trabalho e seus recursos relacionados permanecem isolados em um perfil de navegador. Conter meu trabalho dessa forma significa que nenhuma ferramenta, chave, ou código está em meu sistema de arquivos local. Tenho certeza de que você já a orientação - "você deve criptografar seu drive para um caso de roubo". Embora eu recomende e, de fato criptografe todos os meus discos, meu hardware local agora se torna substancialmente menos relevante para um possível invasor
Executar minha carga de trabalho em uma rede remota também significa que minha rede local terá pouco valor se comprometida. Todas as chaves e permissões para executar cargas de trabalho são bloqueadas e autenticadas de minha instância remota, não de minha rede local e terminais de computador.
A maneira como a pilha da rede é configurada e bloqueada é uma parte vital para manter a segurança ideal durante o trabalho na nuvem. Existem algumas maneiras diferentes de fazer isso.
A maneira mais simples de acessar com segurança um IDE na nuvem, sem a necessidade de configuração extra, seria encaminhar a porta local da instância IDE por meio de um túnel SSH. Ao fazer isso, ele não é exposto à Internet pública. Agora todo o trabalho está sendo realizado por meio de um túnel criptografado. Embora seja simples e seguro, isso limita a necessidade das chaves SSH corretas e de um cliente SSH.
Conforme mencionado na parte um, um benefício principal de um IDE na nuvem é a capacidade de acessá-lo de qualquer dispositivo. Para conseguir isso, preciso expor um servidor da web por meio da Internet pública.
A maneira mais fácil de alcançar isso é com algo como o Caddy. Um servidor web simples com HTTPS automático via Let's Encrypt. Em questão de minutos, posso ter um IDE de nuvem sendo servido com segurança por TLS.
Eu, no entanto, escolho hospedar minhas instâncias remotas em redes privadas. O tráfego é então roteado para a porta da minha instância IDE por meio de um balanceador de carga criptografado por TLS na borda. Isso mantém a própria instância fora da Internet.
Quer escolha rotear diretamente para a instância ou por meio de um balanceador de carga, agora tenho um IDE de nuvem protegido por senha, rodando sobre um TLS.
A autenticação básica ainda é um pouco simplista para os padrões de hoje. Para aumentar a segurança a um nível aceitável, eu recomendaria a implementação do MFA. A melhor maneira de fazer isso é usando um proxy reverso compatível, como Cloudflare ou OAuth2 Proxy.
Agora eu tenho uma estação de trabalho IDE em nuvem acessível por navegador com proteção TLS, senha, e MFA.
A implementação desses procedimentos de segurança só se aplica ao auto-hospedar o IDE na nuvem, é claro. Serviços gerenciados, como o Visual Studio Codespaces, geralmente fornecem e cuidam das medidas de segurança mencionadas acima com excelente garantia de qualidade.
Outro benefício de segurança notável é a capacidade de ter diferentes instâncias para diferentes ambientes de trabalho. Tendo essas instâncias separadas significa que todas as medidas de segurança associadas para seus respectivos ambientes de trabalho são isoladas. Já se foi o tempo em que havia vários conjuntos de chaves e direitos de acesso em uma única máquina, criando um raio de explosão que poderia destruir vários sistemas e redes se comprometidos.
Um último ponto sobre segurança, independentemente de você estar usando um serviço auto-hospedado ou gerenciado, certifique-se de que a plataforma subjacente atenda à conformidade de segurança. Certificações como SOC 1 Tipo II, SOC 2 Tipo II e, em particular, ISO / IEC 27001: 2013 são fundamentais para garantia de segurança. Igualmente importante, porém, é que o provedor de nuvem pública ou serviço gerenciado escolhido esteja na lista de fornecedores confiáveis de sua empresa. Você não vai querer acordar com uma mensagem de alerta em sua caixa de entrada vinda de um arquiteto de segurança!
Três: Velocidade
Uma das principais limitações na entrega de valor quando se começa em uma nova empresa é o processo de integração. "Que tipo de acesso eu preciso? Quais ferramentas, linguagens, e versões específicas minha função requer? Essas versões estão atualizadas com o que meus colegas estão usando atualmente?"
Conseguir agregar valor à empresa pode levar dias ou semanas. Mesmo assim, o conjunto de ferramentas e o controle de versão ainda estão sujeitos a alterações entre os colaboradores individuais.
É aqui que a velocidade de entrega e a produtividade entram em jogo com os fluxos de trabalho na nuvem. Com ferramentas como Terraform e Packer, todo o conjunto, desde a plataforma de infraestrutura central até as ferramentas e os requisitos de acesso na própria instância, pode ser padronizado e automatizado.
Imagine um cenário no qual há três equipes diferentes para um produto específico: uma equipe de operações, uma de back-end, e uma de front-end. Cada equipe tem seus requisitos para ferramentas, linguagens, controle de versão, e acesso para suas respectivas camadas do produto.
Em um fluxo de trabalho na nuvem, podemos ter três imagens de estação de trabalho prontas para uso na prateleira para cada equipe. Tratamos essas imagens como produtos, com proprietários e mantenedores.
Quando um novo membro se junta a equipe, digamos, a equipe de back-end, eles agora executam um único comando para ativar uma nova instância de IDE na nuvem a partir da imagem da "equipe de back-end". Em questão de minutos, eles estão entregando valor com uma instância VSCode totalmente funcional em execução em um VPS seguro carregado com as ferramentas, versões, e acesso corretos de que precisam.
Do ponto de vista da equipe, ter uma imagem centralizada da qual todas as estações de trabalho na nuvem operam, diminui drasticamente o trabalho que não agrega valor. Ele faz isso removendo a variação entre as ferramentas e o controle de versão nas estações de trabalho. Quando uma equipe decide que é hora de atualizar para uma nova versão do Go, por exemplo, os mantenedores da imagem dessa equipe atualizam a versão e todas as instâncias associadas são atualizadas a partir do lançamento da nova imagem. Agora temos um fluxo de trabalho opinativo em que todos estão trabalhando com as mesmas ferramentas e versões.
Também há um aumento drástico em termos de velocidade de entrega técnica. Em vez de trabalhar em uma conexão de Internet doméstica ou no escritório, a carga de trabalho é executada em um data center de alta velocidade. Aquela imagem do Docker que costumava levar dois minutos para baixar, agora leva 15 segundos.
A velocidade necessária para trabalhar na nuvem não é alta. Trabalhei com uma conexão de 10mbps em Sydney, Austrália, em um IDE em nuvem alojado em um data center Digital Ocean em Cingapura. Ele reagiu como se estivesse sendo executado como um aplicativo nativo na minha máquina local.
Quatro: Sistemas operacionais
Um ponto de discórdia há algum tempo é o fato de que a maior parte da indústria de tecnologia fornece e trabalha em Macs, enquanto os sistemas que construímos geralmente rodam em Linux. Eu entendo o apelo do ecossistema da Apple: um conjunto padronizado de hardware e software com excelente suporte. No entanto, isso cria um dilema de engenharia.
Embora alguns possam argumentar que BSD e GNU não são tão diferentes, a verdade é que eles são diferentes o suficiente. Para testar com precisão a arquitetura Linux do meu Mac, preciso executar VMs, contêineres, ou builds de CI / CD.
Mesmo ao executar contêineres no Mac, ainda estou tecnicamente mastigando recursos extras ao executar uma VM Linux, de forma subjacente, para usar o Docker. Isso ocorre porque o daemon do Docker interage diretamente com o kernel do Linux para criar seus namespaces e grupos de controle. O que estou aludindo aqui é que o trabalho de engenharia geralmente faz mais sentido técnico ser conduzido em uma base Linux.
Com um IDE de fluxo de trabalho na nuvem, meu sistema operacional local se torna irrelevante. Ainda posso usar meu Mac junto com todos seus excelentes aplicativos: Mail, Calendar, Slack e, claro, Spotify, e ao mesmo tempo, minha estação de trabalho de engenharia / IDE é um VPS baseado em Linux de alta potência executado em uma guia do navegador. Para aquele modo zen nativo real, gosto de dar ao IDE seu próprio espaço de trabalho e usar a tela inteira! Isso também se aplica ao Windows… sem julgamentos.
Cinco: Flexibilidade
Meu último ponto, e também para recapitular, é a flexibilidade. Em última análise, o que os fluxos de trabalho de IDE em nuvem oferecem são flexibilidade e liberdade.
Agora posso trabalhar em um Mac, Windows, Linux, iOS, Android; Não importa. As ferramentas de que preciso para realizar meu trabalho estão agora em uma instância remota e acessíveis de qualquer local ou dispositivo no mundo. Sim, testei isso no meu Google Pixel 4!
As estações de trabalho auto-hospedadas inicialmente envolvem um pouco mais de trabalho braçal para serem automatizadas e ativadas, mas, como resultado, tenho controle refinado sobre exatamente o que preciso. Posso obter elasticidade vertical com base na carga de recursos. Eu posso montar meus diretórios pessoais para separar unidades imutáveis, permitindo-me expandir, recriar, ou alterar minha instância central. Posso escolher executar meu IDE de nuvem como um contêiner ou daemon nativo. Além disso, posso mudar para diferentes provedores de nuvem pública com facilidade.
Se você só precisa de um IDE remoto para escrever e testar o código, os diversos serviços gerenciados que existem são uma maneira fácil de trabalhar remotamente e com segurança. Eles têm os benefícios de liberdade e flexibilidade, sem a sobrecarga extra.
Quer você opte por seguir o caminho do serviço auto-hospedado ou gerenciado, há um mundo totalmente novo de poder e flexibilidade que um fluxo de trabalho na nuvem pode fornecer.
Passar dias configurando novas máquinas e fazendo backup de discos rígidos é coisa do passado. Vivemos em um mundo onde, com o pressionar de um botão, posso transmitir um filme em 4K de um catálogo entre milhares, em um data center a centenas de quilômetros de distância. Com uma tecnologia como esta, era apenas uma questão de tempo antes de começarmos a trabalhar/investir na nuvem, e não apenas trabalhar/hospedar na nuvem. Fico feliz em dizer que esse dia está aqui, e é impressionante!
Sobre o autor
Ben Vilnis cresceu em meio a computadores desde jovem, quando seu pai abriu uma loja de computadores nos anos 90, que se tornou um provedor de serviços de Internet e empresa de hospedagem no início dos anos 2000. Ele rapidamente descobriu uma afinidade com a tecnologia da computação e começou a montar computadores e criar sites durante o ensino médio. Em seu último ano escolar, ele descobriu sua paixão por Linux, administração de sistemas e redes. Avançando vários anos, Ben agora trabalha na Envato como engenheiro de DevOps e tem uma paixão por infraestrutura descartável, Lean, e plataforma-como-produto. Ben também é músico e cantor / compositor, e atua como bombeiro voluntário no Corpo de Bombeiros Rural de New South Wales.