Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we build microservices

blog.yourkarma.com

Post reply on HN
Print view View original

11–20 of 42 posts

Re: How we build microservices

#11

Post by xetorthio »

vertex-four wrote: post #9
Arie wrote: post #4

Earlier quoted context omitted.

Every little piece is easy/easier to test, but testing end-to-end over multiple micro-apps is hard in my experience.

Why is this? Is it simply a deployment issue - that it's hard to get all the pieces running together in a test environment?

In my experience even getting all the pieces installed in a testing environment is hard. Specially when you need to make sure that they are all wired correctly, with the correct version, with all their dependencies (maybe different kind of databases, queues, caching layers) and on top of that if services are written in different languages, that adds another level of complexity. Eventually when the system grows big enough and the team of people that needs a stable test environment grows big enough, it just becomes too expensive.

Re: How we build microservices

#12

Post by AdrianRossouw »

xetorthio wrote: post #11
vertex-four wrote: post #9

Earlier quoted context omitted.

Why is this? Is it simply a deployment issue - that it's hard to get all the pieces running together in a test environment?

In my experience even getting all the pieces installed in a testing environment is hard. Specially when you need to make sure that they are all wired correctly, with the correct version, with all their dependencies (maybe different kind of databases, queues, caching layers) and on top of that if services are written in different languages, that adds another level of complexity. Eventually when the system grows big en…

this is where docker and the ecosystem around it starts filling in the pieces.

also, it makes failures hurt less, and rollbacks much easier.

Re: How we build microservices

#13

Post by iain_hecker »

Smudge wrote: post #7

> We have an in-house tool we use called Fare which reads this configuration and sets up the appropriate SQS and SNS queues. Would love to see this released publicly. As stated in the post, there aren't a ton of (public) examples of microservice architectures, so everyone seems to be solving the same problems independently. It would be great if we could start pooling more of our resources together.

We will! There are however a couple of really nasty issues that we don't feel comfortable to release to the public yet.

Re: How we build microservices

#15

Post by iain_hecker »

jessaustin wrote: post #14

What's the advantage for your situation of publishing to SNS which is in turn publishing to SQS vs. just publishing directly to SQS? Are you forking to multiple SQS queues?

Yup we are. There might be multiple applications interested in the event and they each get their own queue.

Re: How we build microservices

#16

Post by tiglionabbit »

The text makes it seem like they're using SQS for many things, but the diagram only shows it between Orders and Shipments. I guess everything else communicates through the database and HTTP requests?

Using SQS means you're either polling or long-polling with hangups every 20 seconds. This seems pretty shitty to me. Also how do you structure one of these services around polling or long-polling to get its info? It sounds like they're using Rails. Does Rails have something that makes this easy to do?

At first, reading this reminds me of the Blackboard pattern from The Pragmatic Programmer. This pattern seems like a neat way to separate an application into different agents.

Re: How we build microservices

#17

Post by marceldegraaf »

iain_hecker wrote: post #15
jessaustin wrote: post #14

What's the advantage for your situation of publishing to SNS which is in turn publishing to SQS vs. just publishing directly to SQS? Are you forking to multiple SQS queues?

Yup we are. There might be multiple applications interested in the event and they each get their own queue.

Have you looked into a "real" messaging queue for this, like RabbitMQ or another AMQP based system for this? Or are you bound to SNS/SQS for a particular reason?

Re: How we build microservices

#18

Post by pdx » 

    The shipment app listens to the messaging system, sees an 
    order take place, looks at the details, and says, "Okay, 
    I need to send two boxes to this person." Any other 
    services interested in an order happening can do 
    whatever they need to with the event in their own 
    queues, and the store API doesn't need to worry about 
    it.
I'm curious how you guarantee that all the systems that need to see an event, will actually see it, before it is removed from the event queue. I assume the shipment app, in your example, is responsible for removing the event from the queue. So, what if it removes it before the mailer app or the "make cash register sound" app, sees the event?

Re: How we build microservices

#20

Post by dragonwriter »

MattGrommes wrote: post #19

Is there a difference between microservices and SOA? I've used architectures just like this in the past but never heard of "microservices" until recently.

AFAICT, "microservices" is exactly SOA in its original sense; my guess is the rename is because SOA has become so attached to particular XML-based implementations and standards (e.g., the WS-* series of standards).
Post reply on HN