Simon Wardley visitando super-heróis sem servidor
Bem-vindo aos super-heróis sem servidor!
Aqui converso com fabricantes de ferramentas, inovadores e desenvolvedores que nos levam a um futuro brilhante sem servidor.
Hoje estou conversando com Simon Wardley, consultor do Fórum Leading Edge e especialista em percepção situacional, princípios e jogabilidade. Por conveniência, editei a entrevista.
Esse é o grau usual de repetibilidade. Portanto, digo que a arquitetura sem servidor (FaaS) acelerará o desenvolvimento em várias ordens de magnitude. Seu sistema já está 99,9% escrito por alguém. O truque é encontrar a peça certa. Containers? Não me faça rir. Outro dispositivo estranho. - Simon Wardley
Forrest Brazeal : Este não é o seu primeiro ano em TI e você está defendendo ardentemente os desenvolvimentos sem servidor. Você está interessado nisso há muito tempo?
Simon Wardley : Em 2005, no Fotango, planejamos o ambiente e percebemos que a computação estava se transformando em serviços de utilidade pública, o que significava que os tempos de execução de código evoluiriam na mesma direção.
Como resultado, criamos o Zimki e, de fato, foi a primeira plataforma do mundo como serviço: um servidor Javascript aberto via API, um ambiente de execução de código real com cobrança funcional.
Imediatamente analisamos o desenvolvimento, a manutenção e, em geral, de maneira diferente. De repente, vimos novos níveis de detalhes em termos de custos. Ninguém nunca teve isso antes. Criamos todo tipo de conceitos interessantes, como desenvolvimento baseado em valor.
Infelizmente, a empresa-mãe decidiu nos cobrir quando estávamos ganhando impulso. Mas tenho pensado nisso há anos. Como resultado, o Lambda surgiu. Na minha opinião, uma coisa legal.
Mais íngreme do que, digamos ... recipientes?
Você não acha, na verdade eu adoro recipientes. Estes são subsistemas invisíveis. Mas isso não é uma luta de verdade. O verdadeiro acontece nos tempos de execução do código, especialmente quando se trata de cobrança funcional.
Muitos, ao que parece, ainda não reconhecem que a arquitetura sem servidor está mudando o mundo e continuam discutindo sobre o significado da palavra. Surpreende você que se arrastou?
Isso lembra o EC2 em 2006. A Sun há muito tempo se dedica à computação utilitária, mas poucos levam o EC2 a sério: “Um pouco de lixo. Quem precisa disso? E eles descansaram por um longo tempo.
Em 2009 ou 2010, todos esses consultores de gerenciamento disseram algo como: "O futuro são sistemas privados, a AWS não fará nada". Com o mesmo sucesso, podemos dizer: "Bem, para esses carros, é melhor estocar feno para cavalos" Todos sabemos onde a Amazon está agora.
Alguém vai alcançá-los?
Isso é da mesma ópera da palestra que os principais fabricantes de equipamentos fizeram sobre o EC2 em 2008-09. Os cálculos se transformaram em utilitários e tudo o mais os arrastou. Agora chamamos de DevOps: o rápido desenvolvimento de sistemas de ordem superior, mudanças rápidas, equilíbrio intermitente.
E grandes empresas continuaram inércias e se consolaram com o fato de que tudo isso não se tornaria popular e não os afetaria. Claro, eles calcularam mal.
Naqueles dias, os principais fabricantes de equipamentos tinham toda a artilharia pesada. Bezos tinha uma Amazônia e um estilingue. E ele ganhou. Não foi um erro dos engenheiros, mas da liderança. Agora eles querem voltar ao jogo, mas toda a força está do lado da Amazon.
Com a arquitetura sem servidor, acontece o mesmo. Outras empresas, é claro, poderiam ter brigado com a Amazon, mas não, porque não acreditavam nela. E quando eles acreditarem, o trem partirá.
Se a arquitetura sem servidor é tão boa, por que todos estão se agarrando aos contêineres?
Para usar o Lambda, há muito o que descobrir. Este é um meio completamente diferente, um grande salto em frente. Recipientes são mais fáceis. Além disso, eles são portáteis e tudo isso é muito feliz, especialmente fornecedores.
Eles apenas conversam sobre isso e tentam não perceber uma mudança no tempo de execução do código. Os contêineres não forçam a alterar a arquitetura e não mostram que quase todo o seu código já foi escrito por alguém.
O Lambda é realmente uma ferramenta tão poderosa que vale o esforço?
Recentemente, conduzi uma pesquisa no Twitter: quantas vezes as pessoas reescreveram os recursos básicos de registro do usuário. Acabou - um milhão.
... como um exemplo. Se você desenvolve há pelo menos 10 anos, quantas vezes você reescreveu o recurso de registro do usuário? - Simon Wardley
É incrível o alto nível de repetibilidade nas empresas. As pessoas pensam que os governos estão desperdiçando recursos. O pior caso de repetibilidade que eu já vi no governo são 118 sistemas que fizeram quase a mesma coisa.
No setor privado, vi bancos com mil sistemas de gerenciamento de risco idênticos. E quantos existem em todo o mundo? Milhões e dezenas de milhões dos mesmos sistemas.
Peço desculpas loucamente, mas passamos dias inteiros reciclando resíduos de papel. E se você mudar radicalmente a arquitetura, poderá gastar esse tempo em funções realmente úteis. Mas, é claro, é mais fácil dizer: “Uau, contêiner! Entra e sai - ótimo! E o ambiente é quase como chinelos favoritos. ”
Aqui, a propósito, sobre o "dentro e fora". Muitos temem que a arquitetura sem servidor seja "o pior caso de vinculação de fornecedores na história humana ". Isso é verdade? Seremos completamente dependentes do provedor de computação sem servidor?
Claro, seria legal se tivéssemos diferentes fornecedores concorrentes. Mas isso não é tão importante quanto os benefícios e a funcionalidade. As empresas ainda estão competindo entre si. E a chance dos fornecedores concordarem é quase nula. Todo mundo diz: "Nós seremos distinguidos por isso e aquilo."
A única exceção é, obviamente, o amor universal aos recipientes. Todos correm com contêineres, mas o campo de batalha mudou. Você venceu a batalha, mas perdeu a guerra.
Hoje falamos muito sobre batalhas. Quem vencerá e quem perderá se a computação sem servidor se desenvolver de acordo com o seu cenário?
Hoje a Amazon e o Alibaba, que cortaram o chip, estão vencendo. Ainda existem empresas muito inteligentes, como a Netflix, que usam essas tecnologias e se adaptam rapidamente.
E, é claro, empresas de uma ou duas pessoas por um bilhão de dólares aparecerão do nada. Eles terão uma função. Ninguém vai conhecer esses caras, mas todos usarão esse recurso como um serviço.
Quanto aos perdedores ... Não quero incomodá-lo, mas haverá fãs do DevOps entre eles.
Lembre-se, quando a computação era um produto, criamos métodos de arquitetura com base nas características desse produto. Tome, por exemplo, tempo médio de recuperação médio (MTTR). Escalamos, planejamos a capacidade, pensamos na recuperação de desastres e coisas assim.
E então os cálculos se tornaram uma utilidade, o tempo médio de recuperação foi reduzido e criamos novos métodos: sistemas distribuídos, seguro contra falhas, engenharia de caos, implantação contínua. Com o tempo, ficou conhecido como DevOps. Os cálculos como um produto estão desatualizados.
Agora, com a arquitetura sem servidor, novas mudanças nos aguardam, e o DevOps se tornará uma relíquia do passado. E eles vão começar a esquecê-los.
Alguns nem sequer tiveram tempo de mudar para o DevOps.
Sim, existem aqueles que estão apenas começando sua transição de cinco anos para o DevOps. Como resultado, eles chegarão lá, e não há ninguém lá. É uma pena.
Como será o desenvolvimento de software daqui a dez anos?
Nem sabemos quais métodos crescerão na arquitetura sem servidor. Não vou dizer com certeza, mas há algumas suposições.
Os desenvolvedores atenderão a questões financeiras. O custo da função será mais importante do que nunca. Novos modelos de desenvolvimento baseados em valor aparecerão: uma empresa construirá um sistema para outra, mas não por um preço fixo, mas por parte do lucro desse sistema.
Obviamente, para isso, as próprias empresas devem entender que lucro o sistema traz.
A estrutura da empresa também mudará. Isso é uma coisa comum. A eletricidade evoluiu de um produto para uma utilidade, e muitos sistemas de ordem superior surgiram. O mesmo aconteceu com a produção quando o Fordismo e o sistema americano apareceram.
Quando isso acontece, novos métodos aparecem e a forma da organização muda. Eu acho que será o mesmo com a arquitetura sem servidor.
Ou seja, na sua opinião, no desenvolvimento de software haverá menos perdas e maior eficiência?
Vamos definir os termos. Não confunda perdas com despesas. Essas são coisas diferentes.
Veremos alta eficiência e rápido desenvolvimento de sistemas de ordem superior. Quanto aos custos de TI, eles falaram sobre o EC2 em 2007-2008. E olá, o paradoxo de Jevons .
De fato, acontece que quanto mais eficiente a coisa, mais precisamos dela. As pessoas pensam que economizarão muito com a computação sem servidor. Eu tenho que rolar meu lábio. Vamos apenas levar mais.
E a última pergunta: o que você diria a uma pessoa que não pode escolher entre arquitetura e servidores sem servidor?
[risos] Mas ele é meu amigo ou o quê?
Na minha opinião, temos mais em comum do que desacordo. Estou mais preocupado com o tempo. A guerra irrompe em um campo de batalha sem servidor. E toda a retórica deveria estar lá. Equilíbrio intermitente - é o seguinte: você pensa, espera mais cem anos, depois olha - eles navegaram. - Simon Wardley
Vamos dizer amigo.
Bem, então, deixe-o escolher o que deseja se o projeto for de curto prazo. Eu não sou contra recipientes.
Mas se o projeto for longo, é melhor não ter tempo para dominar a computação sem servidor. O futuro está com eles.