The cacophonies of distributed systems

If you have never heard about Deutsch + Gosling’s fallacies of distributed computing, you are missing out big time! I encourage you to check them out here. Those delusions are widely considered in the distributed systems field as some of the most painful assumptions any junior systems designer, or architect can make. I like to call them “career-limiting choices”.

When I first learned about these eight fallacies a few years ago, I decided I needed to keep them around. I wrote them in a piece of paper and taped it outside of my office. The piece of paper is still there, except that it now has eleven statements – I guess some random folks added a few more fallacies. 

Continue reading “The cacophonies of distributed systems”

The Microservices Maestro

Something I really like about living in the city is the fact that it is made for the masses. Despite its many defects (the rain not being one), Seattle is architected to enable hundreds of thousands of people to go through their busy days. It has a transportation system that interconnects different areas, it mandates different land usage policies for parks, residences, commerces and schools, and it provides restricted parking zones. It is designed for walking (assuming you like hills), it provides easy access to hospitals and it is guarded by police and fire departments.

But Seattle wasn’t initially a big city, its growth is more of a work-in-progress kind of thing. Like many other cities including all-mighty New York, Seattle is constantly under development and re-planning so it can scale to support even more people. It needs more efficient transportation (think subway), bigger highways, more parking and more recreational areas and residential zones.

The similarities between city planning and software engineering are fascinating to me, they are well described by Sam Newman in his “Building Microservices” book. Just like cities started as small towns, most services started as simple servers sitting under someone’s desk, and processing a few hundred requests per day. Given some time and if the idea is right, a service may become popular —that’s a great thing to happen except that the challenge of increasing demand quickly turns into a problem of dealing with higher customer expectations. This is similar to how we expect better transportation and more efficient police enforcement when a town evolves into a city.

Continue reading “The Microservices Maestro”

Tech interviews and how to cope with them

‘The recruiter will call you back soon’ told me the fourth (and last) interviewer I spoke with after a long day interviewing at the Microsoft campus.

I was pretty psyched about getting an offer and moving to Redmond. I wasn’t desperate (I think) but I definitely was a Microsoft fanboy willing to change his entire world to work there. I had decided to tell the recruiter that although I preferred a position related to developing Word’s ultimate new feature, I was willing to take pretty much any job there.

‘Let’s go straight to the point –  I accept your offer’, I practiced many times with a mirror. You can imagine my disappointment when the recruiter didn’t call me back, didn’t pick up my calls and didn’t reply to my emails.

Though I am not a black belt at interviewing in big tech companies, I have had my share of reality checks:

You had me at ‘hello’. I found that getting an interview with the Tech titans requires a lot more than building a nice resume and submitting it through their careers web page. I don’t think I am overstating when I say that this worked for me once in a hundred times. On the other hand, having someone internally refer me worked more often than not and reaching out to recruiters through LinkedIn also turned out to be a pretty good option. But by far the best way to get these companies’ attention is to be already in the club – once I joined Microsoft, other companies started poaching me.

Continue reading “Tech interviews and how to cope with them”