Repensando os Lançamentos de Suporte de Longo Prazo

Tradicionalmente, os lançamentos de sistemas operacionais com Suporte de Longo Prazo têm sido o baluarte das implantações corporativas. Este é o modelo usado por IBM, Oracle, Microsoft, Suse e Red Hat e tem sido o pensamento convencional em torno de sistemas operacionais desde o início das ofertas de suporte, há muitas décadas.

Tem sido comum no passado que tanto os lançamentos de sistemas operacionais de servidor quanto os de desktop sigam este modelo, mas no espaço Linux especificamente começamos a ver isso ser abalado, onde produtos menos formais ficaram livres para experimentar lançamentos mais rápidos, sem suporte ou simplesmente não estruturados. No espaço de produtos primário, openSuse, Fedora e Ubuntu todos forneceram ofertas de suporte de curto prazo ou ofertas de lançamento rápido. Em vez de ciclos de lançamento medidos em anos e ciclos de suporte se aproximando de uma década, eles encurtaram os ciclos de lançamento para meses e o suporte para apenas meses ou alguns anos, no máximo.

No espaço de desktop, obter novos recursos e aplicações mais cedo, em vez de focar principalmente na estabilidade como era comum em servidores, muitas vezes fazia sentido e trazia o benefício adicional de que novas tecnologias ou abordagens poderiam ser testadas em produtos de ciclo de lançamento mais rápido antes de serem integradas a produtos de servidor de suporte de longo prazo. O Fedora, por exemplo, é um campo de provas para tecnologias que, depois de se provarem, abrirão caminho para os lançamentos do Red Hat Enterprise Linux. Ao usar o Fedora, os usuários finais obtêm recursos mais cedo, aprendem sobre as tecnologias do RHEL mais cedo e a Red Hat consegue testar os produtos em larga escala antes de implantá-los em servidores críticos.

Com o tempo, a estabilidade dos lançamentos de curto prazo melhorou dramaticamente e, cada vez mais, esses sistemas são vistos como opções viáveis para sistemas de servidor. Esses sistemas recebem aprimoramentos, recursos e atualizações mais recentes mais cedo, o que muitas vezes é visto como benéfico.

Um grande benefício de qualquer sistema operacional é seu ecossistema de suporte, incluindo os pacotes e bibliotecas que são suportados e fornecidos como parte do sistema operacional base. Com os lançamentos de longo prazo, muitas vezes vemos pacotes críticos envelhecendo dramaticamente ao longo da vida do lançamento, o que pode causar problemas de desempenho, compatibilidade e até de segurança em casos extremos. Isso obviamente força os usuários de sistemas operacionais de lançamento de longo prazo a escolher entre continuar a conviver com as limitações dos componentes mais antigos ou integrar eles próprios novos componentes, o que muitas vezes quebra o valor fundamental do produto de lançamento de longo prazo.

Como o objetivo de um lançamento de longo prazo é ter estabilidade e testes de integração, substituir componentes dentro do produto para “contornar” as limitações de um LTS significa que esses componentes não estão sendo tratados de maneira LTS e que os testes de integração do fornecedor provavelmente não estão mais acontecendo, ou, se estiverem, não no mesmo grau. Na prática, o que acontece é que isso se torna um produto de lançamento de curto prazo construído por conta própria, mas com componentes centrais legados e menos supervisão.

Na realidade, na maioria dos aspectos, fazer isso é pior do que ir diretamente para um produto de lançamento de curto prazo. Usar um produto de lançamento de curto prazo ou rápido permite que o fornecedor mantenha os testes e a integração presumidos, apenas com um ciclo de lançamento e suporte mais rápido, de modo que o valor geral do conceito de lançamento de longo prazo seja mantido e com todos os componentes do sistema operacional, em vez de apenas alguns, sendo atualizados. Isso permite mais padronização, testes da indústria e conhecimento e integração compartilhados do que com um modelo LTS parcial.

Talvez tenha chegado a hora de repensar o valor do suporte de longo prazo para sistemas operacionais. Por tempo demais, ao que parece, o valor dessa abordagem foi simplesmente presumido e seguido, e certamente ela teve e tem méritos; mas o mundo dos sistemas operacionais mudou desde que essa abordagem foi introduzida pela primeira vez. A necessidade de atualizações aumentou, enquanto as taxas de mudança de coisas como kernels e bibliotecas diminuíram dramaticamente. Servidores mais poderosos elevaram a compatibilidade para um ponto mais alto da pilha e, em vez de o software ser escrito para um SO, ele é frequentemente escrito para uma versão específica de uma linguagem, de um tempo de execução ou de outra camada de abstração.

Ciclos de lançamento mais curtos significam que os sistemas recebem recursos, de cima a baixo, com mais frequência. As atualizações entre lançamentos “principais” são menores e menos impactantes. As mudanças decorrentes das atualizações são mais incrementais, proporcionando uma curva de aprendizado e adaptação mais orgânica. E, o mais importante, a necessidade de substituir componentes do sistema que são cuidadosamente testados e integrados por versões fornecidas por terceiros torna-se, efetivamente, algo inédito.

A estabilidade para os fornecedores de software continua sendo um valor dos lançamentos de longo prazo e fará com que haja necessidade do uso de lançamentos de longo prazo por muito tempo ainda. Mas, para o administrador de sistemas, o valor dessa abordagem parece estar diminuindo e, sinto pessoalmente, encontrou um ponto de inflexão nos últimos anos. Costumava parecer esperado e normal esperar dois ou três anos para que os pacotes fossem atualizados, mas hoje isso parece desnecessariamente trabalhoso. Parece cada vez mais comum que componentes de nível mais alto sejam construídos com a exigência de componentes subjacentes mais novos; uma expectativa de que os sistemas operacionais sejam mais atuais ou que partes do SO sejam atualizadas separadamente do restante.

Uma forte dependência de tecnologias de conteinerização pode reverter essa tendência de algumas maneiras, mas de maneiras que sempre reduzem o valor dos lançamentos de longo prazo ao mesmo tempo. A conteinerização reduz a necessidade de capacidades extensas no sistema operacional base, tornando mais fácil e eficaz atualizar com mais frequência para melhorar o suporte a kernel, sistema de arquivos, driver e contêiner, ao mesmo tempo em que deixa as bibliotecas e outras dependências nos contêineres, permitindo que aplicações que precisam de dependências de suporte de longo prazo sejam atendidas dessa forma e que aplicações que podem se beneficiar de componentes mais novos sejam tratadas dessa maneira.

É claro que a virtualização desempenhou um papel na redução do valor dos modelos de suporte de longo prazo ao tornar triviais a recuperação rápida e a duplicação de sistemas. A estabilidade que precisávamos que os lançamentos de suporte de longo prazo abordassem é parcialmente abordada pela camada de virtualização; a abstração de hardware melhora a estabilidade dos drivers de maneiras muito importantes. Na mesma linha, os modelos de suporte ao estilo devops também reduzem a necessidade de suporte de longo prazo e tornam os ecossistemas de servidor mais ágeis e flexíveis. As tendências nos paradigmas de administração de sistemas estão tendendo a favorecer sistemas operacionais mais modernos.

O tempo dirá se as tendências continuarão na direção em que estão seguindo. Para mim, este último ano foi revelador e me viu mover minhas próprias cargas de trabalho de uma década de apoio firme a produtos de suporte de prazo muito longo para produtos de lançamento rápido e devo dizer que estou muito feliz com a mudança.