Crafting a Digital Thread in an Aerospace & Defense DevSecOps Architecture with Mercury Systems
（欢快的音乐） <v ->Gartner 指出，</v> 预计到 2024 年，四分之三的大型企业都将使用 至少四种低代码开发工具。 大家好，我是阿努·米沙拉，今天将与大家探讨水星系统公司 云原生应用程序， 它是我们 DevSecOps 计划的一部分。 在开发数字贸易路线图的过程中， 我们意识到亟待部署一个强有力的平台， 用于处理我们旗下产品相关的 所有数据和业务流程。 同时我们也认为有必要 将所有这些不同的技术整合到一起， 并且有必要设置一个通用界面， 将所有产品知识链接在一起。 我们今天的话题将包括我们如何 意识到对低代码平台的需求， 我们为何会选择 Mendix， 我们如何将安全功能嵌入到应用程序中， 从而加快了这款产品的开发步伐。 以及我们还确保了此数字化转型的 每个阶段都有驱动价值， 最后我们还将探讨我们当前的执行战略。 在开始详细演示之前， 我想请诸位先观看一个短视频， 了解一下水星系统公司的概况。 （快节奏音乐） <v Narrator>在水星系统公司，</v> 我们致力于开发各种关键任务型技术， 为全人类打造一个 安全无忧的世界。 我们是这样做的。 我们开发各种最精密、最尖端、 适用于广大客户的硅谷技术， 并对这些技术进行 无缝定制， 打造当今世界最先进的 航空航天和国防应用程序。 我们提供性能强大、值得信赖、 安全的处理解决方案， 专门应用于在各种 极端恶劣的环境下、 在最严苛的条件下、 在地球最偏远的位置和太空中 执行绝对精准的操作任务。 我们参与了 300 多种航空航天防御、 安全和情报等改造计划， 采用历经验证、过硬的商业技术， 确保性能完美、可靠、可预测， 同时不忘我们的初心， 为全人类打造一个更美好的世界。 因为最终，我们的工作不局限于 航空航天和国防领域， 我们在为全人类而努力工作。 （快节奏音乐） <v ->数字主线有很多分支类别，</v> 在计划中跨越多种 职能部门和角色， 我们如何将所有不同学科专业的联系起来， 如何对贯穿生命周期不同阶段的 数据流动进行视觉呈现。 随着模型设计的深入以及对设计和分析的重点关注， 我们应如何在不同的阶段 保持信息的一致性。 现在大家从这张示意图中可以看到， 上面有很多不同的流程， 那都是真实产品或组件必须经过的环节。 此外，我们还需要对模型进行， 每天可能要进行上万次的模拟仿真， 需要执行拓扑优化、 处理本地电流， 电气 CAD 图纸要通过多次审核等。 我们还需要在产品整个生命 周期内发布相关流程。 现在，我们还需要做出选择， 到底应从哪里入手？ 这是一项非常复杂的挑战。 在开发之旅的最初阶段， 我们重点关注右上象限，即工程世界； 然后进行各种连接， 我们应如何将众多的点连接到一起， 然后在 PLM 系统上构建各种自定义层， 实现数据所有权共享。 我们应将自定义工作流程层构建在规划工具（例如 Jira）上 ， 还是应将自定义层 构建在 PDM 系统或系统工程工具（例如 Jama）上。 由于我们想打造的是 一套基于模型的系统工程， 这个甚至需要将所有 仿真工具、PLM 系统 和 CAD 系统连接在一起。 另外，我们会对这些不同系统 实际投入多少资金和时间。 还有，某些用户可能不会使用或无权 访问这里所列的其他一些工具。 这里涉及了众多应用程序 和不同的用户集。 大家知道，机械制造的关注重心是构建 构建立一个 CAD 平台架构，对吧。 因此，我们需要采用简便快捷的平台产品。 最后很明显，我们需要一个低代码平台。 明确我们的需求后， 接下来就要选择哪种平台最适合我们？ 最终我们选择了 Mendix， 因为它拥有强大的集成性能， 特别是在工程系统方面表现突出。 它内置了 DevOps 功能， 这个我后续会深入探讨， 这样，我们只需极少量培训， 或者无需培训， 即可快速完成这些概念验证。 此外，它还具有路线图 CAD 可视化功能， 因为我们要确保它可供 普通用户访问使用， 并且易于可视化， 可以随时掌握项目主线的进展情况。 所以我们选择了 Kafka， 它符合我们的愿景和路线图规划。 它实际上也完全符合 Mendix 的数据中心路线图要求。 因为它们也会使用 Kafka。 它还支持云原生环境， 我们最终达成了交易， 因为它符合我们的 DevSecOps 计划愿景。 综上所述，我们的关注重点是流程开发， 其次才是产品效用， 然后是开发方面的挑战。 从一开始，我们就计划将 Mendix 作为 DevSecOps 系统进行本地部署。 因为对于国防和航空航天行业来说， 安全性和合规性是头等重要的大事。 我们的管道必须设置漏洞扫描， 查找开源合规方面的弱项， 并持续监控 Kubernetes 集群的安全性。 我们的 Mendix 必须采用容器化架构， 作为 Pod 部署在 Kubernetes 集群中。 至于执行策略， 我们应采用 Mendix 经过反复验证的启动架构 和规模化扩展策略。 我们只需对其稍作调整，使其符合我们的 DevSecOps 计划即可。 谈到项目选择， 即应该从何处入手，这确是个不小的挑战， 我们可以挑选一个影响力大 但复杂度低的项目入手， 这样即可在较短的时间内， 证明我们的初步成功。 我们挑选了一家合作伙伴，他们拥有 经 Mendix 认证的开发人员且具有 DevOps 管道开发技能。 接下来的关键是尝试进行第一款应用程序开发试验。 我们首先必须建立一个跨部门、 可以推动快速开发的机制。 于是我们用了一周时间创建并成功推出了 一套技能集矩阵工具。 然后又用了两周时间， 就成功搞出了成果。 现在再回头看一下我们的架构， 如何从初次成功再到下一个成功， 我们必须要实现一次大的跨跃。 于是我们选择了一个影响力大、复杂度高的项目， 来展示我们的首次规模化应用。 因此，我们在本地部署了 CI CD 管道， 并开启了 Mendix 的全部功能。 同时，我们还必须提升内部人员的开发技能， 因为这款应用程序成功上线后， 将需要与多个 工程系统进行集成。 我们需要确保在部署完成后， 立刻实现 DevSecOps 的 持续安全监控功能。 要继续连接更多的系统， 我们下一步就是要进行规模化扩展， 这样做是为了确保 安全策略得到持续更新， 然后确定产品生命周期 后续步骤所需的用户成功故事， 正如我们在数字主程中讨论的那样。 接下来，我们需要做个决定， 一旦开始将用户成功故事付诸行动， 我们即可开始蓄势发力。 所以未来，一旦开始规模化扩展， 我们就能充分运用所有这些信息， 在此平台上构建诸如机器学习、 物联网、预测分析等等所有功能。 接下来，我的同事， 来自服务合作伙伴 CIGNEX Datamatics 的哈里斯， 将为您详细介绍我们的架构。 <v ->谢谢阿努，大家好，</v> 我叫哈里斯·拉马钱德兰， 来自 CIGNEX Datamatics， 是 CIGNEX 的联合创始人兼首席执行官。 我们公司的业务范围包括 开源服务和解决方案， 迄今已有二十年历史。 我们在开源初期阶段， 主要做的事情是 内容管理解决方案和门户网站 以及基于 Java 的框架。 但现在，您会发现随着开源 系统不断进化演变， 它已形成了云原生架构， 即充满活力的 Kubernetes 生态系统和 CNCF。 基本上来说，众多的 DevOps 工具 现在都采用云原生架构。 这是我们公司的核心领域之一。 此外，我们还使用 Mendix 等低代码平台， 做了大量应用程序合理化的工作 以及大量 RPA 和应用程序 自动化的工作， 帮助企业实现 数字化转型。 今天我们想着重谈一谈 我们在水星系统公司所开展的工作。 关于水星公司的项目， 我想主要谈以下三个方面内容。 第一，关于解决方案的要求。 第二，简要介绍一下 我们的解决方案架构 以及整个计划的实施情况。 最后，我想介绍一下部分核心租户， 也正是在此基础上， 我们才将相关解决方案的要求与架构 完美结合，最后完成了项目计划。 首先来谈谈解决方案和相关需求， 基本上，水星公司的主要用例都是 那种综合门户网站。 也就是说这种门户网站， 工程师们需要每天上来 查找其日常工作 所需的一切信息。 也就是工程师仪表板，您知道， 这就是我们在水星公司使用 Mendix 打造的目标应用。 因此，这里需要我们提供支持的 部分核心业务应用程序和流程 就是企业变更管理、零部件请求、 合规性检查以及零部件搜索等。 这些都是工程师们需要现代应用程序 和现代用户界面提供的核心用例， 是帮助他们高效完成 日常工作的必备工具。 稍后我会继续对 该应用程序的 部分功能进行展开介绍。 为了提供所需的支持， 除了采用 Mendix 搭建应用环境之外， 我们还需要稳固强大的基础设施， 用于企业架构 和企业集成。 于是我们提出了事件驱动型架构方案， 使用 Kafka 作为应用程序环境， 用于实现 Mendix 与众多记录系统的集成。 在这里，我们的记录系统包括： 用于产品线管理的 PLM 系统， 用于产品数据管理 PDM 系统， 和其他应用程序，其中包括 用于未来阶段的研究应用环境， 例如 ERP、MRP 和 MAS 等应用程序平台。 这些都是常用的工程类应用程序， 也是许多和水星系统同类的公司 所使用的记录系统。 我们在这里实施的另一项架构 是打造高性能的数据层， 用于将我们后端系统中的大型数据集 集成到 Mendix 应用程序层中。 所以我们选择了 MongoDB 来管理大型数据集，例如零件号。 因为我们有数以万计、 之前已创建的零部件， 以及需要在其他系统中 例如在变更请求中引用的零部件。 这就是我们所说的采用 MongoDB 构建一个数据层的作用， 我们还构建了相关企业事件系统， 用于对一个或多个记录系统进行修改， 并将这些修改情况传输到 我们的 NoSQL 数据库中。 最后，我想谈一下有关 应用程序的功能和安全性， 以及我们在构建应用程序的过程中 所遇到的核心挑战， 还有 Mendix 是如何帮助我们实现这些要求的。 作为企业， 我们更多地是采用基于项目的安全措施， 也就是说，每个项目都会附带 一个或多个业务流程。 在这种情况下，这个项目会被分配 多个不同角色。 例如项目经理、设计工程师、 电气工程负责人、项目群经理 和文档管理， 所有这些不同角色 都在项目层面建立。 而这一切在我们的环境中也都有创建， 让大家可以实际查看 其中的一些事务。 在网络中，它会转化为 Mendix 中的每项事务， 这些事务不仅附带着自己的工作流 还附带着其安全环境。 这样就非常容易在 Mendix 中实现。 这个安全层位于最顶层， 您平常执行的其他操作都位于下层， 例如身份验证、权限管理， 以及现今 Mendix 环境中的 一切其他要素。 这就是打造如此独特 应用程序环境的原因所在。 我们当时在寻找一个能够 真正帮助我们实现全新架构的平台， 而不是基于规则设置 一套固定的权限集， 我们不需要那种用于 记录层面的东西， 所以才最后选用了 Mendix 平台。 接下来我想谈谈解决方案架构 和云原生部署。 这里我想先回顾一下 这个项目所涉及的 部分核心架构租户的情况。 从一开始，我们就很清楚要 构建这样一种云原生架构。 对我们而言，云原生意味着所有一切 都要采用容器化管理。 Docker 是容器化环境， 我们广泛使用 Docker Buildpack 将 Mendix 应用程序构建为容器， 然后将其部署到水星公司的 生产环境中。 这里不只是 Mendix 做成了容器化应用， 所有我提到过的其他应用程序层， 例如 Kafka 或是 Mendix 使用的数据库， 还有我提到的用于 大型数据集管理的 MongoDB， 所有这些都是采用 容器化的形式部署 在同一编排环境中， 即我们这里的 Kubernetes， 整个架构都致力于确保 不会发生任何的架构故障， 并且我们还可以根据企业的功能范围 以及特定用例的规模化需求 进行相应的规模化扩展。 当然，要完成这一架构部署， 我们还需要其他一些 技术或产品。 其中一项是 Ingress 控制器， 因为您需要将部分容器 提供给安全云用户使用。 在我今天谈论的这些内容里， 并非所有访问都必须通过 Mendix 抱歉，是水星公司的受限应用程序环境。 另外还有一个次级用例， 我们构建了部分数据管道和 API 专门用于将不同的企业系统 集成到这个环境和这个集群中。 为便于将这些 API 提供给外界使用， 我们现在还搭建了一个 API 网关。 接下来再谈谈 CI CD 和构建管道， 这也是整个项目不可或缺的部分， 目的是方便大家操作 这个采用了云原生部署 架构的生产环境。 正如我之前说过的， 我们广泛使用了 Docker Buildpack， 而这些都是离线操作，您在这里看到的一切， 包括 CI CD 管道， 都是在安全环境中运行的， 也就是说要通过两道防火墙。 这里的所有实时连接 都不通过互联网访问。 所以我们的系统属于离线系统， 采用 Jenkins 运行这些构建管道。 我们还使用 WhiteSource 这样的工具执行安全扫描， 然后将这些容器发布到 专用注册表， 即我们自己的 JFrog Artifactory 存储库中。 这就是我们的 Kubernetes 连接集群， 您可以看到所有这些 应用程序环境在部署 或是规模化扩展时的 Docker 镜像。 此外，我们还需要 与目录服务或企业 LDAP 进行集成，用于身份验证。 我们在集群中还内置了 多种监视器和探头， 用于监视应用程序的运行状况， 确保大家随时掌控 所有这些应用程序环境。 此外，我们还广泛使用相关产品 来管理我们的配置映射， 以及与数据库密码等 类似的密钥。 以上就是我们在水星公司所构建的 解决方案架构以及采用云原生架构 部署的 Kubernetes 集群。 今天，这些架构都成功在 Amazon 平台 即 AWS GovCloud 上运行， Kubernetes 集群则在 Amazon EKS 上运行， 另外还在其他部分项目中使用 ECR 作为容器注册表。 以上就是我要介绍的解决方案架构的全部内容， 如果哪位还想进一步探讨 任何解决方案，请在线下联系我。 我们很乐意分享相关经验 以及有关大家正在使用的 这些架构模式的 视角观点。 对我们来说，目前尚处于初级阶段， 我们确实通过相关管道看到 越来越多的应用程序不断涌现。 接下来我把时间交还给阿努， 请他讲下云原生架构的愿景 和未来的发展路线图。 谢谢！ <v ->谢谢哈里斯。</v> 现在我们来谈谈 接下来的发展， 即未来的发展方向。 我们需要进一步拓展应用范围， 超越现有的工程工具和应用程序。 我们需要完成已经开始做的 自动化测试套件， 哈里斯也提到如何利用 Selenium 自动化完成测试周期。 我们还需要围绕现有的 全新低代码平台制定相关标准， 并且要超越现有的 业务流程和微流程。 我们需要进一步探索 CAD 可视化， 以及即将推出的数据中心功能。 我们还需要审视相关的指标和报告工具， 并围绕这些工具所采集的数据 开发更多的指标和工具。 在我们利用这些数字连接 和流程构建出实物产品后， 我们就可以充分利用这些信息， 并应用机器学习服务 来完善我们的产品。 这里我要感谢 Mendix，特别要感谢 奥兹、卡拉和琳达给我提供这样好的机会 与各位分享我们的经验和体会。 如果这是现场直播 或 Mendix 分组讨论就好了， 那样我们就可以分享更多东西， 就像面对面交谈一样。 如果需要了解更多详细信息， 请随时联系我本人或哈里斯。 谢谢！
2021-02-19 18:55
