TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Towards a Type System for Containers and AWS Lambda to Avoid Failures [pdf]

180 点作者 cmeiklejohn大约 7 年前

7 条评论

stephen大约 7 年前
I&#x27;m not sure what the point of this paper is?<p>* It talks a lot about containers, but this is really just contracts across systems, whether they run in containers or not. So not sure why the word &quot;container&quot; is necessary.<p>* It says &quot;towards a type system&quot;, but then just muses about IDL&#x2F;REST&#x2F;Thrift, says &quot;we need cross-system stuff ... so we should use better types&quot;, ...but...what does that look like? There are vague assertions that &quot;we&#x27;ve done this&quot;, but I don&#x27;t see any description of what that actually looks like.<p>* The Zookeeper&#x2F;Kafka example, while apt, I&#x27;m not sure if &quot;having a cross-system type system&quot; is exactly right, as Zookeeper is purposefully&#x2F;validly ambivalent about what its clients encode within it&#x27;s file system, so whether the replication data is F&#x2F;F+1&#x2F;whatever is meaningless to Zookeeper. So to me the solution is not &quot;cross-system type system&quot; where Zookeeper becomes aware of Kafka&#x27;s invariants, it&#x27;s just Kafka itself correctly&#x2F;internally interpreting the Zookeeper data. If that means it&#x27;s an Either[ValidCluster,InvalidCluster] within the Kafka &quot;ClusterInfoApi&quot; abstraction, that&#x27;s fine, but that&#x27;s not something the Zookeeper API&#x2F;IDL is going to care&#x2F;know about.<p>* You&#x27;re never going to get all networked services to agree on the One True networking format&#x2F;One True type system&#x2F;IDL, so why even muse about this as a possible approach?<p>Disclaimer I don&#x27;t read academic papers on a regular basis.
评论 #16749994 未加载
keithwhor大约 7 年前
This is what we’ve done at StdLib [1] with FaaSlang [2].<p>FaaSlang uses static analysis and a superset of ESDoc comments to infer types for the API interface to serverless functions on our system. This allows for automatic type coercion from query parameters, automatic error checking, and more - all caked in at the gateway layer before a function is executed.<p>Zero configuration; just write comments the way you normally would. It’s almost a healthy midpoint between TypeScript and JavaScript, operating above the runtime, but theoretically applicable to any language run within a function container.<p>[1] <a href="https:&#x2F;&#x2F;stdlib.com" rel="nofollow">https:&#x2F;&#x2F;stdlib.com</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;faaslang&#x2F;faaslang&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;faaslang&#x2F;faaslang&#x2F;</a>
评论 #16750912 未加载
评论 #16750899 未加载
arcticbull大约 7 年前
I&#x27;ve not nearly as much experience developing these systems, so getting started without types was a bit daunting. I wrapped my Lambda functions in protobufs and used a shared common definition repository. Then the lambda services support either the JSON rep of the protos or full-on binary protos, and the type checking happens on both ends. Curious what y&#x27;all think of this as a solution.
评论 #16750935 未加载
bjz_大约 7 年前
I&#x27;m really happy more work is being done in this space! Also nice to see nods to various attempts from the past - it&#x27;s important we learn from their failings, but also their successes. It&#x27;s too easy to get stuck in the mindset of &quot;Ugh CORBA&quot; and &quot;noes, SOAP&quot;, without being able to see an opportunity there. Let&#x27;s be persistent and figure this stuff out!
评论 #16750910 未加载
gm-conspiracy大约 7 年前
I am having SOAP-related WSDL flashbacks.
评论 #16747268 未加载
评论 #16748775 未加载
评论 #16749665 未加载
xinjo大约 7 年前
I like the premise of the paper, but the motivating examples feel really weak to me.
评论 #16749296 未加载
cbrozefsky大约 7 年前
&quot;CORBA, while successful&quot; ....
评论 #16747285 未加载
评论 #16747284 未加载