Executando verificação de segurança...
5

Por que um Dev Fullstack usando Windows pode ser uma red-flag?

Após décadas longe do Windows, minha nova experiência em uma startup me deixou intrigado: por que dois desenvolvedores estão usando Windows?

Nem C#, nem nenhuma outra tecnologia da Microsoft faz parte direta da Stack e agora começa o problema - geralmente sempre homologo um ambiente de desenvolvimento e staging muito próximo do que roda no Kubernetes em produção. Mas agora, no Windows um dev que coloca seu ambiente de trabalho no C:/ outro no D:/ e os hostPath agora precisariam de:

  volumes:
  - name: meu-volume
    hostPath:
      path: C:\host\path\no\windows

ou

  volumes:
  - name: meu-volume
    hostPath:
      path: D:\host\path\no\windows

E para resolver isso no YAML do ambiente de desenvolvimento agora eles dependeriam de variáveis de ambiente. Todos os scripts de deployment precisariam também ser revisados/refatorados.

A pergunta honesta é: se você fosse tech lead e encontrase um time formado, colocaria Mac ou Linux de forma impositiva? Se não, qual é a vantagem produtiva em 2024 de se utilizar Windows? Essa também uma pergunta honesta, já que faz cerca de 20 anos que não utilizo Windows. Estou perdendo algo novo?

EDIT

Percebi que algumas pessoas aqui disseram que o projeto está organizado de forma errada, pois os volumes deveriam ser relativos e não absoluto, mas isso não é possível no Kubernetes https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/.

E o porquê? Porque em um cluster, como ele precisa saber explicitamnte aonde irá montar os arquivos. Imagine como ele descobriaria aonde montar se Windows-1 ele tenha o app em C:\app.... e no Windows-2 D:\app

Rodar Kuberntes stand-alone/single é a excessão não é a regra, roda-se somente em ambiente de desenvolvimento.

O WSL injeta os pontos de montagem em /mnt/host, então além dos persistente volumes, possívelmente os deployments também precisarão ser remapeados.

Em cerca de 20 anos eis as novidades:

  • Git bash (Um port do bash disponível, então nem todos os scripts .sh preciseram ser refatorados, sim Windows agora tem um bash)
  • WSL (Que injeta os arquivos montados em /mnt/host e /run/desktop?)
  • PowerShell (O cmd com esteiróides)
Carregando publicação patrocinada...
13

Pra mim pode ser um "redflag" se ele depender do Windows pra programar.

Sendo bem sincero nunca perguntei se um desenvolvedor utilizava Windows ou Linux durante uma entrevista. Não tem a ver com o SO. Se você decide por um desenvolvedor que ele deve usar X ferramenta ao invés de Y, há dois aspectos principais:

  • Curva de aprendizado
  • Disposição

O redflag está aí. Eu, como líder técnico, sempre me coloco à disposição para auxiliar com a curva de aprendizado. Mas se ele não está disposto a enfrentar esta curva, ele não vai ser produtivo, independente do SO.

Na minha equipe todos trabalhamos primariamente com Python. Não há qualquer imposição direta de ferramentas como IDE e sistema operacional.

Mas a questão é que temos uma diretriz sobre nosso estilo de código (famosa PEP-8). E para reforçar a diretriz, há uma verificação que faz parte da nossa pipeline de CI. Se o desenvolvedor não conseguir garantir um código dentro destas diretrizes, a pipeline irá falhar e o PR não prosseguirá. Não me importa muito se ele prefere PyCharm ou VSCode, Windows ou Linux, etc.

Mas se a maioria usa VSCode, e alguém decide usar o PyCharm, ele assume a responsabilidade de descobrir sozinho como configurar corretamente para que o resultado seja consistente, e acaba tirando menos proveito das descobertas dos demais. Isso naturalmente encoraja a uma padronização.

Obviamente esta liberdade de escolha depende da maleabilidade que o sistema possui em se adequar ao sistema de arquivos da máquina. Eu trabalhei isso desde quando decidimos reescrever o sistema. É mais fácil quando é pensado pra ser assim desde o zero.

Além do que você já pontuou sobre o caminho do volume, como a aplicação resolve o caminho das subpastas? Se for através de uma concatenação de string simples, pode dar ruim pois pode resultar em algo do tipo D:\\host\\path\\no\\windows/resto/do/path, ou você pode tentar fazer a separação do caminho (famoso split ou slice) manualmente levando em conta o separador incorreto. Dependendo do caso gera erros. Isso significaria ter de refatorar todo o código para usar um método programático, através de bibliotecas que lidam com o sistema de arquivo, pra formar um caminho adequado para o sistema que estiver executando dinamicamente.

Eu passei a dar mais atenção a este tipo de "detalhe" após ler o Twelve-factor App. Recomendo, e é bem curto.

