Dance, Computer, Dance

by Ray Grasso

Posts

Pieces I've written.

Start with a Monolith

21 September, 2014

The Microservices train is leaving the station baby and everyone is getting on board. Lots of folks have written about Microservices and their benefits but a recent project experience has left me more interested in when you should use the approach.

Here are two posts which jibe with some of what I’ve recently felt.

Eric Lindvall of Papertrail:

When you’re starting out, and when you’re small, the speed at which you can make changes and improvements makes all the difference in the world. Having a bunch of separate services with interfaces and contracts just means that you have to make the same change in more places and have to do busywork to share code.

What can you do to reduce the friction required to push out that new feature or fix that bug? How can you reduce the number of steps that it takes to get a change into the hands of your users? Having code in a single repository, using an established web framework like Rails or Django can help a lot in reducing those steps. Don’t be scared of monolithic web apps when you’re small. Being small can be an advantage. Use it.

Adrian Cockcroft ex. Netflix:

I joined Netflix in ‘07 and the architecture then was a monolithic development; a two week Agile sort of train model sprint if you like. And every two weeks the code would be given to QA for a few days and then Operations would try to make it work, and eventually … every two weeks we would do that again; go through that cycle. And that worked fine for small teams and that is the way most people should start off. I mean if you’ve got a hand full of people who are building a monolith, you don’t know what you are doing, you are trying to find your business model, and so it’s the ability to just keep rapidly throwing code at the customer base is really important.

Once you figure out how… Once you’ve got a large number of customers, and assuming that you are building some Web-based, SasS-based kind of service, you start to get a bigger team, you start to need more availability.

Large projects with long-term timelines seem like good candidates for using the Microservices approach1.

On the other hand, new products or services may not be the right situation to immediately dive in with a Microservices approach. It’s likely that the idea itself is being fleshed out and investing anywhere outside of that core goal is ultimately waste. Carving process boundaries throughout your domain in this early turbulent stage is going to slow you down when you inevitably need to move them.

Pushing infrastructure style functionality—such as logging or email delivery—out into services makes sense, but waiting to see how things develop seems worthwhile when it comes to the core domain. Initially focussing on understanding the domain and investing in getting changes out to production as quickly as possible is likely more important then developing loads of cross-process plumbing.

A monolithic application isn’t such a bad place to start. The trick, as always, is to know when to change that plan.

  1. In fact a brown field or system refresh project seems like an ideal situation to test the waters of implementing them.</span> These projects have a runway long enough to justify the investment required to put all of the required communication, deployment, and monitoring ligatures in place. 

Programming Books Worth Reading

17 September, 2014

Programming well is hard. Here are a few books that have helped me improve that I recommend.

Practical Object-Oriented Design in Ruby by Sandi Metz

Practical Object-Oriented Design in Ruby by Sandi Metz

This contains plenty of great advice even if you don't code in Ruby. It focusses in on the message passing aspect of OO and how to structure your code around that ideal whilst keeping it amenable to change.

Working Effectively with Legacy Code by Michael Feathers

Working Effectively with Legacy Code by Michael Feathers

This is really about all code and is full of strategies to isolate and deal with problematic code in large untested code bases.

Clean Code by Robert C. Martin

Clean Code by Robert C. Martin

A meditation on what makes code “good”. General advice that covers many aspects of code including readability, clarity of intention, and separation of responsibilities.

Effective Javascript by David Herman

Effective Javascript by David Herman

Short, sharp, and to the point advice for writing Javascript. Points out the rough edges in the language and gives you concise advice on how to deal with them.

The Pragmatic Programmer by Andrew Hunt & Dave Thomas

The Pragmatic Programmer by Andrew Hunt & Dave Thomas

A touch dated in areas but the core principles it espouses are still good and will hold true for a while to come.

Release It! by Michael Nygard

Release It! by Michael Nygard

A book focussed on “the last mile” in software. Getting your code out the door and setup in a way that you can monitor and change it. It also provides interesting techniques for dealing with production issues in distributed systems such as cascading failures.

Confident Ruby by Avdi Grimm

Confident Ruby by Avdi Grimm

A look at techniques to improve the readability and style of your code. Tips on elimating conditionals, using null objects, and more.

Practical Vim by Drew Neil

Practical Vim by Drew Neil

I've used Vim for a long time and this book taught me plenty. A must read if you use Vim as your editor.

The Little Schemer by Friedman & Felleisen

The Little Schemer by Friedman & Felleisen

A great way to learn recursion and some Lisp.