Build2019, compreendendo o que vimos

Apenas na semana passada, foi realizada a maior conferência de desenvolvedores do Microsoft Build2019 . Tendo ido para lá, persegui dois objetivos.

• O primeiro objetivo é entender para onde a Microsoft está indo em termos de desenvolvimento e quais tecnologias e abordagens estão promovendo.
• O segundo objetivo é entender o estado da comunidade em torno da Microsoft. Build - uma conferência pública - oferece uma idéia melhor do que as conferências internas da Microsoft para seus funcionários. Em um evento público, você pode tirar conclusões mesmo sobre o número de pessoas que compareceram à sessão.

Para mim, identifiquei vários tópicos importantes sobre os quais quero compartilhar meus pensamentos:

• Roteiro do .Net Framework
• Kubernetes
• Sem servidor
• Computação de borda
• Big Data, Machine Learning, Inteligência Artificial
• Plataforma de apresentação do Windows

Roteiro do .Net Framework

No Build2019, havia um relatório do .NET Platform Overview and Roadmap . Eu recomendo assistir e ler Introdução ao .NET 5 , C # 8 e um relatório separado sobre C # 8 - O futuro do C #

• Minhas observações desde o anúncio do .net core 3.0 são as seguintes: a criação dos padrões .net core / .net estava muito correta, mas no .net, como em outras plataformas, foi acumulado muito código que não pode ser captado e transferido dessa maneira. E, portanto, você precisa levar o núcleo .net / padrão para projetos antigos com modificações mínimas. O WinForms / WPF foi levado para o código-fonte aberto, a próxima versão já estará com o padrão .net oculto e você poderá esquecer a estrutura antiga dos arquivos csproj e obter muitos outros bônus. As coisas certamente estão corretas, mas também são causadas pelo fato de que o legado também deve ser suportado.
• É bom que, para plataformas móveis, o UWP não seja mais lembrado, e apenas o Xamarin para desenvolvedores de C # permaneça.
• No estande da equipe do .Net Core, fiz a pergunta: “E que grandes mudanças você planeja fazer no .Net 6-7-8? E você terá um motivo para aumentar a versão principal do produto a cada ano? ” Acima de tudo, gostei da parte da resposta que traduzi, entendi como “bem, essa é a visão, e como será a próxima, veremos. „
• Eu tinha pensamentos semelhantes sobre o C # 8, bem como sobre todos os lançamentos após async / wait, o que realmente mudou o estilo de programação no C #. E tudo o resto, é claro, era divertido e acrescentava açúcar sintático, mas o fundo Async / Await parecia bastante desbotado. Mas o código está se tornando cada vez menos parecido com o C # clássico. O que você diria sobre esse código, então em 2012

Mas o que eu não gostei nesta sessão foram as tentativas persistentes de enfatizar mais uma vez todos os desenvolvedores de .net / C # a necessidade de conhecer, entender e usar o Machine Learning, os Serviços Cognitivos , etc. diariamente.

Obviamente, um desenvolvedor inteligente deve entender essas coisas, estudar e praticar, se possível. Mas, em 99% dos casos, isso não é necessário no projeto, e esse evangelismo persistente, francamente, começa a incomodar.

Para ser sincero, eu realmente não acredito no futuro de projetos como o Spark.Net, que foram discutidos nesta sessão. A experiência nos lembra que tentativas semelhantes de escrever Wrappers em C # ou portar completamente um projeto de dados para C # nos últimos 10 anos geralmente terminavam em nada, porque a comunidade é menor e o idioma não é tão difícil de mudar.

Após o Build2019, houve um anúncio de que o .Net Framework 4.8 é a versão principal mais recente do .Net Framework e haverá apenas pequenas alterações. Em suma, é hora do .Net Core.

Service Fabric vs Kubernetes

Três anos na Microsoft e por quase meio ano no EPAM, não posso dar uma explicação técnica normal sobre por que você precisa do Service Fabric (e, ao mesmo tempo, não trabalha na Microsoft), se houver o Kubernetes.

