Live data from Hacker News

How we build microservices

blog.yourkarma.com

41–42 of 42 posts

Re: How we build microservices

#41

Earlier quoted context omitted.

this is where docker and the ecosystem around it starts filling in the pieces. also, it makes failures hurt less, and rollbacks much easier.

Docker answers half of the issues: deployment. The other halves: distributed logging (how do you trace a 'transaction' that is being executed against multimachines/multiplaths?) What about rolling releases? what about versioning? What about service discovery (still immature field, look at how many products/tools out there trying to be THE service discovery choice).

We actually use syslog-ng + Loggly for distributed Loggly. We partially solve the transaction problem by slapping a request ID on every action that's initiated by a web request. We then carry this request ID from service to service, which gives us the ability to trace exceptions cross-service. It's obviously not the perfect solution, but it has helped us many times when debugging customer-facing 500 exceptions.

We solved the service discovery problem by simply using DNS. Every service runs behind an (internal) Elastic Load Balancer, and we let the load balancer configuration figure out which instance is up and which one is down. Again, not the perfect solution, but it works great for now and is very easy to setup/maintain.

Re: How we build microservices

#42

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.

No difference, just a new name. Not so bad I guess, however I fear it will cropper when vendors leap on the bandwagon again and start sell inappropriate tools and frameworks badged as Microservice and we can start the process of renaming again.

That's great news for vendors and consultants who jump on the bandwagon though :).
Post reply on HN