Mas aí refatorar nunca é uma decisão simples, e nem sempre o melhor caminho. Leve em consideração tempo e recursos disponíveis e envolvidos na alteração, os benefícios reais que esta transição irá trazer, etc, porque como líder você deve observar antes de tudo a integridade do projeto. Não dá pra deslocar seu roadmap em 1 mês simplesmente porque 2 desenvolvedores usam Windows e se recusam a usar Linux. Diga isso em uma reunião de produto (quando não de diretoria, em último caso) e provavelmente perderá pontos com pessoas importantes/influentes.

9

Eu costumava colocar Linux de forma impositiva. Porém com o avanço do Docker e WSL, todos meus projetos foram pra dentro do Docker inclusive em dev, então, qual o sentido de impor Linux?

Porém, eu acho que todo dev DEVE saber usar linux entre básico e intermediário, para entender o que acontece dentro do docker, se não, a demanda acaba indo para outra pessoa que saiba.

5

qual é a vantagem produtiva em 2024 de se utilizar Windows

Tenho um dock conectado no notebook que apenas por uma única porta USB-C estão conectados:

  • Terceiro Monitor
  • Cabo Ethernet
  • Mouse, teclado
  • Mesa de som com mic, fone, caixa de som
  • stream deck conectado na Luz (também da elgato)
  • webcam

Adivinha o motivo? Não existem driver para linux dos dispositivos:

  • Dock
  • Mesa de som
  • Stream deck e Luz
  • Software de corzinha pro teclado e mouse

WSL

Hoje o WSL é a engine padrão do docker.

então se na sua configuração está

path: D:\host\path\no\windows

é porque simplesmente o projeto está instalado no caminho errado. não é problema de compatibilidade, é de usuário.

Além disso porque esse caminho não está dinâmico?

path: ./storage:/app

Docker suporta isso.

Porque usar linux

Se tenho um ambiente Windows que tem compatibilidade com todos os driver e uma máquina virtual TOTALMENTE integrada com o sistema inteiramente em linux?

SIM! Na WSL (Windows 11) funciona até plicativos graficos. Ja instalei o firefox na wsl e executei rodando na maquina virtual linux como se fosse uma aplicação windows.

colocaria Mac de forma impositiva

Você vai pagar 30k para ter um notebook com desempenho semelhante ao meu que paguei 8k? Se sim, sinta-se a vontade

Se não ajuste as configurações do projeto e ensine seus colaboradores a configurar o projeeto no local certo.

Docker resolve o problema de diferentes SOs / Hardwares.

Ele roda em tudo de forma igual. Se configrar certinho sua aplicação não saberá em qual sistema está, e isso não importa.

Tenho AQUI um docker compose que usei no WSL com todos os pontos que falei nesse post

1
1

O WSL injeta os pontos de montagem em /mnt/host

E porque não guardar os arquivos direto nos volumes da WSL? porque no windows?

WSL diz explicitamente que a performance acessando arquivos do outro sistema é afetada pois tem que passar tudo por REDE.

Porque não criar uma pasta exemplo /app e guardar tudo lá? ferramentas windows acessam. VSCode roda com backend direto no linux e precisa fazer essa manobra toda

WSL é uma VM com SO linux completo integrado ao windows. Ele funciona da mesma forma que um SO linux. Nunca tive uma limitação que me impediria de usar

1

Você vai pagar 30k para ter um notebook com desempenho semelhante ao meu que paguei 8k? Se sim, sinta-se a vontade

Nossa eu tenho o mesmo pensamento, mas aí é de gosto né.

Prefiro meu notebook bem mais barato, e que não é dependente do ecossistema Apple. E pro meu caso, ainda serve para passar nervoso no lolzinho ou outro jogo qualquer kkkk

4

O deploy já não devia usar variáveis de ambiente justamente pra não ter problemas com ambientes diferentes de desenvolvimento?

Ao menos sempre peguei projetos preocupados com isso, mas não conheço os possíveis impedimentos pra isso no seu caso.

3

Antigamente isso fazia mais sentido, mas hoje com docker e WSL é muito mais tranquilo. No momento estou com um note ubuntu meio antigo e acabo trabalhando mais no meu PCzao que montei pra jogar hahaha

1

Na verdade hoje em dia com o Docker e o WSL, pra quem precisa subir um aplicativo é só usar eles.

O Windows tem bem mais compatibilidade com as IDEs de programação, e elas rodam melhor no Windows e tem menos bugs que as versões do Linux.

O desenvolvedor só tem que:

  • Usar as IDEs pra programar, elas rodam melhor no Windows.
  • Se for pra debugar, o Linux é indiferente pois os debugs são feitos pelos códigos e pelas IDEs.
  • Pra testar a aplicação, é só rodar um container do Docker.

Não faz sentido essa afirmação de que se um dev. não usa Linux ele é um red flag.

1
1