• Por um longo tempo, os “intérpretes” disseram que essas são plataformas iguais, mas não é assim (google elementar).
• Houve rumores de que o SF é mais maduro para o desenvolvimento do Windows e o Kubernetes para Linux.
• Bem, ao mesmo tempo, dizem eles, na SF, seus desenvolvedores poderão usar suas habilidades no ambiente Windows, e nos K8s você precisará aprender Linux e reaprender. Concordo que o código legado e a necessidade de reaprender-reaprender é um argumento sério, mas, por outro lado, o SF era bastante complicado e, na minha opinião, não é mais fácil que o K8s. Bem, por um lado, o Linux precisa ser estudado e conhecido de qualquer maneira. Até no ossificado "parque eólico" (que também sou). Por outro lado, Kubernetes abstrai bastante disso.

No Build2019, acabei com o SF, porque havia um relatório sobre ele (embora o título fosse sobre Missão Crítica ***) .

E de acordo com as peças Kubernetes 20-30 em todas as seções. Vou dar apenas a parte que recomendei ver no meu projeto.

• Fundamentos do Kubernetes no Microsoft Azure e o caminho a seguir (planos de desenvolvimento)
• Kubernetes sem servidor, KEDA (dimensionamento automático baseado em eventos) e Funções do Azure (inicie o Azure Functions no Kubernetes)
• Segurança corporativa na era dos contêineres e Kubernetes

Devops

• Implantações de YAML CI / CD e Kubernetes
• Desenvolvimento de aplicativos ponta a ponta e DevOps no Serviço Kubernetes do Azure
• De zero ao super-herói do DevOps: The Container Edition (embora se você já estiver usando o AKS e o Azure DevOps, é improvável que ouça algo novo)
• Protótipos de colaboração de desenvolvedor para AKS com Dev Spaces

Na minha opinião, a Microsoft se rendeu e aceitou a realidade - a comunidade .net, de fato, não aceitou o Service Fabric. Mas o Kubernetes se tornou de fato o padrão até para o mundo .net, com o qual parabenizo você e eu.

ServidorMenos a todos

Ainda assim, muito se fala sobre a computação sem servidor. Mas, se anteriormente apenas as Funções do Azure e os Aplicativos de Lógica estavam envolvidos nesse molho, agora até o Banco de Dados SQL do Azure ServerLess foi conectado (quando vi o anúncio, fiquei muito surpreso porque algo estava errado e o SQL sem Servidor parece interessante).

Por outro lado, o Serverless pode ser iniciado não apenas no Azure, mas também localmente no contêiner. Assim, o Serverless se torna mais compreensível e menos mágico (os engenheiros geralmente não gostam de mágica, porque não entendem como funciona ... e, se não funcionar, como consertar a mágica).

SQL ServerLess

A essência do SQL Serverless é que você pode especificar os limites inferior e superior dos recursos consumidos e pagará no limite inferior, além do que consome entre os limites inferior e superior. Um recurso secundário que você pode pausar o SQL (e não pagar por recursos de computação) se o banco de dados não for usado (você pode pausar por 6 horas agora), eu não consideraria isso, porque para que não haja uma única solicitação ao banco de dados por algumas horas - esta é uma situação muito estranha, porque há pelo menos monitoramento e a base iniciará (como prometido) em 30 a 60 segundos, o que também é importante.

Edge de assinatura ou computação em nuvem em mais do que o Microsoft Data Center

