开发人员会服务器问题排查嘛_无服务器开发人员经验

开发人员会服务器问题排查嘛

TLDR: Serverless is an infrastructure play focused on operations more than the development side of the house. Given developer dollars are some of the most expensive, it is important to identify the boundary of serverless tools in our architecture and structure our architecture layers to minimize disruption to development flow. Instead of using FAAS as compute, we are focusing on FAAS as infrastructure glue.

TLDR：无服务器是基础架构，而不是内部开发侧重于操作。 鉴于开发人员的资金是最昂贵的，因此确定我们架构中无服务器工具的边界并构造架构层以最大程度地减少对开发流程的干扰非常重要。 我们没有将FAAS用作计算，而是将FAAS用作基础架构粘合剂。

The serverless paradigm has been step-change in how we build software. It checks a lot of boxes in the “issues that need resolving” column of software development.

无服务器模式已经在我们构建软件的方式上发生了变化。 它在软件开发的“需要解决的问题”列中选中了很多复选框。

However, for all of its benefits, serverless is first and foremost an infrastructure play. It leans more towards the operations side of the house than the development side. All this is to say, that the serverless developer experience is decidedly sub-par.

但是，尽管无服务器具有所有优点，但它首先是基础架构。 它比房屋开发侧更偏向房屋的运营侧。 这就是说，无服务器开发人员的经验绝对低于标准。

Let’s think for a moment about how we cook food, normal cooking. And now think about a hypothetical, presumably crazy way to cook food (the Guy Fieri method).

让我们考虑一下我们如何烹饪食物，正常烹饪。 现在，考虑一种假设的，可能是疯狂的烹饪方法(盖伊·费耶里的方法)。

Just riffing on Guy

只是对盖伊

Normally, we would isolate the task of cooking to the inner loop where we have faster feedback cycles and go to the outer loop with the longer feedback cycles only when we feel the dish is in a somewhat ready shape.

通常，我们会将烹饪任务隔离到反馈速度更快的内循环中，而只有当我们觉得菜肴的形状已经准备就绪时，才采用较长的反馈循环进入外循环中。

In the Guy Fieri method, however, we break out of the inner loop midstream to first plate the dish and then come back to the inner loop for tasting it and continuing. Insanity!

但是，在盖伊·费里(Guy Fieri)方法中，我们从内圈中游突围而出，先将盘子倒盘，然后回到内圈品尝并继续。 疯狂！

This is exactly the developer experience we deal with when working in the serverless paradigm.

这正是我们在无服务器范例中工作时所面对的开发人员经验。

The serverless movement at its core is an infrastructure/operations play. At the flick of a switch, we can get all the tools and capacity we want (and even the capacity we don’t know we want yet), on-demand, at a fraction of the cost it would take running infrastructure on servers.

无服务器运动的核心是基础架构/运营。 一键切换，我们就可以按需获得所需的所有工具和容量(甚至是我们尚不知道的容量)，而所需的成本只是在服务器上运行基础架构的一小部分。

But it comes at a cost. We have,

但这是有代价的。 我们有，

• Limited support for offline development
  对离线开发的支持有限
• Hard to manage packaging
  难以管理包装
• Bad remote debugging tools
  不良的远程调试工具
• Long deploy times
  部署时间长
• Hard to co-ordinate under active development, especially during simultaneous development between coupled components (most software development)
  在主动开发下很难协调，尤其是在耦合组件之间的同时开发期间(大多数软件开发)
• Running code on a platform we don’t control I.e. AWS lambda and running into compatibility issues with libraries such as lxml on AWS Lambda
  在我们无法控制的平台上运行代码，即AWS Lambda，并遇到与AWS Lambda上的lxml等库的兼容性问题

At Team Marker, we have been experimenting with a few different options to ease some of the issues with development flow. Primarily, architecting FAAS as infrastructure glue. To achieve this, we primarily keep development offline-focused and then use FAAS as an integration layer between our cloud infrastructure. Proper packaging and architecture has helped to remove most of the pain points (an update explaining the various approaches we have used is coming up).

在Team Marker，我们一直在尝试一些不同的选项来缓解开发流程中的某些问题。 首先，将FAAS设计为基础架构粘合剂。 为了实现这一目标，我们首先将开发重点放在离线上，然后将FAAS用作我们云基础架构之间的集成层。 正确的包装和体系结构有助于消除大多数难题(即将发布解释我们所使用的各种方法的更新)。

However, the issues around offline development and long deploy times remain.

但是，有关脱机开发和长时间部署的问题仍然存在。

翻译自: https://medium.com/the-innovation/the-serverless-development-experience-ed49b81eda1b

开发人员会服务器问题排查嘛