undefined | Better HN

0 pointsmrweasel9y ago0 comments

>Any positive experiences with micro-services here?

It makes sense for some thing. We run a webshop, but have a separate service that handles everything regarding payments. It has worked out really well, because it allows us to fiddle around with pretty much everything else and not worry about breaking the payment part.

It helps that it's system where we can have just one test deployment and everyone just uses that during testing of other systems.

I've also work at a company where we had to run 12 different systems in their own VMs to have a full development environment. That sucked beyond belief.

The idea of micro-service are is enticing, but if you need to spin up and configure more than a couple to do your work, it starts hurting productivity.

0 comments

buro99y ago

> have a separate service that handles everything regarding payments. It has worked out really well, because it allows us to fiddle around with pretty much everything else and not worry about breaking the payment part.

Is the payments service a single service that manages the whole transaction, or have you go for multiple services handling each part and, if so, how did you manage failure with a distributed transaction?

mrweaselOP9y ago

It's a single service. It just sites between us and our PSPs. That way no other system needs to worry about integrating directly with the PSPs.

notimetorelax9y ago

Not sure if it's the case here. But what works really well for us is queues with at-least-once guarantee. (For payment services you might need an additional check to guarantee exactly one execution.) I think you can find this queue offered by most providers.

drdaeman9y ago

Totally agree.

We had almost the same story with payments. Except for we've jumped to a payment-processing SaaS but got dissatisfied (all those SaaSes I saw don't work with PayPal EC without so-called "reference transactions" enabled) and decided that wasn't a good idea and we have to jump back to in-house implementation.

I didn't want to re-integrate the payments code back to the monolith - thought it would take me more time and make code messier. So I wrote a service (it's small but to heck with "micro" prefix) that resembled that SaaS' API (the parts we've used). It had surely evolved and isn't compatible anymore, but it doesn't matter as we're not going back anyway.

Works nicely and now I'm feel more relaxed - touching the monolith won't break payments.

On the other hand, I see how too many services may easily lead to fatigue. Automated management tooling (stuff like docker-compose) may remedy this, but also may bring their own headaches.

cableshaft9y ago

I don't think having a handful of services handling a specific, atomic section of the app really classifies as this 'micro-services' claim, it's just smart separation of concerns.

We have specific services that process different types of documents, or communicate and package data from different third parties, or process certain types of business rules, that multiple apps hook into, but it's literally like 20 services total for our department, some that are used in some apps and not others.

When I hear 'micro-services' I'm picturing something more akin to like node modules, where everything is broken up to the point where they do only one tiny thing and that's it. Like your payment service would be broken into 20 or 30 services.

But maybe I'm mistaken in my terms. I haven't done too much with containers professionally, so I'm not too hip with "the future".

j / k navigate · click thread line to collapse