While It’s Compiling is a series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.
Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.
This week we spoke to Russ Miles, Principle Consultant at Simplicity Itself. His experience covers almost every facet of software delivery – having worked across many different domains including financial services, publishing, defence, insurance and search. Most recently he has been an evangelist for microservices and formed the London μServices (Microservices) User Group.
Russ will be speaking on the Origin of Services by Means of Natural Selection at μCon, London’s first microservices conference.
1. What projects are you working on right now?
Right now I’m working on a couple of projects that are distinct but related. One is a new microservice-based architected application that provides sentiment analysis based on a number of chat and social sources. The other is what I’m hoping will be a new open source project eventually, which takes some of the overhead associated with building antifragile software with microservices and makes it easier to work with.
Both projects are exciting, but obviously there is a lot to be considered in the latter project, especially when you want to get the advantages of microservices and antifragility without the necessary headaches of making that happen.
The aim will be to enable developers to focus on what they actually need to build, and the majority of the non-functional concerns associated with microservices and antifragility will be handled by the toolkit.
2. There has been a lot of talk about microservices lately. Why do you think it will be so important to the programming community?
Great question. I think the answer to this is probably four-fold, so please bear with me!
First, let’s dispel some confusion. Microservices are single-purpose services that typically expose a uniform subset of interfaces, such as messaging or HTTP, but there’s really no concrete restrictions there. The most useful analogy is to the unix command line tools.
The key power of unix command-line tools is that you can take these single-purpose, command-line tools and string them together, piping the output of one into the input of another in order to deliver. Each of the tools does one thing, does it well, and supports a uniform interface to one another. The tools do not typically share state with one another, other than the uniform interface handoff, as they are connected together using pipes.
The exact same design approach is taken with microservices. By using a uniform interface, such as HTTP and REST as a style, or even Actors/Reactive applications, various applications can be simply composed in order to build an application.
This leads us to the first main important contribution from microservices: they are simple, single-purpose but autonomous services that aim to offer a uniform interface where appropriate. That’s not a landmark difference to other approaches, but it’s an important starting point.
The second contribution is more important, and has everything to do with beating what I call – based on a phrase coined by Rich Hickey – the ‘Elephant in the Standup’. The key feature of the Elephant is that all of the decisions and assumptions you’ve made prior to today that are manifest in your growing ‘legacy’ codebase will be in conflict with the change that you need to embrace today, tomorrow and going forward.
There are ways to manage the ‘elephant’. Evolving a codebase and system over time is difficult if all parts of it have to be evolved at the same rate. There are various modularisation techniques out there (OSGi springs to mind) that technically can help primarily with attempting to modularise and build services inside of an application. There is some merit to these approaches, and we’re looking to include some discussion on that at muCon for that reason.
From an architecture and design point of view, the Life Preserver tool that I teach in the “Antifragile Software with Microservices” course provides an approach to modularity and design that can be applied regardless of the final deployment choice. These techniques prepare your existing monolithic applications better to accept and possibly even embrace change, but you can go further.
Microservices are a natural design approach that really give you the full power of embracing change as you are able to evolve parts of your application that change at similar rates, typically microservices, at the rate at which they need to evolve at. Breaking apart the monolith, a microservices approach takes the modularity that can be designed using the Life Preserver and applies it to the choices around version control and deployment strategies. This enables applications to evolve, even at runtime, without having to introduce onerous, monolithic and robust all-at-once strategies.
With microservices it is entirely possible to build applications that don’t just embrace change, but that can thrive on it. This is the essence of achieving antifragility in software, i.e. software where its architecture and design means that it gains from accepting the natural disorder and chaos of its runtime. Antifragility requires more in terms of non-functional requirements and even represents a different philosophical approach to software (more on that in my course and at muCon) but it is an extremely valuable step, as it has been shown to lead to the final important contribution of microservices: Enabling Speedy Innovation.
The outcome of achieving an architecture, design and runtime built of micro services that exhibit antifragile properties is that it encourages change rather than resists it. This is the big business payback of doing this work in the first place. Companies are seeing that they can compete through innovation faster than their competitors by adopting antifragiltiy and microservices, as their software can keep pace with the demand for change inherent in innovation. The software can change as fast as the business needs it to, and in the future (even, arguably, now) this will separate the winners from the losers.
So microservices is not just a buzz-word. It has real potential to tame and beat the elephant in the standup. What’s most exciting is that there is already evidence of this; we’re really not talking about vapourware promises for once!
3. What was your first programming language? What drew you to it?
BBC Basic, and I believe I was drawn by one of the most truly awful teachers of computer science I ever had. I actually received a comment from my teacher on completing my GCSE work on a program in Basic that I should “stop, as I don’t understand code that much so you’ve achieved the best grade I can give already”. Probably my first experience of ‘overproduction’ as a Lean Waste!
After that, it’s probably best to talk about the language and platform that has somewhat ruled my life, which would be Java and the JVM. Despite a lot of general beating-up of Java – some of it justified – I am still very happy with the language, although on a regular basis I use any number of the following: JavaScript (Node, Browser), Ruby, Python, Groovy, Clojure, Scala, C#…In fact, due to microservices offering a wonderful mechanism to choose the right language and platform for a particular small service, I’ve found that knowing the strengths of various languages and platform pays huge dividends when building systems constructed that way. It’s only getting more fun, and my enthusiasm for different languages and platforms finds a pragmatic edge in microservices.
I’ve even coded using assembler and Ada (83 and 95 variants) for fast jets such as the Harrier and Typhoon, but I rarely shout about those languages too much these days other than to admit my age.
4. What is one piece of advice you’d like to give to new programmers?
Enjoy learning and read two books at the same time (not exactly at the same time, but in parallel). One book technical, one book as far out of your comfort zone as you can go. I’ve lost count of the number of times I’ve found something in a non-technical book, both fiction and non-fiction, that has influenced the architecture, design and code that I write.
Also remember that you are primarily writing code for other humans. It’s a skill that has a lot of similarities with writing articles and books, and so if you consider the reader as much as possible you’ll do well in this industry.
One last piece of advice: tests and test-driven development will help you write only the code you need, but it works hand-in-hand with the thinking and communication exercise that is architecture and design. The two work together; TDD does not supplant thinking! Remember, thinking is a massive amount of what we do, more than keyboard-ballet!
5. What would you like to ask the community?
What questions do you have on antifragility, building antifragile software, and microservices as an architecture and design approach?
I’m also always very interested in speaking to anyone who has thought about how one’s philosophy affects their software. I’m a big believer that our philosophical underpinnings, even if we don’t consciously analyse these things, lead us to the processes, architecture and design of how we deliver software. I’m always keen to hear people’s thoughts on that.
What do you want to know about antifragile software? Tweet us at #whileitscompiling or @skillsmatter.
Russ will be talking about the Origin of Services by Means of Natural Selection at μCon – check Skills Matter for updates and tickets!
The Skills Matter Blog 
One comment