是时候让我飞了……渲染

Gartner 技术成熟度曲线（如下图所示）可应用于技术的大多数方面：

随着新的创新进入各自的周期，预期最终会实现——从而导致一定程度的采用。

每一项创新的目标都是达到生产力的稳定状态，消费者已经确定采用创新的回报远远超过任何已知的风险。

与此同时，生产力的平稳期开始减弱，导致人们远离创新。一个简单的例子是寻呼机（或寻呼机），它在移动电话/设备达到生产力的高峰期之前很常见。

作为技术专家，我们努力提供能够提高生产力水平的特性、框架、产品或服务。这同样适用于我们使用的那些。

最近，我觉得我当前的托管平台的生产力开始下降。事实上，最近的一项公告让我想知道是否该考虑其他选择了。

由于我在使用Render PaaS 方面获得了积极的体验，因此我想看看我可以如何轻松地转换我的一个 Heroku 应用程序、采用 PostgreSQL 并迁移到 Render。我在这个由两部分组成的系列中描述了这段旅程：

• 第 1 部分：我们将专注于迁移我的后端服务（Spring Boot 和 ClearDB MySQL）。
• 第 2 部分：我们将专注于移植和迁移我的前端 Angular 客户端。

为什么我选择渲染

如果您以前从未听说过 Render，请查看我以前的一些出版物：

• 使用 Render PaaS 在 DevOps 上花费零时间

• 完美的云：AWS、GCP 和 Azure 一体化

• 目的驱动的微服务设计

• 在一天内启动您的创业想法

• 我如何使用 Render 轻松扩展我的微服务应用程序

我发现 Render 令人兴奋的是，他们继续攀登启蒙的斜坡，同时积极为认识到生产力高原的采用者提供可靠的解决方案。

正如我在文章中指出的那样，Render 提供了“零 DevOps”承诺。这完全符合我的需求，因为我没有时间专注于 DevOps 任务。

Heroku 平台有几个我不太喜欢的东西：

• 每日重启导致我的一项服务意外停机。

• Heroku 上的入门级（我真正需要的）Postgres 允许每月停机四个小时。

• 从消费者的角度来看，定价水平不能很好地扩展。

从定价的角度来看，在将我的所有应用程序和服务从 Heroku 迁移到 Render 后，我希望看到显着的成本节省。更令人惊奇的是，我以这个价格获得了更好的内存和 CPU，随着我的应用程序占用空间的增长需要线性扩展。

转换单个服务

正如我在上面提到的，这是由两部分组成的系列文章的第一部分，我将在本文中重点介绍服务层。我要转换的服务具有以下属性：

• Spring Boot RESTful API 服务

• Heroku CloudAMQP (RabbitMQ) 消息代理

• Heroku ClearDB (MySQL) 数据库（单模式）

• Okta 集成

在 Render PaaS 方面，新的服务设计将如下所示：

• 渲染 Web 服务托管 Spring Boot RESTful API 服务（通过 Docker）

• 渲染私有服务托管 RabbitMQ 消息代理（通过 Docker）

• 使 Postgres 具有多个模式存在的能力

• Okta 集成

以下是两个生态系统的并排比较：

我对转换的高级攻击计划如下：

准备 Heroku 进行转换

在开始之前，建议将所有现有的 Heroku 服务置于Maintenance Mode 。这将禁止任何消费者访问应用程序或服务。

虽然源代码应该已经备份并存储在基于 git 的存储库中，但最好确保已成功创建数据库备份。

Heroku 服务的转换

从转换的角度来看，我有两个项目要转换：服务本身和 ClearDB (MySQL) 数据库。

我的 Spring Boot RESTful 服务的转换并没有涉及太多工作。事实上，我能够利用我在之前的项目中使用的方法。

对于数据库，我需要从 MySQL 转换为 PostgreSQL。我的目标是使用 Render 的Heroku Migrator轻松地将 Heroku Postgres 迁移到 Render Postgres，但我需要先从 MySQL 转换为 PostgreSQL。

最初，我从pgloader路径开始，这似乎是数据库转换的常用方法。然而，使用我的 M1 芯片 MacBook Pro 导致了一些意想不到的问题。

相反，我选择使用NMIG将 MySQL 转换为 PostgreSQL。有关更多信息，请查看下面的“ 数据库转换的亮点”部分。

在 Render 中创建服务

在转换数据库和在 Docker 中运行的 Spring Boot RESTful 服务之后，下一步是为 Spring Boot RESTful API 服务创建一个渲染 Web 服务。

这就像创建服务、为其命名并在 GitLab 中为我的代码指向适当的存储库一样简单。

由于我还需要 RabbitMQ 服务，因此我按照这些说明创建了一个在 Render 上运行的 RabbitMQ 私有服务。这包括建立少量磁盘存储来保存尚未处理的消息。

