为什么有的公司infra 组是真的造轮子，有的是在做 Ops and Tools

匿名用户 发表于 2021-05-21 22:56:03
个人认为的好infra组几个评判标准，不用全满足：
1. 对公司revenue产生直接影响，有内部和外部用户群体且都要收费，比如aws/gcp上面卖的服务
2. 专注某些重要领域，storage/

想问一下层主觉得migration到新系统架构上都哪些是含金量高的活呢？一直觉得migration是脏活累活……想具体了解一下层主怎么想的

.....有一说一很多大厂的轮子都是为了内部创造升职机会弄出来的，真的有价值的轮子会成为业界标准

匿名者 发表于 2021-5-23 02:39
想问一下层主觉得migration到新系统架构上都哪些是含金量高的活呢？一直觉得migration是脏活累活……想具 ...

我在想层主说的 migration 可能回不回是 system re-design/re-write 比如 Map Reduce 往 Spark 的 migration 或者 batch 往 streaming 的 migration, 应该不是我们通常的比如 on-prems 往 cloud 或者 data base的 migration. On-prems 往 cloud 的migration 真的就非常无聊了...(属于有 engineering impact 但是毫无面试吹点的脏活累活)

匿名者 发表于 2021-5-22 13:56
个人认为的好infra组几个评判标准，不用全满足：
1. 对公司revenue产生直接影响，有内部和外部用户群体且 ...

有一个问题想请教一下，关于说migration含金量极高这点，从user impact的角度来说，基本上是transparent的，很难呈现所谓的impact吧？

地里的匿名用户 发表于 2021-5-23 01:49
层主说的太好了，方便具体展开说一下 "不会对某个具体的产品组产生强依赖，不用经常 ...

总结的很好，很想跳出devops+tools的圈子

其实大趋势是用cloud service上现有的。自己“造轮子”是个high-cost/high-risk的投资，做出来的东西reliability可能达不到云服务的水准。

匿名用户 发表于 2021-05-22 10:49:27
层主说的太好了，方便具体展开说一下 "不会对某个具体的产品组产生强依赖，不用经常看上下游脸色行事".

我观察到的某些大厂的 platform，其实也有往 ops + tools 走的趋势。比如

不是说真正核心的是distributed system，而不是business logic。
怎么这里还抢business logic的活？

匿名者 发表于 2021-5-24 02:44
不是说真正核心的是distributed system，而不是business logic。
怎么这里还抢business logic的活？

本身是核心但是知识搭戏台不涉及什么 design trade off 和 scaling + high throughput + low latency 和可以做的且有 impact 的核心是两回事吧

匿名用户 发表于 2021-05-22 11:36:11
这样来说，像AWS的DB组，e.g., RDS, ElastiCache等组都是很好的infra组吗？但感觉他们就是在开源代码上修修改改。。当然，这本身也很牛了，不过感觉出去不好找工作。。

GCP的db/storage就很好啊，e.g.  F1,  spanner,  colossus，自己完整搭的infra。当然修修改改在所有组都是一样，改bug+写feature不管是infra还是business组都需要啊

匿名用户 发表于 2021-05-23 14:47:49
GCP的db/storage就很好啊，e.g.  F1,  spanner,  colossus，自己完整搭的infra。当然修修改改在所有组都是一样，改bug+写feature不管是infra还是b

这种 很成熟的组是自己的infra，但是早就搭好了，现在也就是修修改改补小bug。之前换组时候和spanner的一个manager聊过，他说在这里最困难的一个是rampup，learning curve很大。二一个你想做点啥新东西，哪怕是bug fix，最大的困难就是convince各路元老的质疑，写doc开会，正经code写不了几行。