The Fly Blog
·
离职访谈：JP Phillips
内容提要
JP Phillips离开Fly.io，四年来为工程团队做出重要贡献。他希望公司更专注于云服务而非平台即服务。他对Fly Machines的无中心协调设计感到自豪，认为GraphQL和Elixir是平台的不足之处，但对新功能表示满意。期待未来的工作更轻松。
关键要点
-
JP Phillips离开Fly.io，四年来为工程团队做出重要贡献。
-
他希望公司更专注于云服务而非平台即服务。
-
对Fly Machines的无中心协调设计感到自豪。
-
认为GraphQL和Elixir是平台的不足之处。
-
对新功能表示满意，期待未来的工作更轻松。
-
Fly Machines平台已基本完成，能够支持下一代产品。
-
希望Fly.io能更直接定位为云服务提供商。
-
他与家人共同参与了离职决定。
-
他最自豪的成就是使开发者能够通过API调用在全球运行工作负载。
-
Flyd的设计不需要中心协调，且在大多数地区的创建调用延迟低于5秒。
-
他认为GraphQL和Elixir是平台的短板。
-
pilot是新的init，能够原生运行容器，提升了Fly Machines API的未来。
-
他认为BoltDB是正确的选择，避免了SQL带来的潜在风险。
-
他对OpenTelemetry的引入表示肯定，认为其对系统故障排查至关重要。
-
他对Rust编程语言表示赞赏，认为其在某些方面优于Go。
-
他对公司管理结构提出批评，认为缺乏一致的沟通和方向。
-
他对未来的工作充满期待，希望能有更轻松的工作环境。
延伸解读
JP Phillips的离职原因
JP Phillips在Fly.io的离职主要是因为他对公司未来方向的期望与实际情况不符。他希望Fly.io能更专注于云服务，而非平台即服务，这反映了他对公司战略的深刻思考。对于其他员工来说，这种对公司方向的关注也许能引发对自身职业发展的反思。
Fly Machines的设计优势
JP对Fly Machines的无中心协调设计感到自豪，认为这种设计使得系统在全球范围内的调用延迟低于5秒。这一设计不仅提升了用户体验，也为开发者提供了更高效的工作方式。对于正在考虑云服务架构的团队来说，这种设计理念值得借鉴。
技术选择的反思
JP对GraphQL和Elixir的批评表明，技术选择对项目的成功至关重要。他认为GraphQL降低了开发效率，而Elixir则未能满足他的需求。这提醒开发团队在选择技术栈时，需充分考虑其对项目进展的影响，避免因技术不当而导致的资源浪费。
延伸问答
JP Phillips离开Fly.io的原因是什么？
JP Phillips认为他对未来的期望与公司当前的方向不符，特别是对云服务的关注不足。
JP对Fly Machines平台的看法是什么？
他对Fly Machines的无中心协调设计感到自豪，并认为该平台已基本完成，能够支持下一代产品。
JP对GraphQL和Elixir的看法如何？
他认为GraphQL和Elixir是平台的不足之处，GraphQL会减慢开发速度。
JP在Fly.io最自豪的成就是什么？
他最自豪的成就是使开发者能够通过API调用在全球运行工作负载。
JP对未来工作的期待是什么？
他期待未来的工作能够更轻松，并希望能有更直接的云服务定位。
JP对Fly.io管理结构的看法是什么？
他批评公司管理结构，认为缺乏一致的沟通和方向。
