3 ms·

I see a lot of about architecture, service design and complexity. One of the key missing piece is around Amazon culture. Promo-driven design is a real deal at A

by vaidhy 3y ago

I see a lot of about architecture, service design and complexity. One of the key missing piece is around Amazon culture. Promo-driven design is a real deal at Amazon. I am sure this design got someone promoted to principal engineer or higher. If you cannot build complexity into the design, how can you prove your caliber and get promoted.

theK 3y ago
The article is more about bundling together lambda functions into horizontally scalable containers. Paraphrasing the author: > I think the prime video team's presentation should have been called "Moving from lambda to container microservices" There is nothing particularly bad about this move. Prototype something in a FaaS, move it to a container based microservices when you know which features you want and how they perform. Not doing much FaaS prototyping myself but I agree with the author that FaaS beats containers in time to production (even if the difference might be negligible in some cases)
- disruptiveink 3y ago
  Exactly. The article is stating that there is nothing wrong with the move Prime Video did, and that it was a "serverless to containers" refactoring that somehow the Internet misrepresented as "microservices to monolith" and kicked up viral "even Amazon admits that microservices is overengineering!" meme discussions. Which was obvious to anyone who had read the original post that was not the case, but most people were commenting on what they thought the (incorrect) title meant. I am disappointed that the top comment and all of the discussion is once again not related to the article at hand in the slightest and just focused on the easy "complex is bad, guys!" dunk.
klabb3 3y ago
Definitely a real phenomenon. Obscure overengineering also serves another purpose: if you want to build a mini-empire, people leave you alone because they don’t have time to fully grok your design, so they can’t provide meaningful feedback. In these companies the burden-of-proof falls on the critic of a design, not the designer. Simply saying “this looks too complex” is treated as “oh, they couldn’t understand this sophisticated piece of engineering”. This is a cultural issue. If your peers don’t grok it quickly, you should return to the drawing board, or at least provide evidence for the extraordinary circumstances that warrants all that complexity.
- ownagefool 3y ago
  The problem with statement like "this looks too complex" is that it lacks substance and is used as a stick to beat people with, and often has alternative meanings. To combat this, you need to justify the complaint. In the case of lambda, I think being tied into an ecosystem of things that you can't run locally is a net loss, but Amazon has done a terrific job at making a bunch of people not super comfortable with compute, see just running a share-nothing process as the way to bridge the gap, like PHP never existed. Same thing happens with IT orgs that end up owning cloud. You get azure, regardless of whether you want such a thing.
  - kamray23 3y ago
    Well, Amazon running applications on AWS Lambda is more like them having a general purpose cluster which all their services borrow when they need to run some boring unpredictable tasks than it being some bizarre remote service thing. I mean, it's theirs, it's technically local. Local enough.
  - klabb3 3y ago
    > The problem with statement like "this looks too complex" is that it lacks substance and is used as a stick to beat people with, and often has alternative meanings. I’ve never seen anyone say this at $faang-gig. Ive certainly never been it used as a stick. While it’s true that any process can be abused, I’m taking about default burden of proof. > To combat this, you need to justify the complaint. Yeah, of course you can’t just say a magic word and expect others to fall in line. I’m claiming there should be justification for proposed increases in complexity. There is an asymmetry in where adding complexity is so trivial it is often accidental, whereas reducing complexity is labor intensive and so difficult that it’s often not cost-effective to even attempt it. Because of this asymmetry, complexity accumulates uncontrollable over time, unless you actively reduce it (expensive) or prevent it before it is implemented (cheaper). Otherwise your software engineers turns into software alchemists, imo.

by vaidhy 3y ago

theK 3y ago

The article is more about bundling together lambda functions into horizontally scalable containers. Paraphrasing the author: > I think the prime video team's presentation should have been called "Moving from lambda to container microservices" There is nothing particularly bad about this move. Prototype something in a FaaS, move it to a container based microservices when you know which features you want and how they perform. Not doing much FaaS prototyping myself but I agree with the author that FaaS beats containers in time to production (even if the difference might be negligible in some cases)

disruptiveink 3y ago
Exactly. The article is stating that there is nothing wrong with the move Prime Video did, and that it was a "serverless to containers" refactoring that somehow the Internet misrepresented as "microservices to monolith" and kicked up viral "even Amazon admits that microservices is overengineering!" meme discussions. Which was obvious to anyone who had read the original post that was not the case, but most people were commenting on what they thought the (incorrect) title meant. I am disappointed that the top comment and all of the discussion is once again not related to the article at hand in the slightest and just focused on the easy "complex is bad, guys!" dunk.

klabb3 3y ago

Definitely a real phenomenon. Obscure overengineering also serves another purpose: if you want to build a mini-empire, people leave you alone because they don’t have time to fully grok your design, so they can’t provide meaningful feedback. In these companies the burden-of-proof falls on the critic of a design, not the designer. Simply saying “this looks too complex” is treated as “oh, they couldn’t understand this sophisticated piece of engineering”. This is a cultural issue. If your peers don’t grok it quickly, you should return to the drawing board, or at least provide evidence for the extraordinary circumstances that warrants all that complexity.

ownagefool 3y ago
The problem with statement like "this looks too complex" is that it lacks substance and is used as a stick to beat people with, and often has alternative meanings. To combat this, you need to justify the complaint. In the case of lambda, I think being tied into an ecosystem of things that you can't run locally is a net loss, but Amazon has done a terrific job at making a bunch of people not super comfortable with compute, see just running a share-nothing process as the way to bridge the gap, like PHP never existed. Same thing happens with IT orgs that end up owning cloud. You get azure, regardless of whether you want such a thing.
- kamray23 3y ago
  Well, Amazon running applications on AWS Lambda is more like them having a general purpose cluster which all their services borrow when they need to run some boring unpredictable tasks than it being some bizarre remote service thing. I mean, it's theirs, it's technically local. Local enough.
- klabb3 3y ago
  > The problem with statement like "this looks too complex" is that it lacks substance and is used as a stick to beat people with, and often has alternative meanings. I’ve never seen anyone say this at $faang-gig. Ive certainly never been it used as a stick. While it’s true that any process can be abused, I’m taking about default burden of proof. > To combat this, you need to justify the complaint. Yeah, of course you can’t just say a magic word and expect others to fall in line. I’m claiming there should be justification for proposed increases in complexity. There is an asymmetry in where adding complexity is so trivial it is often accidental, whereas reducing complexity is labor intensive and so difficult that it’s often not cost-effective to even attempt it. Because of this asymmetry, complexity accumulates uncontrollable over time, unless you actively reduce it (expensive) or prevent it before it is implemented (cheaper). Otherwise your software engineers turns into software alchemists, imo.