found drama

get oblique

Tag Archives: service-oriented architecture

on SoundCloud’s microservices story

by !undefined

How we ended up with microservices.:

Fascinating story from Phil Calçado at SoundCloud about their shift from a monolithic Rails app toward microservices and a service-oriented architecture.

It’s refreshing to read someone else’s story, and to see how well it lines up with the one that I’ve been living professionally for the past couple of years. The best part? The sobering admission that no matter how disciplined you are about pulling things out of your monolith, that some things are just so stable and so… cheap (??), that you’re better off just leaving them in there.

Not that there’s anything wrong with the desire to keep decomposing, but only if it’s done thoughtfully. Because as a friend recently quipped:

If you have to deploy all your microservices together as a blob, they aren’t really microservices, are they? More like OOP in the large.

— Nick Husher (@TeslaNick)

September 30, 2015

eBay’s experience with Hystrix

by !undefined

Application Resiliency Using Netflix Hystrix:

Good write up from the eBay team about how they’re using Hystrix to put circuit breakers around problematic methods (read: “remote service calls”). Their experience seems to pretty closely match my own (though they’ve been using it longer, and at larger scale).

Also, let’s take a moment to sanity check that closing sentiment:

…but Hystrix has proven to be a sound and mature library for maintaining a resilient environment for our critical applications, providing high availability during any time period.

One thing to remember when working with circuit breakers in the context of a service-oriented architecture (i.e., micro-services) is that there’s the need to differentiate between being “available” and providing the desired level of functioning. Ask yourself, what’s worse: quickly getting back an error that you can handle? or waiting a (potentially) really long time for a successful response? Obviously there’s no one-size-fits-all answer to this question, as it depends on who your consumers are, what your SLAs are, etc. But it’s probably a good idea to get in the habit of preferring fast responses, coping well with errors and failures, and being the good citizen that doesn’t cause cascading failures because you’ve allowed all your request threads to back up and wait on long-running queries that maybe never complete.

Linkdump for March 25th

by Rob Friesel

Microservices James Lewis & Martin Fowler: There’s no reason why this same approach [Amazon’s “you built it, you run it”] can’t be taken with monolithic applications, but the smaller granularity of services can make it easier to create the personal relationships between service developers and their users. (tagged: service-oriented architecture SOA ) flexbox in the […]

Linkdump for October 12th

by Rob Friesel

The Node Beginner Book A comprehensive Node.js tutorial by Manuel Kiessling. (tagged: JavaScript Node.js ) Mitt Romney’s Terrible, Horrible, No Good, Very Bad Foreign-Policy Speech Conor Friefersdorf, writing for The Atlantic: Should Romney be elected he'll almost certainly work closely with despots in Saudi Arabia and Pakistan, for example, and he'll fear certain possible democratic […]

Linkdump for July 30th

by Rob Friesel

Service-oriented Songkick James Coglan writing at the Songkick blog re: the migration of their monolithic Rails app into modularized components and a service-oriented architecture. Interesting case study, and definitely worth the 10 minutes. (tagged: service-oriented architecture Rails Songkick James Coglan ) Colson Whitehead’s Rules for Writing Colson Whitehead, writing at Most people say, “Show, […]