5 ms·
Just noting this as I have some successful use cases of microservices as it may help others. What I mean by successful is I have reused them in many projects wi
by sebringj 9y ago
Just noting this as I have some successful use cases of microservices as it may help others. What I mean by successful is I have reused them in many projects without having to modify them for each project, meaning they stood alone with only needing some config items to add one or more clients.
1) Authentication - JWT and OAuth provider related, can be used with multiple clients or installed per client
2) Pre signing of S3 uploads (very tiny file to do this one)
3) Ecommerce api w / shipping using fedex and stripe
4) Plugable CMS with JS dropped on a page used for UI and auth and S3 used as content store with an API sitting in between
I guess some of them could be considered just an API? But if you can reuse it generally and the scope is fairly narrow, that is more of what a microservice should be. There is also the tradeoff where you may be thinking if this is so tiny, why even do it?...which is probably a good thing to consider before adding more complexity.
- dkoston 9y agoYes, others also include: - Proxies that upload/retrieve assets to multiple cloud providers (i.e. upload files to / retrieve from GCS and S3 in case one is down) - A service that screens/transforms attachments/uploads for security before allowing them to reach other services - An API for sending mail/SMS/other contacts via multiple providers to deal with outages to one or more providers. Often, these are before built as libraries and imported into multiple projects which is the wrong approach. Offering up an API for these instead can help decouple. However, the author probably doesn't understand versioning and deprecates or makes breaking changes to APIs and then has to update a bunch of consumers. If you want a decoupled system, you have to not break the system. This is why legacy stuff exists at older companies. Once API v1 of the mail sending service is done and working, there's no reason you need to break it, or add new features, or take it down. Keep it running and also run v2 so that people can use the new features. The author is probably running v1 and v2 out of the same codebase and overwriting the v1 history so they can't maintain it, that's just bad software project management. Maybe the title should switch to: "coordinating a complex architecture is hard, I only build easy stuff"
- sebringj 9y agoYah funny you say that about versioning and breaking changes. The side effect of the CMS one for example is its been around for 7 years now and I want to kill it off but there are clients depending on it. I don't even update the code anymore so I guess its ok but from that lesson learned, making the other "microservices" as I've defined them you should build a microservice so it can also be used individually for a client as well as multiple clients where the work of doing one or many is the same so you could easily walk away from the responsibility of hosting it if you wanted.
- dkoston 9y agoIt’s good that you want to update it and make it better. However, it it works fine for the clients and they are happy, you should be too. We all look back on our previous work and see room for improvement, that’s a good thing. However, spending too many cycles trying to achieve perfection where it’s not desired will prevent you from moving on with your life to bigger and better pursuits. Be really happy that you have a software project which survived for 7 years. Many fail in far shorter time and provide no value.
- heartbreak 9y ago> coordinating a complex architecture is hard, I only build easy stuff If this had been the actual title of this submission, I would have been much more receptive to it. Let's expand on that: "Coordinating a complex architecture when you do not need it is needlessly expensive, so I recommend not doing so." This blog post coming from a contract software firm tells me that they're willing to sacrifice billable hours to instead write just enough software to solve the client's problem.
- SmirkingRevenge 9y agoI'm not sure what the author does or does not understand, but many of the people going full-steam down the microservice road don't know those things either, and so end up often creating at least as big of a mess as they would with a monolith, despite lots of zeal and hype. Coordinating a complex architecture IS hard. Microservices are often used as a way to wish away all that hard coordinating because... decoupling or something... and stuff. Meanwhile what actually gets built is a tangled mess of tightly coupled (but separate) libraries as "services", with many-to-one relations between those services and developers, unnecessarily complex deployments, and... a big, fat, crappy HTTP layer slathered on top, just to add insult to injury. The next step is usually to pour on generous helpings of graphql.
- rb808 9y agoNice, but these used to be called libraries in the old days.
- sebringj 9y agoYah I get confused when to apply when at times. If I had to distill it down to when I think its a gain: 1. You need some networked thing to be setup no matter what, 2. It is a pain to keep doing over and over from scratch or one-off even with a library 3. Its just super quick and easy to add one more config set and you're done. 4. THE MOST IMPORTANT ONE... drumroll, you get a subscription payment for it per customer!!! slightly evil but nice to be paid monthly for it. It may be slightly less evil though if you are charging the client less overall than going the other options.
- philipkglass 9y agoMicroservices can be used akin to language-independent libraries. You can implement some ML functionality atop Python's marvelous scikit-learn, deploy it as a little service with an HTTP endpoint, and easily call it from an existing Node or PHP code base. That's easier and more effective than forcing unification to one language ecosystem.