Geecon has apparently caught its momentum, aspiring to be most recognizable conference brand in central Europe. I’ve recently attended the fourth installment this year – after TDD Geecon in Poznań, Main Geecon in Krakow and Microservices Geecon in Sopot the time came for Geecon Prague 2015. Here’s a bunch of insights after this event.
The hype around microservices is growing – a really big part of the talks was devoted to this particular topic. Another significant part of the lectures focused on the importance of testing on various levels of abstraction and the system architecture needed to make reliable tests achievable.
Since history repeats itself (I really recommend reading THIS article, even though it’s sooo long), there were some talks indicating that again – there is no silver bullet, which is what makes programmers sad, since […] is the most fun thing to do – everyone knows that. That silver bullet thing popped up in various talks. Ranging from quite obvious (but not so frequently asked) questions:
and whether (or not) your microservices architecture is just:
? (slides from presentation ‘Modular Monoliths’ by Simon Brown).
Christopher Batey – The Dangers of Building Microservices
A microservice is simple. You can recompile and restart it in seconds. If you stop liking the code of your microservice, you can rewrite it from scratch. Microservices are small, so they can’t be a big ball of mud, can they? The decomposition into a lot of independent services allows for easy testing. Ahh, the world of greenfield programming. No silver bullet. The microservice itself won’t be a big ball of mud by itself… but the vast network of connections between them can be. What a lot of people forgot was that one small word: network. Microservices are easy to test in isolation, but once you send the packets over the wire bad things can happen – and they will happen sooner or later, you can be sure. That is why you need to use tools and write tests which can handle and emulate situations like :
- slowly responding services,
- unresponding services,
- services responding quickly but the network slowing down for a moment,
- corrupt messages…
Saboteur, Wiremock, Hystrix.. you should try them!
Antonio Molina & Nick Zeeb – What I Learned Writing a Trillion $
An interesting story built around lessons learned during the development of a system that dealt with massive amounts of money going through Forex (up to 1900000000000$ during one year in their case). Is it even possible to work with such a (continuously deployed!) system without a 80% heart stroke rate per year among developers? It is. But it wouldn’t be without all the knowledge they’ve learned to this day. And some of the most important lessons are:
1.Test like crazy. They perform 10 000 acceptance tests. And many more unit tests. Micro performance tests. Meso performance tests. Macro performance tests. Failure tests. Data migration tests. Live tests on real market with small amounts of money. Of course it comes at a cost. 80% of development time. And…
But they discovered that it pays out in the end. Otherwise…
2. Sometimes less is more. LMAX discovered that in their case, spreading across multiple repositories brought more pain than gain. Also, the fancy ‘branch per feature’ attitude was ditched. Oh, and there is one slightly bigger company which is doing a similar thing right now:
There is also some team culture involved here: always try to develop the smallest working piece of code you can. And the whole team also tries to focus on the smallest achievable piece of functionality at a time.
3. Accept your inferiority at estimating the performance of your algorithms working in the world of deep stack traces. You know the big ‘O’ notation? That’s great, you can prove you were right in the performance test you’ll write. But one day it will prove you were so, so wrong, and this will allow to avoid the big ‘O’ on your face on the day of the release.
No silver bullets, but I’m going to attend Geecon next year to try and find one for sure!
author: Michał Wróbel
