Buildpacks ajudam a aliviar a carga dos desenvolvedores, pegando o código-fonte e transformando-o em aplicativos totalmente funcionais.
Para saber mais sobre esta tecnologia, entrevistamos Ram Iyengar, evangelista-chefe da Cloud Foundry Basis, sobre o assunto mais episódio recente do nosso podcast, What the Dev?
Aqui está uma versão editada e resumida dessa conversa:
Como os buildpacks – e os Paketo Buildpacks em explicit – ajudam os desenvolvedores a implantar aplicativos nativos da nuvem?
Acho que os buildpacks têm sido muito importantes para fazer com que muitos aplicativos sejam enviados para produção e colocados em contêineres sem ter que lidar com muita sobrecarga que geralmente acompanha o processo de conteinerização. O que posso dizer que já não tenhamos dito no webinário e no artigo e coisas assim? Bem, há um ângulo comunitário nisso. Buildpacks está um pouco caminhando para a graduação dentro do CNCF, e esperamos que ele se forme nos próximos seis a 12 meses. Se houver alguma demonstração de apoio que vocês possam fazer como comunidade, agradeço muito as pessoas que dão uma estrela, abrem questões importantes, experimentam o projeto e veem como vocês podem consumi-lo, e nos dão suggestions sobre como o projeto pode ser melhorou.
Uma coisa que eu gostaria de abordar um pouco é o Korifi, que é sua plataforma para criar e implantar aplicativos Kubernetes. Você pode falar um pouco sobre o Korifi e como ele se relaciona com os buildpacks?
Com certeza, uma das principais áreas onde vemos muitos buildpacks sendo consumidos é quando as pessoas estão começando a trabalhar na construção de plataformas no Kubernetes. Agora, qualquer tipo de conversa que você vê sobre Kubernetes hoje em dia, seja na KubeCon ou em um dos outros eventos, é extremamente complexo, e tem sido dito tantas vezes, há memes, há artigos de opinião, há tudo tipos de subcultura da Web sobre o quão complexo o Kubernetes pode ser.
A consequência dessa complexidade é que algumas equipes e empresas começaram a criar uma plataforma onde dizem que querem fazer uso do Kubernetes? Bem, instale outro substrato sobre o Kubernetes e abstraia muitos dos componentes internos do Kubernetes da interação com seus desenvolvedores. Isso ressoa perfeitamente com o que as mensagens do Cloud Foundry têm sido todos esses anos. As pessoas desejam uma experiência de primeira classe, de autoatendimento e multilocatário em VMs, e desejam o mesmo tipo de experiência no Kubernetes hoje por motivos um pouco diferentes, mas o objetivo last é que os desenvolvedores precisem ser capazes de chegar a isso velocidade em que eles são mais ideais. Eles precisam ser capazes de construir e implantar rapidamente e continuar colocando aplicativos em produção enquanto reduzem muitas outras áreas importantes, como, como escalamos isso e como mantemos o equilíbrio de carga nisso? Como configuramos a rede e a entrada?
Todas essas coisas deveriam cair em uma plataforma. E então Korifi é o que surgiu da comunidade para realmente implementar esse tipo de comportamento, e os buildpacks se encaixam perfeitamente neste mundo. Então, ao usar buildpacks – e acho que Korifi é o maior consumidor de buildpacks – eles realmente construíram uma experiência para poder implantar aplicativos no Kubernetes, independentemente da linguagem e da família, e aproveitando todos esses recursos de buildpacks .
Estou ouvindo muita conversa sobre a Cloud Foundry Basis em geral, que ela é meio antiga e talvez o Kubernetes esteja tentando substituir o que vocês estão fazendo. Então, como você responderia a isso? E o que a Cloud Foundry Basis oferece no mundo Kubernetes?
É uma resposta em duas partes ou em duas partes que eu tenho. Por um lado, existe o lado tecnológico das coisas. Por outro lado, há uma comunidade e um ângulo humano nas coisas. Os engenheiros querem novas ferramentas e coisas novas e novas infraestruturas e novos tipos e formas de trabalhar. E então o que aconteceu na comunidade tecnológica mais ampla é que uma tecnologia suficientemente adequada como o Cloud Foundry de repente se viu relegada a tecnologia legada e à maneira antiga de fazer as coisas e, em alguns casos, não é suficientemente moderna. Esse é o ângulo humano disso. Então, quando as pessoas começaram a olhar para o Kubernetes, quando toda a comunidade de desenvolvimento de software program aprendeu sobre o Kubernetes, o que eles fizeram foi de alguma forma pegar essa nova tendência, e eles queriam pegar o trem do hype, por assim dizer. E o Kubernetes começou a ocupar muito espaço na mente e agora, como bem diz o Gartner, você ultrapassou aquela fase de expectativas elevadas. E agora você está entrando na produtividade, e toda a comunidade anseia por uma maneira de consumir Kubernetes sem a complexidade. E eles querem uma maneira muito conveniente de implantar aplicativos no Kubernetes sem se preocupar com rede, balanceamento de carga, escalares automáticos e todas essas outras coisas periféricas que você precisa anexar a um aplicativo.
Acho que não se trata realmente de desenvolvedores apenas quererem coisas novas. Acho que eles querem ferramentas melhores e formas mais eficientes de fazer o seu trabalho, o que os deixa livres para fazer mais inovações que eles gostam e não ficarem atolados com todas essas questões de infraestrutura e coisas que você sabe que agora podem ser resolvidas de. Então, acho que o que você está dizendo é muito importante em termos de posicionar o Cloud Foundry como útil e útil para os desenvolvedores em termos de ganho de eficiência e capacidade de trabalhar da maneira que desejam.
Bem, sim, eu concordo em princípio, e é por isso que estou dizendo que Cloud Foundry e alguns outros como Heroku, todos eles aperfeiçoaram essa experiência de como deveria ser o fluxo de trabalho de um desenvolvedor. Agora, os desenvolvedores ficam felizes em adotar novas maneiras de trabalhar, mas o problema é que, quando você está no caminho para obter esse tipo de eficiência e velocidade, muitas vezes você cria, sem querer, muitos fluxos de trabalho opinativos ao seu redor. Portanto, todos os desenvolvedores terão uma maneira muito específica de criar implantações e criar esses artefatos imutáveis, e construirão para si um forte de onde gostariam de ser reis do castelo, senhor do mansão, mas está realmente atacando muito a imagem psychological e quaisquer apreensões que surjam ao se desviar dessa imagem psychological. E no momento, o Kubernetes parece oferecer uma das melhores maneiras de construir, empacotar e implantar um aplicativo, visto que ele pode realizar muitas coisas diferentes.
Agora, se você fizer uma comparação ponto a ponto entre o que o Cloud Foundry period capaz, digamos, em 2017 e o que o Kubernetes é capaz agora, será quase o mesmo. Então, em termos de paridade de recursos, estamos agora em um ponto, e pode ser muito controverso dizer isso em um podcast público, mas em termos de paridade de recursos, o Cloud Foundry sempre ofereceu o tipo de recursos que estão disponíveis na comunidade Kubernetes agora mesmo.
Agora, é claro, o Kubernetes imagina que os aplicativos sejam construídos e implantados de uma maneira um pouco diferente, mas em termos de colocar tudo em contêineres e enviá-los para um orquestrador de contêineres e fornecer o tipo de confiabilidade que os aplicativos precisam, e permitir sidecars e serviços e multilocação.
Acredito firmemente que a oferta do Cloud Foundry period bastante atraente, mesmo quatro ou cinco anos atrás, enquanto o Kubernetes ainda está navegando em águas bastante agitadas em termos de multilocação, serviços e coisas assim. Mas ei, como comunidade, eles estão fazendo inovações maravilhosas. E sim, concordo com você quando digo que os engenheiros estão sempre buscando a melhor maneira de, você sabe, obter essa eficiência.