sobre o ambiente, todos rodam o ambiente de desenvolvimento com kubernetes? e porquê?

o ideal seria utilizar um dockerfile para desenvolvimento + docker-compose para orquestrar caso seja necessário subir mais de um container e os apontamentos dos volumes serem feitos de forma relativa e não absoluta isso garante compatibilidade independente do S.O.

a Questão da redflag por optar por um S.O acredito que isso não diz muita coisa, no fim cada desenvolvedor tem que que utilizar as ferramentas que vão lhe propor maior produtividade e maior compatibilidade com a stack e as ferramentas da empresa, e se ele preferir usar windows e nao comprometer os critérios mencionados anteriormente que o faça.

2

O porquê do Kubernetes em ambiente de desenvolvimento ao invés do Docker?

Porque que se eu tenho uma aplicação que roda em Kubernetes, com certeza ela vai rodar no Docker, já no caso inverso não se aplica automaticamente.

No Docker você pode, por exemplo, usar dependencias de serviços - no Kubernetes você precisa de um teste de Readiness e Liveness, geralmente um endpoint /healthcheck. É simples de resolver? Sim, mas precisa ser feito e testado, constantemente.

Se voce precisar testar um ambiente com N replicas pra certificar que um serviço está tolerante a falhas, também não consegue. Então tchau teste de resilência e up/downscaling, 100% da responsabilidade fica na mao do DevOps e SRE que vão receber deploys quebrados. Como você saberia se aplicação escala? Docker-compose nao possui HPA, então não saberia, só quando quebrasse no pipeline. Por experiência nos ultimos projetos, quanto mais distante é a realidade do ambiente de produção ao que os devs trabalham = mais bugs.

Ainda na esfera dos testes, os devs não conseguiriam testar de maneira facil atualização com 0 downtime.

O Kubernetes só coloca em produção um novo POD que passar pelo teste de Liveness e Readiness, caso contrario o POD antigo continua operacional. E isso eleva o nível do time para construir processos de migrations/deploys melhores, porque a nova versão só entra em produção depois que o serviço está plenamente operacional.

Pra uma aplicação que não seja de missão crítica até concordo com o uso do docker-compose, no nosso caso não é uma opção, aonde um minuto de downtime é um prejuizo na escala de milhares reais ou talvez dezenas de milhares.

1

mas ai no caso, os devs tem que fazer as alterações de código direto no ambiente de desenvolvimento?

a ideia de utilizar o docker-compose é apenas localmente na própria máquina que o desenvolvedor utiliza que pelo que você descreveu é a situação atual e é o que justificaria a necessidade do apontamento para o caminho absoluto em c:/ e d:/.

1

Não considero o uso do Windows uma preocupação ("red flag").

Pessoalmente, não acho que Kubernetes seja a escolha ideal em um ambiente de desenvolvimento. Prefiro a simplicidade do Docker Compose ou mesmo o uso direto de um Dockerfile para necessidades imediatas.

Informações confidenciais deveriam ser configuradas como variáveis de ambiente ou através de outro método mais eficaz de gerenciamento. Isso facilita a colaboração em equipes diversificadas, onde cada desenvolvedor pode escolher entre Linux, Windows ou Mac. A flexibilidade para trabalhar no sistema operacional da preferência de cada um, a meu ver, é fundamental. Além disso, diferenças de ambiente, tabulação e código podem ser gerenciadas pelo uso de um arquivo .editorconfig.

No que se refere ao C#, é sabemos que é possível programar usando apenas o VSCode. Sim, é viável, mas o Visual Studio é imensamente superior em termos de produtividade, e ele só funciona para Windows, e tem uma versão "OK" para MAC

Atualmente, meu ambiente de desenvolvimento é totalmente baseado no Windows, com integração do WSL e Docker. Algumas tarefas são executadas dentro do WSL e outras diretamente no Windows, variando conforme a necessidade de cada projeto.

A única dificuldade que encontrei até agora foi ao experimentar recursos do Docker para o projeto "Rinha de Backend". Notei que o modo de rede 'host' não é suportado pelo Windows, mesmo utilizando o WSL. Para contornar isso, recorri ao uso de Linux em dual boot.

Exceto isso, nunca encontrei grandes obstáculos utilizando o Windows para desenvolvimento.

2

É um ambiente de missão crítica. Docker-compose não é uma opção viável para testes.

Além disso não estou me referindo a devs de frontend, esses inclusive se quiserem trabalhar no React direto, sem docker, sem problemas. Como um dev fullstack conseguiria testar se a aplicação está pronta para suportar upscaling e downscaling? Em serviços stateless OK, mas nos demais casos precisa-se sim fazer testes no HPA.

O docker não possui um equivalente a esse último e isso não dev ser responsabilidade esclusiva da equipe de DevOps/SRE resolver, muitas vezes o código precisa ser refatorado para evitar dataloss no downscaling.