• Era uma vez, em 2008-2010, a Microsoft disse algo assim: “aqui você tem nosso mágico Serviço em Nuvem, reescreva seus aplicativos para eles (Função Web / Trabalhador) e ficará feliz.” A felicidade não funcionou, porque O legado estragou tudo.
• Apareceram então máquinas virtuais, mas agora não importa.
• Então, quando ficou claro que mesmo agora poucas pessoas podem se mudar completamente para a nuvem, você ainda precisa criar soluções híbridas. No começo, isso significava VPN para o Azure. Em seguida, veio a pilha do Azure (um complexo de hardware e software que é semelhante ao Azure na API e poderia conter a carga de produção, se o regulador não permitir a publicação na nuvem pública e manter o dev / test com dados anônimos na nuvem pública)
• Então, todo tipo de solução de IoT se tornou moda e popular (para a Microsoft e outros grandes players ... a telemetria foi escrita por um longo tempo). Inicialmente, no cenário da Connected Factory (fábrica / linha de montagem), eles sugeriram o uso de soluções da Nuvem do Azure, mas o setor explicou que a latência entre suas fábricas poderia ser muito maior que a permitida e interromper a linha de montagem devido à Internet "piscante" não é viável a decisão.
• Como resultado, apareceu pela primeira vez o Azure IoT Edge, que, embora tenha sido baixado do Azure, mas funcionou e processou dados no seu hardware (você precisava de um host compatível com o Docker, que pelo menos às vezes se conectava à Internet), mas no início tinha um conjunto muito modesto de recursos. Uma boa conversa sobre esse tópico foi Azure IoT Edge & AI: habilitando o Intelligent Edge
• Então, quando o IoT Edge se mostrou útil (para consumidores e para finanças da Microsoft), os serviços que antes eram considerados Cloud Only começaram a aparecer como cogumelos. Por exemplo, os Serviços Cognitivos chegaram ao Edge. O controle visual da qualidade dos produtos em uma linha de montagem ou transportador é muito mais fácil de fazer em um contêiner de docker local do que em reunir latência para o Data Center do Azure.
• Mas, no Build2019, muitos desses serviços foram publicados ou apareceram como pré-visualização (gosto dos Serviços de Fala para síntese de fala principalmente da pré-visualização. Faltava muito em dispositivos sem acesso constante à Internet).
• Ao mesmo tempo, foi mostrado, anunciado pelo SQL Server, Edge ( Simplifique a arquitetura de borda com o Azure SQL Database Edge ).
  
  Não, o SQL 2017 está em execução no Linux no Docker há muito tempo, mas exigia 3,5 GB de memória. Essa versão também é otimizada para memória (500 MB <e é executada em processadores ARM), para dispositivos Edge (geralmente há pouca memória neles). E, ao mesmo tempo, há o trabalho de Streaming e Análise de Séries Temporais, que parece muito interessante.
• Além disso, foi lançado o hardware do Azure Sphere para soluções IoT seguras .
• Eles mostraram o equipamento de computação do Azure Edge , o que não deixa dúvidas de que o tópico é monitorado de perto.
  
  True box, gostei mais da migração de dados para o Azure porque Parece mais sólido.

  
  

Big Data, Machine Learning, Inteligência Artificial

Nessas áreas, escreverei da perspectiva de um ex-desenvolvedor (embora não exista ex-desenvolvedores) e não de um especialista em dados.

Muitas vezes, conheci a posição "interessante" de alguns clientes de que o IaaS deveria ser feito no Aws, PaaS no Azure e Data no GCP. Não se pode deixar de concordar que historicamente cada um dos fornecedores se especializou em algo, mas agora, se você o observar em grandes quantidades, em muitos serviços a paridade foi alcançada (a diferença de nuances, é claro, permanece). A integração de soluções entre diferentes provedores de nuvem é, obviamente, um trabalho interessante e uma mina de ouro, mas, como regra, é extremamente ineficiente para o próprio cliente (você sempre deve pagar pelo tráfego de saída, mas também há latência e complexidade / complexidade da solução).

Provavelmente, a direção mais promissora para o Microsoft / Azure, no futuro próximo, do ponto de vista do dinheiro novo, é trabalhar com dados - “olá” Spark / Hadoop / Kafka, Data Lakes e muitos serviços mais interessantes, mas ao mesmo tempo com tópicos importantes (alguém não gosta no hype para fazer vendas), como Inteligência artificial (eles novamente nos mostram a Cortana, novamente nos mostram carros inteligentes). O número de anúncios e os casos mais importantes (às vezes sintéticos e às vezes até mostram um cliente satisfeito) sobre o uso dos serviços de Big Data no Azure na conferência estavam fora de escala. De acordo com a AI, existem 37 sessões (existem 171 para todo o Build2019, se subtrairmos os relatórios do corredor de 15 minutos e as sessões de programação para os alunos.). Havia até relatórios do DevOps para Big Data, plataforma Windows AI e AI para PowerBI. A maioria dessas tecnologias é de código aberto, todas elas são orientadas pela comunidade e estão presentes nos três grandes fornecedores. Há alguns anos, admito, não me lembro de uma abordagem tão ativa dos serviços de dados.

Plataforma de apresentação do Windows

Uma das sessões que eu gostaria de mencionar é a sessão da Plataforma de Apresentação do Windows (WPP). Para ser sincero, pensei inadvertidamente que se tratava do Windows Presentation Foundation (WPF), mas fiquei agradavelmente surpreso que o tópico fosse mais amplo do que o esperado.

