3 ms·
The "fallacy" breaks down pretty quickly when we consider its implications. If we were to follow the suggestions given, we shouldn't be using: - Email services
by whack 7y ago
The "fallacy" breaks down pretty quickly when we consider its implications. If we were to follow the suggestions given, we shouldn't be using:
- Email services such as SES or Sendgrid
- Password auth services such as Firebase
- Chat services such as Twilio
You might say those are extreme examples, and that's the whole point. Clearly there are a ton of use-cases where it makes sense to build reusable services once, and using it across many clients. Not just for "enhancements", but as an integral part of your service's functionality. So how and where do we draw the line between reusable services and avoiding service-dependencies? That's the real question we should be asking, and one I don't see being answered in the article.
- chrismarlow9 7y agoThis is what I was wondering. The entire concept of AWS is built around "re-use". Forgive me if I'm wrong but didn't Bezos decide to rebuild amazon because of technical debt and wanted to build independent "re-usable" components. The entire thing was modeled as though teams were really companies. Each "team/company" (think of RDS as a team) defined their API to the overall guidelines, and then other teams interacted with them to make use of their service. He realized the business case for this and AWS was born. Maybe that's just some fake story I read somewhere. Anyway the entire concept of B2B also challenges this. We don't build a new company each time we need something new. Even assembly language doesn't agree with this.
- lonelappde 7y agoIt's fake. Bezos/team realized Amazon was good at web tech and so built a version for sale. Amazon didn't eat its own dogfood until years later. They did the same thing for logistics too, building a service for each logistical task they do (warehousing and delivery)
- meheleventyone 7y agoI look at it like this. It’s super useful to have a screwdriver that has an adaptor that will take many different kinds of bits. It would be super painful to have a really configurable bit that could with some work fit any screw. My exemplar is a library for doing things with grids. It supported any kind of 2d grid. It was an amazing piece of design from a conceptual standpoint. Super generic, clean and with some impressive demos doing very non-standard things. It was also much easier for me to write my own grid implementation for my usecase than learn how to use. Being reusable because you do something well is great. Being “reusable” because you can be made to do one thing out of a bunch once you learn how is not. From a business point of view it’s about how valuable that flexibility is and generally I think if it’s not part of the core business you are better finding an inflexible fit rather than a flexible thing you have to sculpt to work. Simply because the latter takes focus away from what you are actually trying to do.
- jodrellblank 7y ago> It would be super painful to have a really configurable bit that could with some work fit any screw. Why would it? Universal sockets exist: https://images-na.ssl-images-amazon.com/images/I/61UczrhrTuL._SY355_.jpg https://images-na.ssl-images-amazon.com/images/I/61UczrhrTuL... - I can imagine one built with small enough pins to push into/around any kind of screw head, although I don't know if one exists today.
- meheleventyone 7y agoThe super complex generic grid library is also probably useful for someone but I’d say neither case is more universally useful due to the complexities involved.
- quickthrower2 7y agoInteresting because in those examples the need for reuse was so high that not only is the code reused but an entire company is set up, paying staff including sales and marketing people not working on code itself but making people aware of the solution. In fact there are multiple companies providing each of those services. With internal code, there might be a team per micro service or maybe 0.25 of a developers time devoted to it. Not saying for or against microservices but they can’t be compared to SaaS services