Nota. transl.: Este artigo, que se converteu nun éxito en Medium, é unha visión xeral dos principais cambios (2010-2019) no mundo das linguaxes de programación e do ecosistema tecnolóxico asociado (con especial atención a Docker e Kubernetes). A súa autora orixinal é Cindy Sridharan, especializada en ferramentas de desenvolvemento e sistemas distribuídos -en particular, escribiu o libro "Distributed Systems Observability" - e é bastante popular no espazo de Internet entre os especialistas en TI, especialmente interesados no tema da nube nativa.
Cando 2019 chega ao seu fin, quería compartir os meus pensamentos sobre algúns dos avances e innovacións tecnolóxicas máis importantes da última década. Ademais, tentarei mirar un pouco o futuro e esbozar os principais problemas e oportunidades da vindeira década.
Quero deixar claro que neste artigo non cubro cambios en áreas como a ciencia de datos (ciencia de datos), intelixencia artificial, enxeñería frontend, etc., xa que persoalmente non teño experiencia suficiente neles.
A tipificación contraataca
Unha das tendencias máis positivas da década de 2010 foi o renacemento das linguas de tipo estático. Non obstante, tales linguaxes nunca desapareceron (C++ e Java son demandados hoxe; dominaron hai dez anos), pero as linguaxes de tipo dinámico (dinámica) experimentaron un aumento significativo da popularidade despois da aparición do movemento Ruby on Rails en 2005. . Este crecemento alcanzou o seu máximo en 2009 co código aberto de Node.js, que fixo que Javascript no servidor fose unha realidade.
Co paso do tempo, as linguaxes dinámicas perderon parte do seu atractivo no campo da creación de software de servidor. A linguaxe Go, popularizada durante a revolución dos contedores, parecía máis idónea para crear servidores de procesamento paralelo de alto rendemento, eficientes en recursos (cos que o propio creador de Node.js).
Rust, introducido en 2010, incluíu avances en nun intento de converterse nunha lingua segura e mecanografiada. Na primeira metade da década, a recepción da industria de Rust foi bastante morna, pero a súa popularidade aumentou significativamente na segunda metade. Os casos de uso notables de Rust inclúen o seu uso para , (falamos diso en - aprox. transl.), un primeiro compilador de WebAssembly de Fastly (agora parte de bytecodealliance), etc. Con Microsoft considerando a posibilidade de reescribir algunhas partes do sistema operativo Windows en Rust, é seguro dicir que esta linguaxe ten un futuro brillante na década de 2020.
Incluso as linguaxes dinámicas teñen novas funcións como (tipos opcionais). Implementáronse por primeira vez en TypeScript, unha linguaxe que che permite crear código escrito e compilalo en JavaScript. PHP, Ruby e Python teñen os seus propios sistemas de escritura opcionais (, ), que se usan con éxito en .
Devolvendo SQL a NoSQL
NoSQL é outra tecnoloxía que foi moito máis popular a principios da década que ao final. Creo que hai dúas razóns para iso.
En primeiro lugar, o modelo NoSQL, coa súa falta de esquema, transaccións e garantías de coherencia máis débiles, resultou ser máis difícil de implementar que o modelo SQL. EN co título "Por que deberías preferir unha forte consistencia sempre que sexa posible" (Por que debes escoller unha consistencia forte, sempre que sexa posible) Google escribe:
Unha das cousas que aprendemos en Google é que o código da aplicación é máis sinxelo e o tempo de desenvolvemento é máis curto cando os enxeñeiros poden confiar no almacenamento existente para xestionar transaccións complexas e manter os datos en orde. Para citar a documentación orixinal de Spanner, "Cremos que é mellor que os programadores xestionen os problemas de rendemento das aplicacións debido ao abuso de transaccións a medida que xorden os pescozos de botella, en lugar de ter presente constantemente a ausencia de transaccións".
O segundo motivo débese ao aumento das bases de datos SQL distribuídas "escaladas" (como и ) no espazo de nube pública, así como alternativas de código aberto como CockroachDB (tamén falamos dela - aprox. transl.), que resolven moitos dos problemas técnicos que facían que as bases de datos SQL tradicionais "non escalasen". Incluso MongoDB, antes o epítome do movemento NoSQL, é agora transaccións distribuídas.
Para situacións que requiren lecturas e escrituras atómicas en varios documentos (a través dunha ou máis coleccións), MongoDB admite transaccións con varios documentos. No caso de transaccións distribuídas, as transaccións pódense utilizar en varias operacións, coleccións, bases de datos, documentos e fragmentos.
Transmisión total
Apache Kafka é sen dúbida un dos inventos máis importantes da última década. O seu código fonte abriuse en xaneiro de 2011 e, ao longo dos anos, Kafka revolucionou a forma en que as empresas traballan cos datos. Kafka utilizouse en todas as empresas nas que traballei, desde startups ata grandes corporacións. As garantías e os casos de uso que ofrece (pub-sub, streams, arquitecturas orientadas a eventos) utilízanse nunha variedade de tarefas, desde o almacenamento de datos ata o seguimento e a análise de streaming, demandados en moitas áreas como finanzas, sanidade, sector público, etc. venda polo miúdo e etc.
Integración continua (e, en menor medida, implantación continua)
A Integración Continua non apareceu nos últimos 10 anos, pero durante a última década si estendeuse ata tal punto, que pasou a formar parte do fluxo de traballo estándar (executa probas en todas as solicitudes de extracción). Establecer GitHub como unha plataforma para desenvolver e almacenar código e, o máis importante, desenvolver un fluxo de traballo baseado en significa que executar probas antes de aceptar unha solicitude de extracción para dominar é o único fluxo de traballo en desenvolvemento, familiar para os enxeñeiros que comezaron a súa carreira nos últimos dez anos.
A implantación continua (a implementación de cada commit como e cando chega ao mestre) non está tan estendida como a integración continua. Non obstante, coa infinidade de diferentes API na nube para a súa implantación, a crecente popularidade de plataformas como Kubernetes (que proporcionan unha API estandarizada para as implantacións) e a aparición de ferramentas multiplataforma e multinube como Spinnaker (construídas enriba das estandarizadas). API), os procesos de implantación tornáronse máis automatizados, simplificados e, en xeral, máis seguros.
Contenedores
Os contedores son quizais a tecnoloxía máis promocionada, discutida, anunciada e incomprendida da década de 2010. Por outra banda, é unha das novidades máis importantes da década anterior. Parte da razón de toda esta cacofonía reside nos sinais mixtos que recibíamos de case todas partes. Agora que a publicidade diminuíu un pouco, algunhas cousas foron máis claras.
Os contedores fixéronse populares non porque sexan a mellor forma de executar unha aplicación que satisfaga as necesidades da comunidade global de desenvolvedores. Os contedores fixéronse populares porque encaixaban con éxito nunha solicitude de mercadotecnia dunha determinada ferramenta que resolve un problema completamente diferente. Docker resultou ser fantástico unha ferramenta de desenvolvemento que resolve o urgente problema de compatibilidade ("funciona na miña máquina").
Máis precisamente, fíxose a revolución Imaxe de Docker, porque resolveu o problema da paridade entre contornas e proporcionou unha verdadeira portabilidade non só do ficheiro da aplicación, senón tamén de todas as súas dependencias de software e funcionamento. O feito de que esta ferramenta estimulase dalgún xeito a popularidade dos "contedores", que son esencialmente un detalle de implementación de moi baixo nivel, segue sendo para min quizais o principal misterio da última década.
Sen servidor
Apostaría a que a chegada da computación "sen servidor" é aínda máis importante que os contedores porque realmente fai realidade o soño da computación baixo demanda. (baixo demanda). Durante os últimos cinco anos, vin que o enfoque sen servidor se expandía gradualmente engadindo soporte para novos idiomas e tempos de execución. A aparición de produtos como Azure Durable Functions parece ser o paso correcto para a implantación de funcións con estado (ao mesmo tempo un relacionadas coas limitacións de FaaS). Observarei con interese como se desenvolve este novo paradigma nos próximos anos.
Automatización
Quizais o maior beneficiado desta tendencia sexa a comunidade de enxeñaría de operacións, xa que permitiu que conceptos como a infraestrutura como código (IaC) se fagan realidade. Ademais, a paixón pola automatización coincidiu co auxe da "cultura SRE", que pretende adoptar un enfoque máis centrado no software das operacións.
API-ficación universal
Outra característica interesante da última década foi a API-ficación de varias tarefas de desenvolvemento. As API boas e flexibles permiten ao programador crear fluxos de traballo e ferramentas innovadoras, que á súa vez axudan co mantemento e melloran a experiencia do usuario.
Ademais, a API-ficación é o primeiro paso cara a SaaS-ficación dalgunha funcionalidade ou ferramenta. Esta tendencia tamén coincidiu co aumento da popularidade dos microservizos: SaaS converteuse nun servizo máis ao que se pode acceder a través da API. Agora hai moitas ferramentas SaaS e FOSS dispoñibles en áreas como vixilancia, pagos, equilibrio de carga, integración continua, alertas e cambio de funcións. (marcación de funcións), CDN, enxeñaría de tráfico (por exemplo, DNS), etc., que floreceron na última década.
observabilidade
Cabe destacar que hoxe temos acceso moito máis avanzado ferramentas para supervisar e diagnosticar o comportamento das aplicacións que nunca. O sistema de vixilancia Prometheus, que recibiu o status de código aberto en 2015, quizais se poida chamar o mellor sistema de seguimento daqueles cos que traballei. Non é perfecto, pero un número importante de cousas implícanse exactamente da forma correcta (por exemplo, soporte para medicións [dimensionalidade] no caso das métricas).
O rastrexo distribuído foi outra tecnoloxía que entrou na corrente principal na década de 2010, grazas a iniciativas como OpenTracing (e o seu sucesor OpenTelemetry). Aínda que o rastrexo aínda é bastante difícil de aplicar, algúns dos últimos desenvolvementos dan esperanza de que desbloqueemos o seu verdadeiro potencial na década de 2020. (Nota: Le tamén no noso blog a tradución do artigo “"do mesmo autor).
Mirando ao futuro
Desafortunadamente, hai moitos puntos de dor que agardan a resolución na próxima década. Aquí están os meus pensamentos sobre eles e algunhas ideas potenciais sobre como desfacerse deles.
Resolución do problema da lei de Moore
O fin da lei de escala de Dennard e o atraso da lei de Moore requiren novas innovacións. John Hennessy en explica por que os adictos problemáticos (específico do dominio) arquitecturas como TPU poden ser unha das solucións ao problema de quedar atrás da lei de Moore. Ferramentas como de Google xa parecen ser un bo paso adiante nesta dirección:
Os compiladores deben admitir novas aplicacións, transportarse facilmente a novo hardware, vincular varias capas de abstracción que van desde linguaxes dinámicas e xestionadas ata aceleradores de vectores e dispositivos de almacenamento controlados por software, ao tempo que proporcionan conmutadores de alto nivel para o axuste automático, proporcionando só- en funcións: tempo, diagnósticos e distribución de información de depuración sobre o funcionamento e o rendemento dos sistemas en toda a pila, mentres que na maioría dos casos proporciona un rendemento razoablemente próximo ao ensamblador escrito a man. Pretendemos compartir a nosa visión, progreso e plans para o desenvolvemento e a dispoñibilidade pública desta infraestrutura de compilación.
CI / CD
Aínda que o aumento do CI converteuse nunha das tendencias máis importantes da década de 2010, Jenkins segue sendo o patrón de ouro para CI.
Este espazo necesita unha gran necesidade de innovación nas seguintes áreas:
- interface de usuario (DSL para codificación de especificacións de proba);
- detalles de implementación que o farán realmente escalable e rápido;
- integración con diversos contornos (escenificación, prod, etc.) para implementar formas de proba máis avanzadas;
- probas e implantación continuas.
Ferramentas para programadores
Como industria, comezamos a crear software cada vez máis complexo e impresionante. Non obstante, cando se trata das nosas propias ferramentas, a situación podería ser moito mellor.
A edición colaborativa e remota (a través de ssh) gañou certa popularidade, pero nunca se converteu na nova forma estándar de desenvolvemento. Se vostede, coma min, rexeita a idea mesma de necesidade unha conexión permanente a Internet só para poder facer programación, entón traballar a través de ssh nunha máquina remota é pouco probable que che conveña.
Os contornos de desenvolvemento local, especialmente para enxeñeiros que traballan en grandes arquitecturas orientadas a servizos, seguen sendo un reto. Algúns proxectos están tentando resolver isto, e estaría interesado saber como sería a UX máis ergonómica para un caso de uso determinado.
Tamén sería interesante estender o concepto de "contornas portátiles" a outras áreas de desenvolvemento como a reprodución de erros (ou ) que ocorren baixo determinadas condicións ou configuracións.
Tamén me gustaría ver máis innovación en áreas como a busca de código semántica e sensible ao contexto, ferramentas para correlacionar incidentes de produción con partes específicas da base de código, etc.
Informática (o futuro de PaaS)
Tras o bombo en torno aos contedores e sen servidores na década de 2010, a gama de solucións no espazo de nube pública ampliouse significativamente nos últimos anos.
Isto suscita varias preguntas interesantes. En primeiro lugar, a lista de opcións dispoñibles na nube pública está en constante crecemento. Os provedores de servizos na nube teñen o persoal e os recursos para seguir facilmente os últimos desenvolvementos no mundo Open Source e lanzar produtos como "pods sen servidor" (sospeito que simplemente facendo que os seus propios tempos de execución FaaS sexan compatibles con OCI) ou outras cousas semellantes.
Só se pode envexar aos que usan estas solucións na nube. En teoría, as ofertas na nube de Kubernetes (GKE, EKS, EKS en Fargate, etc.) proporcionan API independentes do provedor de nube para executar cargas de traballo. Se utilizas produtos similares (ECS, Fargate, Google Cloud Run, etc.), probablemente xa esteas aproveitando ao máximo as funcionalidades máis interesantes que ofrece o provedor do servizo. Ademais, a medida que xurdan novos produtos ou paradigmas informáticos, é probable que a migración sexa sinxela e sen estrés.
Tendo en conta a rapidez coa que está a evolucionar a gama deste tipo de solucións (sorprenderíame moito se nun futuro próximo non aparecen un par de novas opcións), pequenos equipos de “plataforma” (equipos asociados á infraestrutura e encargados de crear plataformas on-premise para empresas que executan cargas de traballo) será incriblemente difícil competir en termos de funcionalidade, facilidade de uso e fiabilidade xeral. Os anos 2010 viron Kubernetes como unha ferramenta para construír PaaS (plataforma como servizo), polo que paréceme completamente inútil construír unha plataforma interna enriba de Kubernetes que ofreza a mesma opción, sinxeleza e liberdade dispoñible no público. espazo de nubes. Enmarcar PaaS baseado en contedores como unha "estratexia Kubernetes" equivale a evitar deliberadamente as capacidades máis innovadoras da nube.
Se miras as dispoñibles hoxe capacidades informáticas, faise obvio que crear o teu propio PaaS baseado unicamente en Kubernetes é equivalente a pintarte nun recuncho (non é un enfoque moi avanzado, non?). Aínda que alguén decida construír hoxe un PaaS en contenedores en Kubernetes, nun par de anos parecerá obsoleto en comparación coas capacidades da nube. Aínda que Kubernetes comezou como un proxecto de código aberto, o seu antepasado e inspiración é unha ferramenta interna de Google. Non obstante, desenvolveuse orixinalmente a principios/mediados dos anos 2000 cando o panorama informático era completamente diferente.
Ademais, nun sentido moi amplo, as empresas non teñen que converterse en expertas na xestión dun clúster de Kubernetes, nin constrúen e manteñen os seus propios centros de datos. Proporcionar unha base informática fiable é un desafío fundamental provedores de servizos na nube.
Finalmente, sinto que retrocedemos un pouco como industria en termos de experiencia de interacción (). Heroku foi lanzado en 2007 e aínda é un dos máis doado de usar plataformas. Non se pode negar que Kubernetes é moito máis potente, extensible e programable, pero boto de menos o fácil que é comezar e implementar en Heroku. Para usar esta plataforma só necesitas coñecer Git.
Todo isto lévame á seguinte conclusión: necesitamos mellores abstraccións de nivel superior para funcionar (isto é especialmente certo para abstraccións de máis alto nivel).
A API correcta ao máis alto nivel
Docker é un gran exemplo da necesidade dunha mellor separación das preocupacións ao mesmo tempo implementación correcta da API de máis alto nivel.
O problema con Docker é que (polo menos) inicialmente o proxecto tiña obxectivos demasiado amplos: todo para resolver o problema de compatibilidade ("funciona na miña máquina") utilizando tecnoloxía de contedores. Docker era un formato de imaxe, un tempo de execución coa súa propia rede virtual, unha ferramenta CLI, un daemon que se executaba como root e moito máis. En todo caso, o intercambio de mensaxes foi Máis confuso, sen esquecer "máquinas virtuales lixeiras", cgroups, espazos de nomes, numerosos problemas de seguridade e funcións mesturadas coa chamada de mercadotecnia para "construír, entregar e executar calquera aplicación en calquera lugar".
Como con todas as boas abstraccións, leva tempo (e experiencia e dor) dividir varios problemas en capas lóxicas que se poden combinar entre si. Desafortunadamente, antes de que Docker puidese alcanzar unha madurez similar, Kubernetes entrou na loita. monopolizou tanto o ciclo de publicidade que agora todo o mundo intentaba manterse ao día dos cambios no ecosistema de Kubernetes e o ecosistema de contedores adquiriu un estado secundario.
Kubernetes comparte moitos dos mesmos problemas que Docker. Por toda a charla sobre abstracción xenial e composíbel, separando diferentes tarefas en capas non moi ben encapsulado. Na súa esencia, é un orquestrator de contedores que executa contedores nun clúster de máquinas diferentes. Esta é unha tarefa de baixo nivel, aplicable só aos enxeñeiros que operan o clúster. Por outra banda, Kubernetes tamén o é abstracción do máis alto nivel, unha ferramenta CLI coa que os usuarios interactúan a través de YAML.
Docker foi (e segue sendo) guay ferramenta de desenvolvemento, a pesar de todas as súas deficiencias. Nun intento de manterse ao día con todas as "lebres" á vez, os seus desenvolvedores lograron implementar correctamente abstracción ao máis alto nivel. Por abstracción ao máis alto nivel quero dicir un subconxunto funcionalidade na que o público obxectivo (neste caso, os desenvolvedores que pasaron a maior parte do seu tempo nos seus contornos de desenvolvemento local) estaba realmente interesado e que funcionou moi ben fóra da caixa..
Dockerfile e utilidade CLI docker debería ser un exemplo de como construír unha boa "experiencia de usuario de máis alto nivel". Un programador común pode comezar a traballar con Docker sen saber nada sobre as complejidades implementacións que contribúan á experiencia operativacomo espazos de nomes, cgroups, límites de memoria e CPU, etc. En definitiva, escribir un Dockerfile non é moi diferente de escribir un script de shell.
Kubernetes está pensado para diferentes grupos obxectivo:
- administradores de clusters;
- enxeñeiros de software que traballan en cuestións de infraestrutura, ampliando as capacidades de Kubernetes e creando plataformas baseadas nel;
- usuarios finais que interactúan con Kubernetes a través de
kubectl.
O enfoque de "unha API para todos" de Kubernetes presenta unha "montaña de complexidade" insuficientemente encapsulada sen orientación sobre como escalala. Todo isto leva a unha traxectoria de aprendizaxe inxustificadamente prolongada. Como Adam Jacob, "Docker trouxo unha experiencia de usuario transformadora que nunca foi superada. Pregúntalle a calquera que utilice un K8s se desexa que funcione como o primeiro docker run. A resposta será si":
Eu diría que a maioría da tecnoloxía de infraestruturas hoxe en día é de nivel demasiado baixo (e polo tanto considérase "demasiado complexa"). Kubernetes está implementado a un nivel bastante baixo. Trazado distribuído no seu (moitos tramos unidos para formar unha traza) tamén se implementa a un nivel demasiado baixo. As ferramentas para desenvolvedores que implementan as "abstraccións de máis alto nivel" adoitan ser as máis exitosas. Esta conclusión é certa nun número sorprendente de casos (se a tecnoloxía é demasiado complexa ou difícil de usar, entón aínda non se descubriu a "API/UI de máis alto nivel" para esa tecnoloxía).
Nestes momentos, o ecosistema nativo da nube é confuso debido ao seu foco de baixo nivel. Como industria, debemos innovar, experimentar e educar sobre como é o nivel correcto de "abstracción máxima e máis alta".
Comercio polo miúdo
Na década de 2010, a experiencia de venda polo miúdo dixital permaneceu practicamente sen cambios. Por unha banda, a facilidade das compras en liña debería chegar ás tendas tradicionais de venda polo miúdo, por outra banda, as compras en liña permaneceron practicamente sen cambios nunha década.
Aínda que non teño ideas específicas sobre como evolucionará esta industria durante a próxima década, estaría moi decepcionado se comprasemos en 2030 do mesmo xeito que o facemos en 2020.
Xornalismo
Estou cada vez máis desilusionado co estado do xornalismo global. Cada vez é máis difícil atopar fontes de noticias imparciales que informen de forma obxectiva e meticulosa. Moitas veces a liña entre a propia noticia e as opinións sobre ela é borrosa. Como regra xeral, a información preséntase de forma tendenciosa. Isto é especialmente certo nalgúns países onde historicamente non houbo separación entre noticias e opinións. Nun artigo recente publicado despois das últimas eleccións xerais do Reino Unido, Alan Rusbridger, antigo editor de The Guardian, :
O principal é que durante moitos anos mirei os xornais americanos e sentín pena polos meus compañeiros de alí, que eran os únicos responsables da noticia, deixando o comentario a persoas completamente diferentes. Porén, co paso do tempo, a piedade converteuse en envexa. Agora penso que todos os xornais nacionais británicos deberían separar a súa responsabilidade polas noticias da súa responsabilidade nos comentarios. Desafortunadamente, é demasiado difícil para o lector medio, especialmente os lectores en liña, discernir a diferenza.
Dada a reputación bastante dubidosa de Silicon Valley no que se refire á ética, nunca confiaría na tecnoloxía para "revolucionar" o xornalismo. Dito isto, eu (e moitos dos meus amigos) estaría encantado que houbese unha fonte de noticias imparcial, desinteresada e de confianza. Aínda que non teño idea de como pode ser unha plataforma deste tipo, confío en que nunha época na que a verdade é cada vez máis difícil de discernir, a necesidade dun xornalismo honesto é maior que nunca.
Redes Sociais
As redes sociais e as plataformas de noticias comunitarias son a principal fonte de información para moitas persoas en todo o mundo, e a falta de precisión e a reticencia dalgunhas plataformas a facer mesmo unha comprobación básica de feitos levou a consecuencias desastrosas como o xenocidio, a interferencia electoral e moito máis. .
As redes sociais tamén son a ferramenta de comunicación máis poderosa que existiu. Cambiaron radicalmente a práctica política. Cambiaron a publicidade. Cambiaron a cultura pop (por exemplo, a principal contribución ao desenvolvemento da chamada cultura cancel [culturas do ostracismo - aprox. trad.] as redes sociais contribúen). Os críticos argumentan que as redes sociais demostraron ser un terreo fértil para cambios rápidos e caprichosos nos valores morais, pero tamén brindaron aos membros de grupos marxinados a oportunidade de organizarse dun xeito que nunca antes tiñan. En esencia, as redes sociais cambiaron a forma en que as persoas se comunican e se expresan no século XXI.
Porén, tamén creo que as redes sociais sacan os peores impulsos humanos. A consideración e a consideración adoitan descoidarse en favor da popularidade, e faise case imposible expresar un desacordo razoado con certas opinións e posicións. A polarización adoita estar fóra de control, polo que o público simplemente non escoita as opinións individuais mentres que os absolutistas controlan os problemas de etiqueta e aceptabilidade en liña.
Pregúntome se é posible crear unha plataforma "mellor" que promova discusións de mellor calidade. Despois de todo, é o que impulsa o "compromiso" o que adoita achegar o principal beneficio a estas plataformas. Como Kara Swisher no New York Times:
É posible desenvolver interaccións dixitais sen provocar odio e intolerancia. A razón pola que a maioría dos sitios de redes sociais parecen tan tóxicos é porque foron construídos para a velocidade, a viralidade e a atención, máis que para o contido e a precisión.
Sería verdadeiramente lamentable que, nun par de décadas, o único legado das redes sociais fose a erosión dos matices e da adecuación no discurso público.
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com