Serverless最佳实践
原文： https://charity.wtf/2016/05/31 ... less/
【编者的话：本文是作者上周参加serverless会议后写的两篇博文之一，如果读者对serverless的含义或者#NoOps或者其它之类感兴趣， 可以参考我之前的几篇博文，我在其中讨论了现代运维 。读完之后，尽可以对我的观点进行吐槽。】
我的基本观点就是：在我们将越来越多核心功能外包的今天，软件工程师应该更多将精力放在哪些方面？
如果关心运行高质量的服务或者产品，或者提供客户满意的服务级别，那么无论软件与裸机之间有多少抽象层，都应该关注操作层面，例如设计、高可用、监控和可调试性。
如果选择成为运营商，那么绝对不应该指手画脚，事后诸葛亮般指责都是别人的错误；如何选择是自己的自由，但是绝对不该在客户面前指责是谁的问题。
那么在这么多需要关心的角度中，我们从哪个开始呢？
我们的任务是什么？我们有什么独特的地方？
首要问题一直会是：我们的目的或者任务是什么？任务肯定不是写软件，而是交付客户花钱请你要解决问题的方案，而我们是通过软件去实现的，（其实代码是一种负债，尽可能少写代码。是不是听起来更像是为#serverless辩护？:) )。
其次，我们有什么独特的地方？我们核心竞争力是什么？
这些都是外包之前需要仔细考虑的问题。
实际上
我们外包的是劳力而不是“操心”，只有我们自己需要仔细考虑自己的核心价值。
如果我们是一个初始公司，最好是使用5-20个SaaS产品，这样会比我们花精力自己做更有效，我们也可以将精力更多地投入到核心价值。
好。#
但是我们仍然需要考虑可靠性，安全模型，存储模型，查询性能，服务之间如何通讯，如何查错，事情出问题时如何重新部署等等。我们尽管不亲自运营硬件，仍然需要考虑这些应用层次关键问题。
例如，以AWS Lambda为例，这是一个从各种角度考虑都不错的服务，是未来发展的趋势。即使如此，如何为大量应用查错也是一件让经常让客户很恼怒和挑战的事情。
** 重要提示：我讨论的是生产系统。Parse， Heroku, Lambda,等都提供非常棒的原型，可以给我们足够的支持。早期公司更应该考虑弹性和快速开发，而不是可靠性。 ”
聚焦与关键路径
用户并不关心我们采用的jenkins是否出问题了，事实上他们并不关心你需要关注的事情。他们更关心需要我们产品无法解决的功能，也就是说我们更需要关注外运营商的行为和为题，这些都会被用户看到。
如果可能尽量多问一些问题，（AWS经常不会告诉太多，但是小运行商会告诉很多）。尽量问清楚他们的多租户模式（共享硬件还是独享？），典型性能变化情况（最好自己测试一下，不要相信他们提供的数据），以及底层存储系统。
从用户角度考虑如何提供更好的弹性，这些并不是运营商提供的。如果是移动应用，我们能提供合理的线下经验吗？例如Parse可以提供很多吸引人的APIs，当出错时可以回滚以及尝试重新保存。
如果一个运营商出现问题，我们能切换到其它运营商吗？在我们公司目前人力物力状况下有能力考虑这个吗？
是否可以接受被锁定在一个运营商，如果不得不转到另外一家呢？或者如果选中的运营商关门了呢？
折衷
外包很不错，我尽我所能做过。我曾经帮着创建外包标准的服务，我认为这会是未来。基本上就是“坚果壳中的资本主义”：增加复杂性-》增加专业性-》付钱给可以做更好的人-》双赢。
但是也有折衷，我们面对事实吧。
服务本身是聪明的，会对如何使用提出很多限制，因此更像是基于可靠性目标提供服务。当用户有所倾向时会产生偏差和不可靠。如果一定要在我们和众多客户之间做出选择，那么毫无疑问每次都一定是客户会赢。
限制也会慢慢改变，尤其是初始服务。我们可能有可能为某个功能很绝望，但却不会去重建它。（这也是为什么我在kafka和Kinesis之间选用前者的原因）。
如果我们想自己开始创业，我们需要更多和更深入思考和反省我们的愿景，因为面对不明朗的未来，不可能像调试系统一样登陆，使用strace或者gdb或者tail来进行排错。
最佳情况是，为了换取比我们更强的某个领域专家而不得不放弃某些控制和质量，有可能会更加有利一些。一般更差场景，结果会更不可靠，而且，更加难懂，而且，我们不能说是不是有所提高，因为老实说，为大众开发某个服务比为某个开发服务更加困难。
状态服务
我们来简单说说状态。
无服务器乌托邦忽略了状态服务的问题，更多地采用 DynamoDB, 或者 Firebase, 或者 RDS 或者Aurora 等实现.
这彻头彻尾是在胡扯，我想说世界上没有不需要了解存储系统如何工作的特例。请求响应会变得很慢，我们不得不考虑为什么，而且需要去修复它。而且很有可能会碰到某个运转稳定的应用突然变得有很大延迟。。
¯_(ツ)_/¯
底层运行的硬件会降级（不要忘了底层总会有经过抽象化之后的硬件层）。运营商总会有各种奇怪的问题，他们可能会比我们运营的好，但是却不会给我们满意的答复因为成千上万的用户都在抱怨这事儿。
跟多了解存储系统，我们系统就会运行更稳定，我们也就会越幸福。
结论
这些趋势都是不可逆转的，对每个人来说都是好消息。
运维工程师需啊哟掌握更多技术栈，最好的工程师被组织起来解决各种问题（以前他们会为不同公司工作解决不同问题，而现在他们通过internet大规模提供SaaS解决方案来解决以前碰到的问题。只需要看看过去5-6年发展起来的运维软件就知道这种趋势）。
这也就意味着运维团队闭门为软件开发部门提供缓冲的年代变成了开门主动迎接挑战模式。
人们已经感觉到因为软件开发周期大大加快，软件质量有明显提升；也就是说提供用户与开发端到端的解决方案。重心已经偏向自己做开发的运维团队。
这种改变真棒，我们可以从大公司，如Google, AWS, Pagerduty, Pingdom, Heroku, 等获得帮助而不用真正雇佣他们；因为大牛总是稀缺的，即使有这样的机会，我们也不一定能够雇的起。
事情另一面在于应用工程师需要更多考虑传统运维所要考虑的可靠性，架构，检测，可视化，安全和存储等方面的问题。仔细考虑自己的独特优势，然后在这方面做精。
没人可以在实现目标方面替代我们自己，做好自己能做的。
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
