I’ve done a lot in the first few months of this year. I left my job at the BBC, I moved to Berlin, and I started working for SoundCloud.
I recently spotted @KingScooty‘s monthly retrospective article, and thought I’d steal the idea for myself and use it as a way of not forgetting some of the interesting code-related stuff I’ve come across recently.
In a world of microservices, your application might do something like this: parse a request, do some work, and send a reply. At either end, you’ll be spending some time and effort (computationally) to convert between objects and the representation of your choice – JSON, for example.
If you have lots of small services in a chain, then you’ll be repeating this cycle of parsing and serializing at each step, which starts to look inefficient.
Interface description languages (IDLs) allow us to model interfaces in a way that is language-independent. For example, Google’s protobuf will allow you to create a
.proto file, which you can then compile into class files for the language of your choice. Clients exist for Java, Scala, Go, Ruby, and a variety of other languages.
Objects that are created can be serialized in a binary format, transmitted over the wire, and deserialized at the other end. The reduced size of messages provides an advantage, and the binary format makes the conversion back into an object much quicker. But, the messages themselves then become more difficult to inspect – you can’t inspect them as you would with JSON or XML.
Everyone’s favourite buzzword at the moment. SoundCloud are pretty big on microservices, and the team I’m on are starting to spin out parts of our large Rails monolith into smaller, separate services. Whilst I’m familiar with the concept, I’m starting to learn more about the practicalities.
To me, complexity seems to increase with the number of microservices. Sometimes it’s difficult to see exactly where failures are coming from, or what is causing them. Zipkin can trace individual requests through the network, and is a useful diagnostic tool. Prometheus, an open-source monitoring tool produced by SoundCloud, also gives us a clearer view of which services are doing what.
Here are some other articles and videos I’ve read and watched recently, which don’t quite fit in above:
- ‘Your Server as a Function’: a paper which explains some of the mentality behind Finagle. Marius’ talk from SBTB 2014 on Functional Systems touches on this as well, and is worth a watch.
- docker-compose: Seems like a nice way of spinning up some containers for all the different dependencies of your application. Pretty useful in a world where your service relies on several other services to function.