就在上周，
举行了最大的Microsoft
Build2019开发人员
大会 。 到达那里后，我追求了2个目标。
- 第一个目标是了解Microsoft的发展方向以及所推广的技术和方法。
- 第二个目标是了解Microsoft周围社区的状况。 与员工内部的Microsoft会议相比，Build（一个公开会议）提供了更好的主意。 在公共活动中，即使参加会议的人数也可以得出结论。
对于我自己，我已经确定了几个关键的话题，我想与他们分享自己的想法：
- .Net框架路线图
- Kubernetes
- 无服务器
- 边缘计算
- 大数据，机器学习，人工智能
- Windows演示平台
.Net框架路线图
在Build2019上，有
.NET平台概述和路线图的报告。 我强烈建议您观看和阅读
.NET 5 ，
C＃8 入门以及有关C＃8的单独报告-C＃
的未来
- 自发布.net core 3.0以来，我的观察结果是：创建.net core / .net标准是非常正确的，但是在.net中，像在其他平台中一样，已经积累了许多无法像这样获取和传输的代码。 因此，您需要以最小的修改将.net核心/标准包子带到旧项目中。 WinForms / WPF已被开源，下一个版本将已经包含.net标准，您可以忘记csproj文件的旧结构并获得更多收益。 事情当然是正确的，但是它们也是由必须同时支持遗产这一事实造成的。
- 很好的是，对于移动平台，UWP不再被记住，只剩下用于C＃开发人员的Xamarin。
- 在.Net Core团队的立场上，我问了一个问题：“您计划在.Net 6-7-8中进行哪些重大更改？ 您是否有理由每年增加产品的主要版本？” 最重要的是，我喜欢我翻译的答案部分，我理解“这是愿景，以及接下来的愿景，我们将看到。 „
- 我对C＃8以及异步/等待之后的所有发行版都有类似的想法，这确实改变了C＃的编程风格。 当然，其他所有内容都很有趣，并添加了语法糖，但是Async / Await背景看上去已经褪色了。 但是代码变得越来越不像经典的C＃。 您会对这样的代码说什么，所以在2012年
但是，我对本次会议不满意的是，不断地尝试向所有.net / C＃开发人员强调，他们每天都需要了解，理解和
使用机器学习，认知服务等。
当然，如果可能的话，聪明的开发人员应该理解，学习和实践这些东西。 但是，在99％的情况下，该项目并不需要这样做，坦率地说，这种持续的传福音开始变得麻烦。
老实说，我并不真正相信在本次会议中讨论过的Spark.Net等项目的未来。 经验提醒我们，在过去的10年中，用C＃编写Wrappers或将数据项目完全移植到C＃的类似尝试通常没有任何结果，因为社区较小，语言也不难更改。
Build2019之后，有一个
公告称.Net Framework 4.8是.Net Framework的最新主要版本，并且只有很小的变化。 总之，是时候使用.Net Core了。
服务结构与Kubernetes
如果有Kubernetes，在Microsoft呆了3年，在EPAM呆了近半年，我无法就为什么需要Service Fabric（并且同时在Microsoft不工作）提出正常的技术解释。
- 长期以来，“解释者”说这些平台是平等的，但事实并非如此（谷歌基础知识）。
- 然后有传言说，SF对于Windows开发更成熟，而Kubernetes对于Linux更成熟。
- 他们说，同时，在SF，您的开发人员将能够在Windows环境中使用他们的技能，而在K8中，您需要学习Linux和重新学习。 我同意，遗留代码和重新学习的需要是一个严肃的论点，但另一方面，SF非常复杂，在我看来，这并不比K8容易。 好吧，一方面，无论如何都需要研究和了解Linux。 甚至到僵化的“风电场”（我也是）。 另一方面，Kubernetes对此进行了很多抽象。
在Build2019上，我为SF付出了自己的一切，因为 上有
1个报告（尽管标题是关于“关键任务***”的） 。
根据Kubernetes的说明，所有部分的内容都为20-30。 我只会给出我建议在项目中看到的部分。
开发者我认为，Microsoft投降并接受了现实-.net社区实际上不接受Service Fabric。
但是，即使对于.net世界，Kubernetes实际上已经成为标准，我向您和我表示祝贺。服务器对所有人
尽管如此，关于ServerLess计算的说法还是很多。 但是，如果以前仅将Azure函数和逻辑应用程序包装在其中，那么现在甚至连Azure SQL数据库ServerLess也都迷上了（当我看到该公告时，我很惊讶，因为出了点问题，ServerLess SQL听起来很有趣）。
另一方面，Serverless不仅可以在Azure中启动，还可以在容器中本地启动。 因此，Serverless变得更容易理解，也变得更没有魔力（工程师通常不喜欢魔力，因为他们不了解它是如何工作的……如果不起作用，那么如何修复魔力）。
SQL Serverless的本质是您可以指定所消耗资源的上限和下限，并在下限以及上限和下限之间的消耗量上付费。 一个较小的功能，如果不使用数据库（您现在可以暂停6个小时），则可以暂停SQL（而不用支付计算资源），我不认为这是因为 这样一来，几个小时内就不会有对数据库的单个请求-这是一种非常奇怪的情况，因为至少要进行监视，并且数据库将在30-60秒内启动（如承诺的那样），这也很重要。
Subscription Edge或云计算不只是Microsoft数据中心
- 曾几何时，在2008年至2010年，微软曾说过这样的话：“在这里，我们有了不可思议的Cloud Service，为它们重写了应用程序（Web / Worker角色），您将感到幸福”。 幸福没有用，因为 传统破坏了一切。
然后出现了虚拟机，但是现在没关系了。- 然后，很明显，即使现在很少有人可以完全迁移到Cloud，您仍然需要制作Hybrid解决方案。 最初，这意味着要使用VPN到Azure。 然后是Azure Stack（一种硬件-软件复合体，类似于API中的Azure，如果监管机构不允许在公共云中发布，并且可以在公共云中使用匿名数据进行开发/测试，则可以在其上承担生产负载）
- 然后，各种各样的物联网解决方案变得流行和流行（对于Microsoft和其他大型公司……遥测已经写了很长时间）。 最初，在连接工厂（工厂/装配线）的情况下，他们建议使用Azure Cloud的解决方案，但业内人士解释说，工厂之间的延迟可能会比允许的高得多，并且由于“闪烁”的Internet而停止装配线是不可行的决定。
- 结果，首先出现了Azure IoT Edge，尽管它是从Azure下载的，但是可以在您的硬件上工作和处理数据（您需要Docker兼容主机，至少有时连接到Internet），但是起初它具有非常适度的功能集。 关于此主题的精彩演讲是Azure IoT Edge＆AI：启用智能边缘
- 然后，当IoT Edge证明是有用的（对于消费者和Microsoft财务）时，以前被视为“仅云”的服务开始像蘑菇一样出现。 例如， 认知服务来到Edge。 从本地docker容器执行装配线或输送机上产品的视觉质量控制要比向Azure数据中心装配延迟要容易得多。
- 但是在Build2019上，这些服务中有许多是公开的或作为预览出现的 （我喜欢语音服务来进行语音合成，其中大部分来自预览。在无法持续访问互联网的设备上非常缺乏）。
- 同时，它被SQL Server宣布为Edge （ 使用Azure SQL Database Edge简化Edge体系结构 ）。
不能，SQL 2017早已在Docker的Linux上运行，但它需要3.5 GB的内存。 此版本还针对边缘设备（通常只有很少的内存）针对内存（500MB <并且在ARM处理器上运行）进行了内存优化。 同时，还有内置时间序列流和分析的工作，这听起来非常有趣。 - 此外，还推出了用于安全物联网解决方案的基于Azure Sphere的硬件。
- 他们展示了Azure Edge计算设备，这无疑使该主题受到密切监视。
确实，我更喜欢将数据迁移到Azure，因为 看起来更坚固。
大数据，机器学习，人工智能
在这些方面，我将从前开发人员（尽管没有前开发人员）和数据专家的角度撰写文章。
我经常遇到一些客户的“有趣”立场，即应该在Aws中进行IaaS，在Azure中进行PaaS，在GCP中进行数据。 不能不同意历史上每个提供者都专门从事某项工作，但是现在，如果您大量研究它，则在许多服务方面已经实现了均等（细微差别当然仍然存在）。 当然，在不同的云提供商之间集成解决方案是一项有趣的工作，而且是金矿，但通常来说，对于客户本人而言效率极低（您始终必须为传出流量付费，但解决方案也存在延迟和复杂性/复杂性）。
从新资金的角度来看，Microsoft / Azure在不久的将来最有希望的方向是使用数据-“ hello” Spark / Hadoop / Kafka，Data Lakes和更多有趣的服务，但同时涉及热门话题（有人不喜欢宣传人工智能）（他们再次向我们展示了Cortana，再次向我们展示了智能汽车）。 会议上有关在Azure中使用大数据服务的公告的数量，最重要的是案例（有时是综合案例，有时甚至表现出满意的客户），而且规模还很小。 仅就AI而言，总共有37节课（如果减去15分钟的走廊报告和学生编程课程，整个Build2019将有171节课）。 甚至还有关于大数据的DevOps报告，Windows AI平台和PowerBI的AI。 这些技术大多数都是开源的，它们都是社区驱动的，并且存在于所有3家大型提供商中。 我承认，几年前，我不记得有这么积极的数据服务方法。
我要提及的会议之一是Windows Presentation Platform（WPP）会议。 坦白地说，我无意中认为这与Windows Presentation Foundation（WPF）有关，但是令我感到惊讶的是，该主题的范围超出了预期。
早在2009年，当WPF刚刚启动时，这个话题就很流行：在WPF应用程序中托管WinForms控件，反之亦然-试图在WinForms中插入WPF控件。 这完全是不可能将庞大的应用程序片段转移到新框架上的原因。 在最初的版本中，此类功能并未公布，但是当很明显必须取消向后兼容性时，它们便开始积极推广。
因此，在2019年，我们将讨论如何
在WPF（XAML岛）中托管U
WP控件 ，以及如何
在WinUI 3.0中将UI组件与操作系统分离 （即以nuget包的形式提供控件/编译器/运行时而不是等待Windows Update） 。）
这个主意很棒，但是有必要在UWP的第一个版本中执行，因为到那时，实体框架团队几年前已从.net Framework中删除了EF，以停止依赖Windows Update。 .Net Core变成了开发中。
最重要的是，它不仅适用于Windows 10的最新版本，而且还很旧，但仍然适用。 会议预留了一个大大厅，但大厅中有足够的可用空间（Windows的开发已被埋葬了约10年），但这不是重点。 大厅里的年轻人很少（我将其与在Asp.Net Core上的会议，或者特别是在机器学习上的会议进行比较）。 这些只是我的主观观察；我不处理Windows的fun仪开发。
Microsoft开发人员生态系统
作为Microsoft的现场工程师，我只正式支持Microsoft自己所做的事情。 通过这种方法，其他所有知识都会萎缩。 现在我离开了微软，成为解决方案架构师，填补这一空白变得至关重要。 在Build上，为开发合作伙伴和开发人员提供了完整的解决方案展览，您可以在这里到任何展位询问问题，进行演示。 通过参观这些摊位，我节省了数周的时间。
- 您仍然可以使用SonarQube来管理技术债务（代码质量，当然不是体系结构）
- Kubertenes上有专门的DevOps解决方案，比Azure DevOps易于使用
- 有一些有趣的解决方案，例如Aqua（aquasec）/ Snyk，用于审核docker映像和已经运行的容器的内容。
- 有一些有趣的解决方案可用于监视和跟踪分布式应用程序，这些解决方案比Signalfx等普通的ELK或Azure Monitor（Application Insights + Log Analytics）具有优势
- 我已经对Jetbrains上的R＃和.net上的开发环境保持沉默（我记得R＃，但是没有使用它，因为我写了一点，因此对开发环境的了解不多）。
- 它充满了基于AI / ML /数据等的各种解决方案，但是我并没有太多去做，因为 我没有工业大数据解决方案的实践经验，我将无法评估收益。
公告内容
老实说，就我个人而言，今年的公告（
在这里和
这里 ）并没有伤害我，我也没有特别记得它们。 在量子计算机上，大肆宣传是不错的选择，但这是当今的技术。 并没有真正记住任何其他东西。
后记
实际上，我希望有更多非工业行业的代表，因为 微软长期以来一直在声明，它寻求通过项目而不是ithnikami来帮助企业。 是的，当然有
空中客车公司 ，
宝马 公司的报道……但是我期望更多。
Office365不是我的主题，因此我决定甚至不考虑此问题。
根据我的观察和以前的经验，以上所有内容都是我个人的看法。 我不假装是客观的。 您可以讨论任何论文。