事无定势，因时制宜。
运维工作这几年，见过有devops对terraform嗤之以鼻的，也见过对其奉为圭臬的。
诚然脱离场景讨论一个IaC工具本身是没有意义的。这就如同了每个人自顾自的描述自己的感受，旁人是无法感同身受的。
但最近看到一个reddit上clickops vs IaC的讨论，我还是想浅谈下我现在对terraform是否对运维有用的看法。
最初接触terrform是19年一个aws的项目，第一次发现云上的基础设施资源可以像代码声明一样去管理，确实很方便。像打开了新世界的大门。
虽然那会主要还是开发，但后边一路基础设施也都习惯了用terraform管理，直到如今做运维了，逐渐一年年也接触过了多个诸如aliyun，gcp，azure云的IaC.
先不论terraform的种种在我看来便利的方向，我想先从我接触到运维抱怨的问题开始。
最近在搞devops，有一点对Infrastructure as code代码风格的感悟
直接从一个例子展开吧
假如需要将原来单账号下以下多网络分别创建到单独的账号下
1 | # network.auto.tfvars |
为了网络创建复用自然需要使用module去按账号构建
（别想动态指定provider，terraform不支持！）
那问题是怎么将vpc的配置按账号分组传递给对应的module
来看两种方案
在Rust中常有配置读写的操作，一般可以用Arc<RwLock<T>>来实现，也可以用arc-swap来。有什么不同？
下面拿一个例子来说明下
假设有个配置，会有一个read thread不断获取配置，配置更新时要实时反映出来。
之前写sealed trait时没提他在oauth2-rs中怎么用, 为什么用，这个其实在状态接口设计中很有用，今天展开聊聊。
今天聊聊typestate模式。
新版oauth2-rs使用这个模式是想解决一个问题。
在Oauth2中，一般需要提前配置好auth_url, token_url, introspect_url等，才能调用后续的鉴权相关功能。比如没有token_url配置好，你就无法成功拿授权码（code）获取token。
但如果用户忘了配置，那就会在调用获取token时才得到运行时错误。
能不能在编译时就把错误暴露出来，让用户提前感知问题？
这就是typestate模式能很好解决的问题。
AWS Lambda Function是轻量级的计算服务。优势是按需付费，专注于功能，服务本身如何构建暴露都有AWS都不需要自己操心。
而按需付费基本就是服务使用时长和内存占用了，这个优化的话那妥妥的是Rust的拿手好戏, 所以现在有好多Serverless服务都用Rust构建的Lambda Function来搞。
今天简单看下如何用Rust快速构建Lambda Function（别担心没aws环境，往下看，有本地沙箱可尝试）
提到Rust请求中间件, 就不能不提tower。
tower是一个请求协议无关的的中间件定义类库，主要定义了Service和Layer两个trait来帮助实现可重用的请求处理中间件。
今天拿聊聊它如何巧妙构建起中间件。
我们知道Rust的异步是以task的调度来构建的。task作为抽象在语言层面的调度单元。
那如果想要观测其的调度执行有没有办法呢？。
有的！异步runtime库tokio就有个tokio-console可以实现对异步调度的观测和分析，其对了解调度的机制和性能分析都很有帮助。
