4 ms·

We started with a monolith which made determining service boundaries that much easier. What we struggled with the most is the concept of sharing data between se

We started with a monolith which made determining service boundaries that much easier. What we struggled with the most is the concept of sharing data between services. We started off with publish/subscribe method which quickly became very strenuous to maintain. Ended up switching to plain service-to-service communication over HTTP/S. This allowed us to focus on resiliency and performance of each micro-service more so than before. And so far it's been paying off great. Other things like having an overall view of the health of the entire system and having a way to consume and analyze logs in one place is absolutely detrimental to success in this type of architecture.

kenoyer130 9y ago
detrimental?
- eludwig 9y ago
  instrumental?
- avenoir 9y ago
  instrumental is the right word lol :)
newman8r 9y ago
That's why I like Foxx microservices/arangoDb - but it's really more of something you need to do from the ground up
latchkey 9y ago
"Ended up switching to plain service-to-service communication over HTTP/S." That statement assumes this picture: ServiceA -> Network (https) -> ServiceB I'm curious, what happens to the message being sent from ServiceA if Network or ServiceB is down?
- avenoir 9y ago
  We have a fraction of inter-service communication still flowing through pub/sub via RabbitMQ. This is typically done in cases where we absolutely cannot lose a message. Most of the communication, however, is via https with each microservice in the mix providing guaranteed high uptime, reasonable response time and some way of handling various failure conditions (ie fallback to cache, exponential backoff and etc). So while you do lose your message in this scenario, you have to have a very catastrophic network failure for this to have a wide-spread impact. We occasionally see blips which are dealt with via retries. So this has worked out fairly well at our not-so-crazy scale. I personally believe there is no right or wrong here. It all comes down to what your team is comfortable with. I think pub/sub is a great approach if you're willing to sink some time into it. Synchronous communication also has some very interesting development by companies like Netflix (Ribbon?).

kenoyer130 9y ago

detrimental?

eludwig 9y ago
instrumental?
avenoir 9y ago
instrumental is the right word lol :)

newman8r 9y ago

That's why I like Foxx microservices/arangoDb - but it's really more of something you need to do from the ground up

latchkey 9y ago

"Ended up switching to plain service-to-service communication over HTTP/S." That statement assumes this picture: ServiceA -> Network (https) -> ServiceB I'm curious, what happens to the message being sent from ServiceA if Network or ServiceB is down?

avenoir 9y ago
We have a fraction of inter-service communication still flowing through pub/sub via RabbitMQ. This is typically done in cases where we absolutely cannot lose a message. Most of the communication, however, is via https with each microservice in the mix providing guaranteed high uptime, reasonable response time and some way of handling various failure conditions (ie fallback to cache, exponential backoff and etc). So while you do lose your message in this scenario, you have to have a very catastrophic network failure for this to have a wide-spread impact. We occasionally see blips which are dealt with via retries. So this has worked out fairly well at our not-so-crazy scale. I personally believe there is no right or wrong here. It all comes down to what your team is comfortable with. I think pub/sub is a great approach if you're willing to sink some time into it. Synchronous communication also has some very interesting development by companies like Netflix (Ribbon?).