Em 2009, quando o WPF foi lançado, o tópico era popular: hospedando controles WinForms em aplicativos WPF ou vice-versa - tentando inserir controles WPF no WinForms. Era tudo do que muitas vezes era impossível pegar e virar as peças enormes do aplicativo para a nova estrutura. Nos primeiros lançamentos, esses recursos não eram anunciados, mas quando ficou óbvio que a compatibilidade com versões anteriores tinha que ser puxada, eles começaram a promover ativamente.

Portanto, em 2019, discutiremos como hospedar controles U WP no WPF (ilhas XAML) e como dissociar os componentes da interface do usuário e o sistema operacional no WinUI 3.0 (ou seja, fornecer controles / compilador / tempo de execução como pacotes de nuget e não esperar pelo Windows Update .) A idéia é ótima, mas era necessário fazê-lo na primeira versão do UWP, porque nessa época a equipe do Entity Framework havia removido o EF do .net Framework há vários anos para parar de depender das atualizações do Windows. E o que se tornou o .Net Core estava em desenvolvimento.




Um grande salão foi reservado para a sessão, mas havia espaço livre suficiente no salão (o desenvolvimento para Windows foi enterrado por cerca de 10 anos), mas esse não é o ponto. Havia muito poucos jovens no salão (eu comparo com uma sessão no Asp.Net Core ou, especialmente, Machine Learning). Essas são apenas minhas observações subjetivas: não lida com o desenvolvimento funerário do Windows.

Ecossistema Microsoft para Desenvolvedores

Como engenheiro de campo da Microsoft, apoiei oficialmente apenas o que a própria Microsoft fazia. A partir dessa abordagem, o conhecimento de tudo o mais atrofia. Agora que deixei a Microsoft e me tornei arquiteto de soluções, tornou-se vital preencher essa lacuna. E na Build, havia uma exposição inteira de soluções para parceiros e desenvolvedores de desenvolvimento, onde você podia ir a qualquer estande e fazer perguntas, pedir uma demonstração. Economizei semanas visitando esses estandes.

• Você ainda pode usar o SonarQube para gerenciar dívidas técnicas (qualidade do código, não arquitetura, é claro)
• Existem soluções DevOps especializadas em Kubertenes que são muito mais fáceis de usar que o Azure DevOps
• Existem soluções interessantes, como o Aqua (aquasec) / Snyk, para auditar o conteúdo das imagens do docker e já executar contêineres.
• Existem soluções interessantes para monitorar e rastrear aplicativos distribuídos com vantagens sobre o ELK banal ou o Azure Monitor (Application Insights + Log Analytics) como o Signalfx
• Já estou em silêncio sobre o R # e o ambiente de desenvolvimento no .net da Jetbrains (lembrei-me do R #, mas não o usei, porque escrevi um pouco e, portanto, não ouvi muito sobre o ambiente de desenvolvimento).
• Ele estava cheio de todos os tipos de soluções baseadas em AI / ML / Data, etc., mas não fui muito a eles, porque Não tenho experiência prática em soluções industriais de Big Data e não poderei avaliar os benefícios.

Comunicados

Para ser sincero, pessoalmente os anúncios deste ano ( aqui e aqui ) não me machucaram, e eu não me lembro particularmente deles. Em computadores quânticos, é bom exagerar, mas é imperceptível que essa seja a tecnologia de hoje. E nada mais foi realmente lembrado.

• Bem, não sobre a versão experimental do Edge (um navegador da Microsoft) com o mecanismo Chromium, mas escreva sobre a disponibilidade de seus códigos-fonte ! (Era conhecido muito antes do Build2019 )
• O autoscaling controlado por eventos do Kubernetes (KEDA) não parece ruim, mas de alguma forma o efeito uau não me causou. Embora a ideia seja maravilhosa.

Posfácio

Na verdade, eu esperava mais representantes de indústrias não industriais, como A Microsoft há muito tempo afirma que procura ajudar os negócios com projetos, e não com seus objetivos. Sim, claro, houve relatos com a Airbus , BMW ... mas eu esperava mais.

O Office365 não é o meu tópico, então decidi nem considerar esse problema.

Todas as opções acima são minha opinião pessoal, com base em minhas observações e em minha experiência anterior. Eu não finjo ser objetivo. Você pode discutir qualquer tese.