最后，我在 Render Dashboard 中为 Spring Boot RESTful API 服务和 RabbitMQ 消息代理创建了必要的环境变量。

初始化和验证服务

下一步是开始我的服务。在它们运行并使用我的 Postman 集合验证 API 后，我更新了我的客户端应用程序以指向新的渲染服务位置。

一切都启动并运行后，我的渲染仪表板如下所示：

下一步

此时剩下的就是删除仍在 Heroku 上运行的数据库，并从 Heroku 生态系统中删除迁移的服务。

使用 Heroku 时，每当我将代码合并到我的服务存储库的 master 分支时，如果我使用GitLab CI/CD 将代码部署到我的源存储库中的 Heroku，代码就会自动部署。

但是，无需使用 Render 将代码添加到源文件存储库。我只需要在 Render Dashboard 中为服务指定 Build & Deploy Branch：

我喜欢零 DevOps 承诺。

数据库转换的亮点

按照上面的步骤，从 Heroku 到 Render 的转换是顺利和成功的。对我来说最大的挑战是数据的转换。在高层次上，这主要归结为从我的 MacBook Pro 终端执行的一系列命令。

首先，我通过 Docker 启动了一个本地 Postgres 实例：

 docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres

接下来，我使用以下命令（或 pgAdmin）创建了一个名为“example”的数据库：

 createdb example

为了将我在 Heroku 上运行的 ClearDB (MYSQL) 实例转换为我在本地运行的示例 Postgres 数据库，我使用了NMIG ，这是一个基于 Node.js 的数据库转换实用程序。

安装 NMIG 后，我使用数据库端点信息和凭据设置了 config.json 文件，然后运行：

 /path/to/nmig$ npm start

接下来，我使用以下命令将数据备份到文件中：

 pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump

我没有经历在 AWS 中创建签名 URL 的麻烦，而是使用pgAdmin客户端将备份导入到 Heroku 上新创建的 Postgres 实例中。

在运行 Postgres 实例并验证数据后，我在 Render PaaS 上创建了一个新的 Postgres 数据库。然后我所要做的就是发出以下命令：

 pg_restore --verbose --no-acl --no-owner -d postgres://username:[email protected]/example example.dump

沿途的经验教训

回顾我从 Heroku 到 Render 的转变，以下是我在此过程中学到的一些经验教训：

• 我在 Postgres 数据库更新日期/时间值以包括 DST 偏移量时遇到了一个小问题。这可能是我最初的数据库设计的问题，但我想传递它。在我的例子中，受影响的列仅用于日期值，这对我来说没有改变。

• 我在我的一个表中包含了一个名为 END 的数据库列，这在 Postgres 或 Hibernate 试图返回本机查询时导致了问题。该服务看到了 END 列名称并将其作为 SQL 关键字注入。我只是简单地重命名了该列来解决这个问题，我一开始就应该知道不要这样做。

• 使用 Render，我需要将 RabbitMQ 服务设为私有服务，因为 Web 服务选项不会公开预期的端口。然而，通过这种方法，我失去了访问 RabbitMQ 管理界面的能力，因为私有服务没有暴露在外部。看起来 Render 计划解决此功能请求。

总而言之，这些小障碍不足以影响我迁移到 Render 的决定。

结论

Gartner 的生产力高原最重要的方面是提供产品、框架或服务，让消费者茁壮成长并实现他们的目标。从隐喻的意义上讲，生产力的平稳期并不是为了浮华或时尚。

当我与 Render 的开发倡导者 Ed 分享这个结论时，他的回应是我想分享的：

“Render 非常明确地不想变得‘时尚’。我们正努力做到出人意料和可靠。”

Ed 的回答引起了我的强烈共鸣，让我想起了有一次我的前同事告诉我我的代码对他来说“无聊”。事实证明，他的评论是我能收到的最大赞美。您可以在此处阅读更多内容。

在技术的任何方面，选择哪个供应商的决定都应始终与您的技术地位相匹配。如果您不确定，Gartner 炒作周期是一个很好的参考点，您可以在此处开始订阅他们的服务。

我一直专注于以下使命宣言，我认为它适用于任何 IT 专业人员：

“将时间集中在提供可扩展知识产权价值的特性/功能上。为其他一切利用框架、产品和服务。”

- J. Vester

当我审视 Render PaaS 生态系统时，我看到一个解决方案既符合我的使命宣言，又符合我的炒作周期偏好。

让事情变得更好的是，我完全希望看到我的个人自付费用节省 44%——甚至更多，因为我的服务需要垂直扩展。

对于那些考虑托管解决方案的人，我建议将 Render 添加到提供商列表中以供审查和分析。您可以通过此链接免费开始使用。

这个系列的第二部分将是令人兴奋的。我将演示如何摆脱为用 Angular 编写的静态客户端付费，并使用 Vue 或 Svelte 来利用 Render 的免费静态站点服务。我会选择哪个框架……为什么？

祝你有美好的一天！