Kubernetes em 5: Joe Beda, Brendan Burns e Craig McLuckie em seu passado, futuro e o verdadeiro valor do código aberto
Em um momento em que o software corporativo de código aberto está em uma encruzilhada, estragado pelos debates sobre licenciamento e monetização, o Kubernetes é um sucesso absoluto.
Lançado pela primeira vez por três engenheiros do Google há cinco anos, o Kubernetes tem sido um dos poucos projetos de código aberto a ter um impacto descomunal na computação distribuída com um mínimo de drama entre usuários, mantenedores e fornecedores . Há muitas pessoas que argumentam que o hype em torno de Kubernetes correu bem antes do uso no mundo real, mas não há dúvida de que as empresas que modernizam seus aplicativos em torno de contêineres estão prestando muita atenção ao potencial do Kubernetes de servir como ponte entre vários provedores de nuvem.
Durante a celebração do quinto aniversário na semana passada, ficamos entusiasmados em sediar uma discussão entre os três co-criadores do Kubernetes - Joe Beda e Craig McLuckie da VMware, e Brendan Burns da Microsoft - no GeekWire 2019. Cloud Summit. Falamos sobre a história do projeto, o estado atual do software de código aberto e os problemas não resolvidos que estão atrasando o futuro da computação em nuvem.
Uma transcrição levemente editada dessa discussão segue abaixo.
GeekWire Cloud e Enterprise Editor Tom Krazit: Então, eu acho que a maioria das pessoas nesta sala sabe que vocês , mas se você pudesse se apresentar, dizer "Oi" e me dizer quem é sua pessoa favorita na história da ciência da computação, e por quê. Joe Beda: Eu sou Joe Beda e meu favorito pessoa em ciência da computação ... eu diria Ada Lovelace porque ela foi a primeira programadora e foi durona e super legal.
Brendan Burns: Eu sou Brendan. Eu iria com ... Eu não sei se tenho um único favorito. Mas eu vou com Steve Wozniak, um dos co-fundadores da Apple e o desconhecido Beatle da Apple. Craig McLuckie: Ei, eu sou Craig. Eu vou com Jack Tramiel, o cara que criou o Commodore 64. Eu teria tido a mais solitária e deprimente adolescência, mas para o Commodore 64. Então, obrigada Jack.
Tom Krazit: Uma das razões pelas quais vocês estão aqui, e as festividades da semana, estão ao redor do Kubernetes, este projeto que está seguindo você por alguns anos. Olhando para trás, o progresso que você fez até agora e onde estamos hoje com o Kubernetes ... vamos começar por aí. Onde estamos hoje? Como o projeto evoluiu? O que resta a ser feito? E do que você mais se orgulha ao longo do período de cinco anos? Brendan Burns: Sinto que atingimos esse ponto de inflexão quando começamos a conversar sobre coisas como nossa política de back-end. Eu estava tipo, "Oh, acho que estamos fazendo agora". Não estava no roteiro inicial. Mas eu acho que é ... há um grau de onipresença que vem junto com isso. Acho que para mim a coisa da qual mais me orgulho é realmente a comunidade. Eu sinto como se tivéssemos tido muita sorte, tanto em como a comunidade expandiu e apoiou o projeto. E a falta, de certa forma, a falta de drama que está lá, tem sido realmente fantástica. Joe Beda: Eu acho que para mim, uma das coisas sobre as quais falamos provavelmente um ano ou dois atrás foi falar sobre Kubernetes (as) chato. Chegando ao ponto em que era confiável o suficiente para que ele desaparecesse na madeira e as pessoas não pensavam nisso porque estavam apenas trabalhando e resolvendo seus problemas. Acho que fizemos bons progressos lá. Eu sinto que estamos chegando nesta meia-idade, onde é chato e está mudando o teor do projeto de uma maneira boa, porque as pessoas estão realmente dependendo disso.
Craig McLuckie: Para mim, acho interessante ver a evolução do Kubernetes. Começou como uma carta de amor para engenheiros de sistemas distribuídos nos primeiros dias, indicando o que poderia ser. Abraçando a ideia de design aberto, comunidade aberta, desenvolvimento aberto. E como isso se tornou algo muito real, tem sido humilhante e surpreendente assistir.
Onde está agora, é real. É fantástico. Eu gasto muito tempo com muitas organizações empresariais que estão apostando o farm no Kubernetes. Eles pretendem ir além do Kubernetes como uma plataforma principal para o gerenciamento de carga de trabalho sem data da próxima geração. E eles estão começando a realmente pensar, “Como eu crio essa plataforma que me permite reunir tudo?” Alcançar sua verdadeira abstração de Goldilocks: nível baixo o suficiente você pode rodar praticamente qualquer coisa, nível alto o suficiente que esconde longe muitos dos caprichos da infra-estrutura.
Amazon Web Services vai all-in no Kubernetes, lança novo serviço de implantação de contêineres
Quando olho para o futuro, acho que ainda há muito trabalho a ser feito para completar a oferta em termos de endurecimento e obtendo a segurança lá, trabalhando em muitos dos casos de borda à medida que trazemos cargas de trabalho adicionais para a plataforma. Em termos de "Do que eu tenho mais orgulho?" Acho que a coisa que mais me orgulha é ver organizações realmente fazerem delas. Há muitas pessoas que tinham todos os motivos para considerar o Kubernetes como um empreendimento competitivo, como um Kubernetes que estava ameaçando um negócio existente ou ameaçando um conjunto de tecnologias que eles construíram.
E, em geral, praticamente todos, todos os fornecedores de escala, todos os provedores de energia, todas as organizações têm, do lado do provedor (nuvem), uma estratégia da Kubernetes agora. E é incrível ver muitas empresas realmente grandes - que deveriam estar ostensivamente competindo e tentando encontrar maneiras de adaptá-las ao seu ambiente de uma maneira única - realmente colaborando com essa comunidade aberta e engajada, e avançando mutuamente necessidades e capacidades de todos os usuários finais. Foi maravilhoso assistir. Tom Krazit: Com o benefício da retrospectiva, o que você teria feito de diferente? Brendan Burns: Houve muitos erros. Eu não sei se há… nós os corrigimos ao longo do caminho.
Joe Beda: Uma das coisas que eu… na VMware, estamos colocando um grande esforço na comunidade em torno de como você implanta e gerencia Kubernetes ao longo do tempo? E acho que muitas pessoas usarão um serviço gerenciado fornecido pelos provedores de nuvem, mas acho que um dos benefícios do Kubernetes é que ele é flexível e entra em muitos lugares diferentes.
Não fizemos um bom trabalho desde o início em termos de fornecer ótimas ferramentas, ótimas opiniões, ótimos guias em termos da maneira correta de executar o sistema ao longo do tempo.mE acho que estamos trabalhando nisso agora, mas eu acho que demoramos muito para chegar lá.
Brendan Burns: Eu acho que a outra coisa ... tem duas outras coisas, agora que penso nisso, uma é que não construímos boas integrações testes. E acho que isso nos assombra até hoje. Temos testes de unidade e temos testes completos de ponta a ponta. Mas se você quiser fazer testes nessa zona intermediária, realmente não há uma grande infraestrutura no projeto e é uma dessas coisas que é realmente difícil de adaptar. Nós também fizemos a governança muito tarde. E nós tivemos sorte. E isso realmente não nos machucou.
Tom Krazit: Você quer dizer em termos de uma versão concorrente emergindo ou ...?
Brendan Burns: Não, não. Quero dizer, como governança de projetos. Como quando trouxemos o comitê de bootstrap para definir as regras de como organizaríamos o projeto, éramos muito grandes. Nós fizemos isso de forma reativa em resposta a ver que estávamos crescendo demais. Nós deveríamos proativamente ... quero dizer, é difícil saber.
Joe Beda: Então, um pouco de história. Então, quando começamos o projeto, um grupo de engenheiros relativamente experientes, com uma visão quase sempre alinhada, estava apenas enrolando as mangas e escrevendo código. E isso funcionou por um bom tempo.
Mas como o projeto ficou mais complicado à medida que passávamos pelo material que estava obviamente no início, quando ficou claro que seria um grande negócio, você começou a terminar com o conflito na comunidade. "Devemos ir nessa direção ou nessa direção?" Agora temos uma estrutura de governança em vigor com um comitê de direção e todo esse tipo de coisa acontecendo. Mas nós esperamos muito para fazer isso.
Brendan Burns: A coisa mais importante para mim foi o momento em que fizemos a primeira pesquisa comunitária, e havia um tremendo entusiasmo com o projeto, o que poderia fazer por pessoas e todo esse tipo de coisa. E havia uma tremenda confusão sobre como se envolver e para onde o projeto estava indo.
Era como: “as pessoas estão realmente empolgadas com isso, mas não sabem como ajudar e não têm ideia de como as decisões Craig McLuckie: Do meu lado, eu diria, é muito difícil descobrir como fazer isso de forma diferente, mas um dos meus maiores arrependimentos é o seguinte: Eu olho para trás na história do Kubernetes porque não fomos mais eficientes em alinhar o mundo do Kubernetes e o mundo do Docker.
Se você realmente pensar sobre o que o Docker trouxe para a festa nos primeiros dias foi, legitimamente foi mudando terreno. A capacidade de empacotar e atomicamente ver toda a carga de trabalho, uma cadeia de ferramentas realmente elegante e bem montada ... e eu senti que estávamos machucados coletivamente.
As duas comunidades ficaram feridas porque não conseguimos realmente uni-las. E acho que o Kubernetes poderia ter se beneficiado tremendamente de muitas das características de design e das experiências de desenvolvimento de ferramentas que a Docker e a comunidade Docker reuniram. E eu acho que a comunidade Kubernetes poderia ter trazido muita riqueza em termos de recursos de sistemas distribuídos para o Docker.
E eu não sei exatamente como Fizemos isso de forma diferente, mas se pudéssemos ter nossas opiniões, acho que reunir esses dois mundos de uma forma muito mais harmonizada teria beneficiado a todos de forma significativa. Tom Krazit: Isso é interessante porque não Era competição nominal realmente entre o que Docker estava tentando fazer com Swarm e o que Kubernetes estava tentando fazer. E eu não sei se você vê exatamente desse jeito porque era um projeto de código aberto versus o que o Docker estava tentando fazer como uma empresa comercial. (Mas) como isso teria sido, você acha? Brendan Burns: Bem, concretamente, eu não acho que deveria haver competição no espaço de orquestração. Eu acho que houve ... e eu acho que isso foi uma coisa que eles fizeram certo, nós realmente tentamos traçar uma linha e dizer: "Acima dessa linha nós vamos ter um ecossistema e nós vamos ter lugares onde você pode criar seu próprio ferramental e suas próprias experiências. ”E você vê os benefícios disso hoje.
Eu acho que provavelmente teríamos avançado como uma comunidade conjunta nesse espírito. Isso não aconteceu. Mas estou com o Craig, acho que (não só) poderíamos ter influenciado um ao outro de maneiras realmente positivas, mas acho que também dificultou a adoção por um tempo, porque havia incerteza e você veria os fornecedores dizendo “Bem , como eu alvo meu monitor? Eu viso meu monitoramento no Kubernetes? Eu direciono meu monitoramento para outro lugar? ”
A consolidação ajuda o ecossistema a avançar.
Tom Krazit: Então, eu quero definitivamente falar sobre coisas que estão por vir, e coisas que você vocês estão pensando (agora) também. Mas quero olhar mais uma vez para trás: quem escreveu o código mais desleixado nos primeiros dias de Kubernetes? Brendan Burns: Sou eu. Joe Beda: Bem, não, OK. Então ...
Brendan Burns: Depende de como você conta.
Joe Beda: Sim. ‘Porque…
Brendan Burns: Você escreveu muito Bash (um tipo de código shell Unix).
Joe Beda: Yeah. Então, Brendan é muito bom em espalhar algumas coisas para provar um ponto e colocar algo em prática. Eu acho que é o seu super poder. Mas cedo eu fiz muito trabalho que era trabalho de zeladoria. E isso incluiu algumas das primeiras coisas sobre como, de fato, lançamos um cluster, naquele ponto, na GCE? E foi ... esses são os pecados que estamos pagando agora em termos das ferramentas do ciclo de vida. E esse material original era ... não era bonito.
Brendan Burns: Esse material viveu muito mais do que ...
Joe Beda: Eu não posso acreditar que ainda está por aí. p>
Brendan Burns: ... qualquer um achou que seria. Embora eu me lembre a certa altura de Craig dizer alguma coisa ... vou parafrasear ele aqui, mas Craig me disse algo como: "Você tem ótimas idéias e é realmente inovador e deixa esse rastro de sujeira atrás de você como você nunca acreditaria. ”Craig McLuckie: (sorri e balança a cabeça)
Joe Beda: Parece que Craig, a palavra“ Filth ”, é como sim, definitivamente. / p>
Brendan Burns: Todos nós temos nossas diferentes forças, eu acho.
Direcionando a nave para o futuro
Tom Krazit: O que você consideraria o maior problema não resolvido em computação distribuída agora? Se aceitarmos que o Kubernetes é mais ou menos uma solução, está caminhando para a maturidade, está se endurecendo, está recebendo todas essas coisas de que vocês estão falando ... basta olhar para o mundo mais amplo da computação distribuída. Qual é o maior problema não resolvido?
Joe Beda: Então, (há) diferentes definições de computação distribuída. Eu acho que é tudo, desde algoritmos de consenso e como você faz replicação de banco de dados entre regiões com relógios vetoriais e essas coisas. Acho que estamos nos movendo para um mundo onde é difícil, (assim) você faz o problema de outra pessoa. E estamos chegando ao ponto em que os padrões e os algoritmos são empacotados.
Se expandirmos isso para incluir coisas como APIs na nuvem e coisas assim, eu acho Um dos problemas difíceis é geralmente a configuração. E isso é tudo, desde Puppet, Chef, Terraform… no mundo Kubernetes como Helm, Kustomize. Há como um gazilhão de projetos. E nenhum deles consegue 100% certo.
Eu acho que enquanto nós temos uma boa biblioteca de idéias de como nós construímos abstrações no nível da linguagem de programação, nós não temos um bom conjunto de ferramentas em vez de abstrações para como você realmente constrói um nível mais alto conceitos quando se trata de configuração de nuvem e sistemas de API.
Brendan Burns: Isso é um infinito ... nós poderíamos gastar uma quantidade infinita de tempo sobre esse tópico.
Eu acho que da minha perspectiva demasiado difícil. Para as pessoas que sabem como construir os sistemas, leva muito tempo e não há reutilização suficiente. E também o espaço total endereçável dos desenvolvedores que conseguem criar aplicativos baseados na nuvem é bem menor do que deveria ser.
Como se você considerasse o número de desenvolvedores que trabalham nos front ends versus o número de pessoas que trabalham na nuvem, esse deve ser o mesmo número de pessoas, eu acho, ou até mais pessoas trabalhando na nuvem. E não é. E eu acho que isso é um fracasso em termos de nós, nós construímos os sistemas até certo ponto e então nós realmente não construímos sistemas que são fáceis para os desenvolvedores usarem.
Eu não acho que o Kubernetes É fácil para os desenvolvedores usarem.
Tom Krazit: É o que eu também ouço.
Brendan Burns: E então, eu acho que é uma área que temos que fazer melhor. E infelizmente não é uma área onde pessoas que gostam de construir coisas, como Kubernetes, também gostam de passar tempo. Então ...
Joe Beda: Na nossa experiência como usuário do setor, há uma disciplina bem reconhecida, as pessoas obtêm diplomas nela, são departamentos inteiros, você tem chefes de UX. Precisamos de um tipo semelhante de movimento em torno da experiência do desenvolvedor no espaço de infraestrutura. E eu acho que o DX, ou a experiência do desenvolvedor, não é tão bem reconhecido quanto uma disciplina.
Craig McLuckie: Configuration. Olhando para além do espaço de configuração, há uma coisa que certamente está na minha mente no momento em que está estabelecendo o ... Joe realmente fez algum trabalho sobre isso. Mas a ideia de identidade de serviço como uma entidade de primeira classe. E ser capaz de lidar com a identidade em um mundo federado altamente conectado. Não apenas em termos dos princípios do usuário, mas a capacidade de estabelecer a identidade do serviço como uma entidade de primeira classe é uma área extremamente importante na qual precisamos investir como indústria.
E acho que ainda não chegamos a um ponto em que essa massa crítica em torno de como atender à identidade como uma entidade de primeira classe esteja lá. Se você olhar dentro de um lugar como o Google, eles têm ótimos sistemas para lidar com isso. Muitas das grandes empresas de internet descobriram isso. Mas isso não foi disponibilizado para as empresas de forma holística. E acho que essa será uma área que gostaríamos que acontecesse nos próximos cinco anos. Joe Beda: Eu diria segurança em geral, embora haja uma enorme lacuna. É visto como essa outra coisa, o problema de outra pessoa, algo que é colocado em camadas depois do fato. Não tornamos a segurança acessível aos desenvolvedores e ao ambiente.
Tom Krazit: Descontando as empresas para as quais você trabalha atualmente, quem você acha que está fazendo algumas das coisas mais interessantes no topo do Kubernetes agora? ? Tivemos várias empresas representadas entre as empresas aqui hoje, startups que estão trabalhando em coisas usando a camada da API do Kubernetes, algumas maneiras interessantes que acho que resolvem alguns desses problemas. Quando você olha para as pessoas que estão explorando o poder do Kubernetes, o que surge?
Brendan Burns: Eu gosto de pensar mais sobre os projetos que estão girando em cima, em vez de ... e eu acho que é isso. na verdade o caminho certo para pensar sobre isso em geral. Como isso se tornou uma camada tão onipresente, uma camada tão uniforme que, se você for criar algo interessante sobre o Kubernetes, ele terá que ir para qualquer lugar. E, geralmente, a maneira de fazer isso é criar um projeto de código aberto e descobrir como você o integra nos produtos.
Na verdade, passei muito tempo pensando em política. Mencionei a política desde o início, mas pensando em política e no trabalho de agente de política aberto que está no CNCF. Há algumas coisas realmente interessantes, já que as pessoas percebem que, sim, você pode proteger o exterior do cluster, mas na verdade também precisa criar regras sobre os tipos de objetos que são colocados em seu cluster. Tipo, qual repositório de imagens você está usando, ou quais tags você está colocando em objetos. Essa coisa acaba sendo incrivelmente importante para algumas das coisas de segurança que as pessoas estão falando.
Abrir e fechar
Tom Krazit: Na verdade, é uma boa parte de uma das outras coisas sobre as quais eu queria falar sobre o que é open source agora.
Se você estivesse iniciando um projeto como o Kubernetes novamente hoje, ainda o tornaria totalmente open source? Você pensaria sobre isso de forma diferente?
Brendan Burns: Eu faria isso de código aberto. Eu acho que ficou claro que para a infra-estrutura, se vai ser onipresente, tem que ser aberto.
Por que algumas empresas de código aberto estão considerando uma abordagem mais fechada
diferente, eu não sei. Eu não construí um banco de dados. Mas para algo que está na pilha onde o Kubernetes está, você precisa ter um monte de empresas diferentes fazendo apostas muito significativas. Tem que estar totalmente aberto, tem que ser vendedor neutro. Eu acho que, na verdade, obtê-lo para fundação é fundamental para o seu sucesso. Então, além do código aberto, na verdade tem que estar em uma base.
Joe Beda: Eu acho que em termos de formar uma empresa em torno do código aberto acho que estamos vendo uma evolução em termos daquilo que modelos de negócios são. Eu acho que o mais importante é resolver um problema de negócios. Não é sobre a tecnologia, é sobre o problema que você resolve. E às vezes esse problema é se você é um provedor de nuvem, como você realmente fornece operações como um serviço.
Mas eu acho que há outros problemas de negócios que, quando você começa a olhar além da persona do desenvolvedor, como essa tecnologia realmente impacta o resto da organização que vai além dos desenvolvedores, que entra no pessoal de operações, que entra nos tomadores de decisão. Acho que isso vai além do código aberto.
E acho que, quando você constrói seu modelo de negócios, é nisso que você precisa pensar. No entanto, acho que um dos problemas é que muitas empresas, e acho que isso faz parte do espírito de startup, é que elas começam com uma tecnologia interessante e descobrem que vão descobrir o modelo de negócios mais tarde. E eu acho que você tem esse viés de confirmação olhando para empresas como o Google onde você está tipo, "Bem, funcionou para eles." Nem sempre dá certo.
Brendan Burns: Mas eu também acho que o desafio para muitos deles é que, como você disse, eles começam com a tecnologia. Eles não começam com um problema de negócios. E, portanto, eles estão em busca de uma maneira de monetizar.
Eu acho que você vê isso também no ecossistema de início, que é que as pessoas gastam muito dinheiro (capital de risco). E então, de repente, eles ficam tipo: "Oh meu Deus, eu tenho que conseguir receita para ..." Isso coloca muita pressão nas pessoas também.
Então, eu não sei. Espero que isso não se transforme em um grande julgamento sobre o código aberto, porque não acho que seja o caminho certo para pensar sobre isso. Mas também vale a pena dizer que o Kubernetes foi concebido para ser um projeto de código aberto. Não havia negócios lá. Não era para ser um negócio em si mesmo. Tom Krazit: Bem, isso é uma coisa que eu já ouvi muita gente se preocupar, se o desenvolvimento de software livre é basicamente financiado por grandes vendedores, há projetos potencialmente inovadores que não poderiam realmente encontrar uma casa, não poderiam realmente encontrar uma maneira de serem notados no mundo, e apoiar o desenvolvimento, tempo e esforço necessários para colocar um projeto em funcionamento.
A maneira que eu olhei é, há um conjunto de modelos comerciais clássicos em torno de código aberto. A primeira é a distro play. E isso quase sempre termina em desastre.
Então, temos a ideia de "criar uma distribuição". Eu também vou ser completamente open source e, eventualmente, vou ter um concorrente que vai aparecer ao longo do tempo se eu for bem sucedido, e eles vão apenas seguir o meu negócio. Eles vão pegar minhas renovações, porque não há nada defensivo lá. Seu custo de vendas é menor do que o meu porque seus clientes já implantaram a tecnologia e acabam de receber a assinatura de suporte de volta. ”
O que leva à filosofia do núcleo aberto, ou coisas de licenciamento esotérico onde você tenta criar jardins de parede artificiais. Isso inevitavelmente leva você para o lado errado da sua própria comunidade. E coisas ruins acontecem.
A segunda maneira de monetizar o código aberto é a Red Hat. Não quero dizer, ser como a Red Hat, quero dizer, literalmente ser Red Hat.
Eles criaram um modelo muito nuançado. E eles alcançaram seu ponto de singularidade na comunidade onde ... eles podem ser o proxy entre os OEMs e os ODMs e os ISVs estabeleceram esse ponto.
Eles tinham uma maneira muito sutil de abordar a comercialização de código aberto . E acho que todo provedor de distro quer se tornar isso. Mas acho que sempre haverá uma única Red Hat. A terceira maneira de monetizar o código aberto é óbvia, ou seja, monetizar um efeito secundário. E as organizações que são mais eficientes em monetizar o efeito secundário são os provedores de nuvem. O efeito secundário é o consumo de infraestrutura. Então, qualquer um que seja capaz de monetizar o efeito secundário tem um interesse em consumir código aberto.
Eu realmente acho que existe um quarto modelo. E eu não acho que isso tenha sido totalmente comprovado ainda, mas meu sentimento é que há um conjunto de coisas em que o código aberto é realmente bom; Em termos de ganhar adoção, ganhar tração, ganhar onipresença, não há nada de ruim com código aberto. Acho que acabaremos em um mundo em que o código que fica entre os aplicativos de uma empresa e a infraestrutura física acabará sendo todo de código aberto. Eu acho que isso vai acontecer. Mas há muitas coisas que o código aberto não sabe.
O código aberto não sabe sobre si mesmo. Não sabe se foi corrigido corretamente, não sabe necessariamente como gerenciar e se atualizar. Não sabe como se otimizar. Então, eu acho que há uma oportunidade de criar uma interseção entre os serviços de dados de código aberto e SaaS que permitem que as pessoas sejam muito mais eficientes na forma como provisionam, implantam, gerenciam, operam, consomem tecnologias de código aberto.
Brendan Burns: Sim, acho que é totalmente verdade. Acho que um dos desafios que estamos vendo agora é que as pessoas que são realmente boas em operacionalizar software estão nas nuvens, porque isso é basicamente o que elas fazem, é operacionalizar o software. E é muito difícil para outras pessoas operacionalizar o software.
Elas aumentaram as expectativas. A expectativa do usuário sobre como você usa o software agora é "pago uma taxa mensal ou uma taxa por hora e obtenho SLAs e todo esse tipo de coisa". Essa é sua expectativa de software. Não é: "Ei, eu instalei algo e li o manual e descubro como executá-lo."
E acontece que é muito difícil se você é uma pequena empresa para fazer isso. E acho que vamos ver as nuvens e outras facilitam. E espero que isso, por sua vez, produza uma economia de software que funcione.
Acho muito claro que, se você faz um bom trabalho na produção de um serviço, pode competir com as nuvens. O floco de neve é um ótimo exemplo disso. Todo mundo tem um data warehouse e ainda assim o Snowflake continua a vender no Azure e a vender em qualquer outro lugar. E há muitos outros exemplos semelhantes. Tom Krazit: Mas o Snowflake não era um projeto de código aberto ...
Brendan Burns: Mas eu não acho que eu veja isso ... é o problema que eu tenho, que é que eu não acho que o modelo de licenciamento é importante. Talvez Snowflake precise ser uma fonte fechada, eu não sei, não tenho ideia. Mas eu realmente não penso… Eu acho que tem a ver com a racionalização aberta do software e os desafios de operacionalizar o software mais do que o modelo de licenciamento.
Joe Beda: Eu acho que há uma interessante recursiva propriedade aqui. Acho que o Kubernetes facilita a execução de sistemas em escala, distribuindo sistemas em escala. Então, na verdade, está reduzindo o custo e a complexidade da criação de software operacionalizado.
E assim, como o Kubernetes se torna um kit de ferramentas para operacionalizar o software, podemos descobrir que somos capazes de separar software gerenciado da nuvem subjacente de certa forma, como floco de neve. E acho que essa será uma oportunidade interessante. Eu acho que o Kubernetes realmente cria muitas oportunidades lá.
Craig McLuckie: A outra coisa que eu observaria é que existe uma força fragmentária muito interessante que estamos começando a ver na indústria agora. Como seria razoável, se você olhar para a ascendência da nuvem, assumir que estaríamos em um período de consolidação maciça. Que tudo estaria ficando mais simples, tudo se consolidaria.
Mas a realidade é que, quando você olha para o mundo das empresas modernas, na verdade está indo para o outro lado. Todo empreendimento com o qual trabalho tem políticas de aquisição multicloud. Eles estão sendo forçados pelos grupos de compras a comprar em várias nuvens. Em alguns casos, os reguladores estão dizendo: “O que acontece se um ator hostil entrar no plano de controle da nuvem? O que você vai fazer então? ”
Há uma tendência de prazo mais longo que é, a utilidade da nuvem como está hoje está por aí… Eu posso colocar muita infraestrutura ao lado de eletricidade barata. E eu posso conseguir economia massiva em escala. Mas também estamos começando a ver a distribuição do fornecimento de eletricidade. Estamos começando a ver o surgimento de coisas como o GDPR. Na Europa, estamos começando a ver as leis locais de privacidade de dados que estão sendo criadas para a fragmentação.
Não há nada que impeça os provedores de nuvem de prosperar e prosperar neste mundo e realmente resolver esses problemas intrinsecamente distribuídos. Mas estamos vendo um período de fragmentação massiva na frota computacional em um período em que acredito que todos esperavam mais consolidação. E falando assim com a necessidade de operacionalizar, acho que há um ímpeto para poder operacionalizar não apenas em um ambiente específico, mas em toda essa frota altamente fragmentada e altamente distribuída.
Acho que é aí que os próximos 10 anos de grandes resultados corporativos para fornecedores de software corporativo serão combatidos. Não é apenas no gigantesco centro de dados em nuvem, mas é nessa frota computacional incrivelmente distribuída e altamente fragmentada. Tom Krazit: Então, digamos que todos vocês consigam o erro de inicialização e queiram iniciar uma empresa em torno de uma projeto de origem. Qual é o seu modelo de negócio? Craig McLuckie: Oh, isso é fácil. Serviços. (A Heptio ofereceu serviços profissionais em torno do Kubernetes antes de ingressar na VMware.)
É engraçado, porque os VCs seriam: “Você vai ser o Mirantis, certo? E é tipo, "Não ..." Desculpe, não há nada errado com o Mirantis, eles fizeram um trabalho maravilhoso com o OpenStack e temos que apreciar e respeitar o trabalho que eles fizeram.
Há muitos pessoas que dizem: "Você não pode comercializar código aberto nas costas dos serviços". E eles estão completamente certos. Você não pode dimensionar uma empresa de serviços. Mas você tem que começar por aí. Porque nada vai te ensinar mais sobre os desafios das complexidades, as necessidades que as organizações empresariais têm para consumir tecnologia e serviços de código aberto.
Então, comece com serviços e você aprenderá muito. Você passa seis meses em um datacenter corporativo implantando sua tecnologia com um grande cliente que está respirando no seu pescoço, você aprenderá algumas coisas.
Isso lhe dará uma plataforma que lhe permitirá comece a identificar onde estão as principais lacunas operacionais, onde estão os principais desafios, o que é realmente difícil sobre essa tecnologia e siga as necessidades do cliente. Você aprenderá muito através desse processo que realmente o levará a identificar onde essas áreas-chave em que você pode investir para resolver problemas são.
Brendan Burns: Eu responderia da mesma forma de maneira um pouco diferente. local, ou seja, eu começaria com SaaS. Talvez seja de código aberto, mas acredite e saiba que você eventualmente terá que se tornar uma empresa de SaaS. E assim comece por aí.
O código aberto, como Craig disse, é ótimo para penetração no mercado, adoção e entusiasmo, mas no final as pessoas não querem operar software. Eles querem que você opere um software para eles. Perceba que isso vai ser o seu negócio e vá de cabeça e você terá uma chance. Joe Beda: Sim, eu acho que você acaba com o SaaS, mas eu acho que ... você sabe, eu passou como 10 anos no Google. Nem todos os desenvolvedores são iguais. Essa experiência no Google não me prepara para entender como é o dia-a-dia de um desenvolvedor de empregos corporativos no Midwest Bank. Tom Krazit: Você acha que isso é responsável por muitas lutas do Google? neste mercado (infra-estrutura de nuvem)?
Joe Beda: Eu acho que o Google é um lugar único. Eles contratam um tipo único de indivíduo. Eu acho que eles estão aprendendo lições difíceis em termos do que é preciso para entregar a empresas reais. Tom Krazit: Então, com os poucos minutos restantes que temos aqui, eu só queria checar uma coisa . Kubernetes é um nome longo. É freqüentemente mal pronunciado e digitado errado. Brendan Burns: Kupernekeys! Tom Krazit: E eu li um relatório que você passou por 13 nomes diferentes antes de se decidir pelo Kubernetes, antes que o Google aprovasse.
Joe Beda: Sim.
Brendan Burns: Havia muito.
Tom Krazit: Então, qual foi o seu nome favorito rejeitado? Craig McLuckie: Oh isso é fácil. Carina. Brendan Burns: Oh, isso foi triste. Na verdade, renomei toda a base de código. Eu realmente fiz isso. Como nome aplicado ...
Joe Beda: É uma nebulosa.
Brendan Burns: É uma coisa de três estrelas. Eu realmente passei e renomei toda a base de código e, em seguida, decidimos não fazer isso.
Joe Beda: Fizemos uma pesquisa no Google.
Brendan Burns: Isso é verdade
Joe Beda: E surgiu como uma estrela pornô softcore. E nós éramos como… “isso não é um bom nome.” Tom Krazit: Vetou aquele. Joe Beda: Eu estava realmente esperando pelo Projeto Sete. Isso era o que eu estava realmente esperando.
Craig McLuckie: Eu acho que, se eu tivesse que realmente ... O que eu mais gostei foi o Locutus.
Brendan Burns: Sim, eu ia dizer isso. Joe Beda: Oh, Locutus, sim, Locutus era bom. Craig McLuckie: Isso teria sido bom.
Joe Beda: Então, esse era o personagem de Star Trek, era o tradutor da Borg. Mas foi amarrado o suficiente para ...
Brendan Burns: Locutus é Picard quando ele se transforma em Borg. (O Borg é o que o Google chamava de sistema interno usado para gerenciar sua infraestrutura, e o Kubernetes é uma versão simplificada do Borg.) Joe Beda: É isso?
Brendan Burns: Não está certo? Joe Beda: Sim, eu não sei. Brendan Burns: Eu acho que está certo. (Gestos para o público.) Eles saberão. (Audiência concorda.) Eles me disseram. Veja?
Craig McLuckie: Mas sim, o embaixador dos Borgs. Sim, isso foi muito bom.
Via: Geek Wire
Nenhum comentário