在9月28日举行的
RubyRussia大会
上， 尼古拉· 斯维奇科夫（ Nikolai Sverchkov）将作一个演讲，介绍Serverless是Ruby Future。
伊万·索洛维约夫（Ivan Solovyov）在采访中讨论了为什么这种趋势很有趣，以及为什么摩擦论者应该注意这一趋势。
告诉我你是怎么去Ruby的？他开始在大学编程。 所有练习都是在C ++中进行的，但是我在Ruby中完成了期末论文和论文。 为什么选择Ruby，我不确定，可能是因为当时的语言是在大肆宣传之后。 在Ruby大学，没有人知道，更没有教授。 但是毕业后，我想用Java编写。 然后在我看来Java是特殊的，最酷的开发人员，是一种更高等级的程序员，我想成为其中的一员。 我的第一次工作面试是在Java初级中进行的，但我成功失败了。 但是他能够进入需要Ruby的公司。 也许是最好的！ 仅仅两年就搬到了Elixir。 现在，我在Evil Martians工作，从事后端工作。
您的无服务器报告。 您是如何开始朝这个方向努力的？他开始在业余时间学习。 我有一个真实的但与主要工作任务无关的东西。 然后，他开始在公司的项目中使用无服务器。 进入门槛相当低，我认为它仅略高于Heroku。 写你的第一个“你好，世界！” 这将非常简单-亚马逊上有很多文章，教程和极其丰富的文档。 然后，当然会有困难。 有陷阱，我将在报告中讨论其中的一些陷阱。
初学者应该投入无服务器并在生产中使用它吗？我认为是！ 但是无需急于使用无服务器来实现一切。 首先，您可以查看您的应用程序并在其中找到一小部分业务逻辑，您可以将其放入单独的服务中。 如果此新的微服务具有简单的通信接口，那么您将有99％的概率可以使用相同的AWS Lambda来实现它。 理想情况下，如果这是无状态的业务逻辑，那么您不必考虑如何保存结果，而不必考虑执行lambda函数的工件。 例如，发送一封信可能是一个很好的首要任务。 在我的报告中，我将分别提出无服务器计算模型最适合哪些任务的问题。
主要建议是将业务逻辑代码与lambda分开。 这是痛苦的熟悉规则“薄控制器，厚模型”的变体。 首先，以这种方式进行测试将更加容易。 其次，如果在此过程中发现无服务器不适合您的任务，则可以轻松地迁移到经过验证的解决方案，例如，用常规Web服务器替换无服务器输入层。 在这方面，非常好的
喷气机 。 这是一个Ruby Serverless框架，可让您编写一个可以直接部署到AWS Lambda和常规Amazon EC2实例的应用程序。
告诉我更多有关这个Ruby框架的信息吗？喷气机就是其中一种。 尽管存在针对特定语言量身定制的其他无服务器框架，但Jets是功能最强大的。 现在，他在大师中有2500多个提交。 该框架为Ruby开发人员使用了许多熟悉的约定，例如“ Serverless上的Ruby on Rails”。 但这有其缺点。 由于使用无服务器计算模型需要花费代码的执行时间，因此从单词的字面意义上来说，初始化和加载大量繁重的依赖项的开销很大。 在我的报告中还将对此主题进行时间披露。
哪些平台现在最适合无服务器，它们之间有什么区别，哪个更好选择？ 据我了解，由于您大多数时候都在谈论它，所以您现在沉迷于Amazon Web Services。您问为什么我在谈话中经常使用“ lambda”一词？ 我认为这个故事就像是凯驰（Karcher）或施乐（Xerox）。 有些品牌的名字习惯上称整个产品为小众。 2014年，亚马逊率先提供了对无服务器计算模型-AWS Lambda的公共访问。 其他所有人：具有Azure功能的Microsoft，具有Cloud功能的Google，具有IBM Cloud Functions的IBM在思想上仍在追赶。 尽管无服务器市场正在蓬勃发展，但AWS的服务价格通常高于竞争对手。 因此，诸如
Google Cloud Run之类的新版本可以使游戏一夜之间转变。 如果我们对平台比较进行更详细的分析，那么我建议您观看
DUMP 2019大会DataArt的Ruslan Serkin的
视频 。
您如何看待无服务器的发展方向？哦，这是我报告中最有趣的部分！ 我可以没有剧透-快听！ 相反，我可以谈论无用和生产。 今年4月，我参加了在明斯克举行的RubyConfBy会议，同一位喷气机的作者在会上讲话。 在随后的聚会上，我们讨论了无服务器开发以及为什么，如果有主要行业参与者的支持，我们看不到lambda函数的大量分布。 该模型的优点是显而易见的，生态系统是透明的，但是IT社区对此没有广泛的信任。 结果，我们得出的结论是，现在无服务器是一种影子播放器，而且这种情况在某种程度上让人想起了一次与Docker一起使用的情况。 长期以来，人们一直认为生产中的Docker会自杀。 现在我们看到容器化是软件分发的主要工具。 我认为，未来，无服务器也会有同样的情况。 越来越多的人会相信他。
无服务器会杀死独石吗？这个问题可以改写为“微服务架构会杀死单块吗？” 因为无服务器是理想的微服务器-它很小，所以它是无状态的，并且具有用于与外界通信的最小接口。 就像微服务不会杀死整体一样，lambda也不能杀死整体。 这三种体系结构都有特定的任务范围，非常适合它们。 反之亦然-例如，有些任务不适合使用无服务器。 在我的报告中查找详细信息。
如何处理供应商锁定？ 例如，您为Amazon开发了一个lambda，但决定迁移到Google。如果您不使用某种框架（例如，
无服务器） ，则在平台之间进行迁移将很痛苦，该框架通过云提供程序提供了抽象API，并允许您在Amazon和Google中部署相同的功能。 如果您粗略地说，用手做所有事情，那么是的，这会有些痛苦。
使用代码时如何处理常见的lambda？ 例如，一些通用组件，一些功利功能等等。在此主题上仍然没有最佳实践。 而且问题可以在“如何在微服务之间弄乱通用代码？”中重新表述，因为含义相同。 当您将重用逻辑放在共享中的某个位置，并在函数本身中将其连接时，有一个选项。 例如，这种方法可以很好地与Go一起使用，其中您获得的输出是一个可执行文件。 另一个选择是摆脱组件连接并允许重复。 可能值得一试，看看最有效的方法。 我唯一可以建议的是不要尝试使lambda函数通用。 在某些时候，您可能会觉得一个uber函数将是代码重复问题的完美解决方案。 但是随着时间的流逝，您将意识到这是通往无处可去的道路。 您将获得某个“无服务器的整体版本”，其中包含第一和第二体系结构的所有问题。
关于RubyRussia的报告之后，我们将更详细地讨论！来吧，您仍然可以
注册 ，会议将在9月28日下周六举行。
不仅会有报告，而且还有最好的公司的代表：
主办单位
-Evrone一般合伙人
-Toptal金牌合作伙伴
-Gett银牌合作伙伴
-Valarm ，
JetBrains ，
Bookmate和
Cashwagon铜牌合作伙伴
-InSales