Geecon has apparently caught its momentum aspiring to be most recognizable conference brand in central Europe. I have recently attended the fourth installment this year – after TDD Geecon in Poznań, Main Geecon in Krakow and Microservices Geecon in Sopot the time has come for Geecon Prague 2015. Let’s go with bunch of insights after this event.
The hype around microservices is still on the rise – the really big part of the talks was devoted to this topic. Other significant part of the lectures was about importance of testing on various levels of abstraction and system architecture needed to be able to make reliable tests achievable.
Since history repeats itself (I really recommend to read THIS article, even though it is sooo long..), there were some talks indicating that again – there is no silver bullet, which is what makes programmers sad, since […] is most fun thing to do – everyone knows it. This silver bullet thing was emerging in various talks. Ranging from quite obvious but not so often 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. They are small so they can’t be a big ball of mud can they? The decomposition to a lot of independent services allows to test them easily. 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 at first was that 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 :
- slow responding services,
- not responding services,
- fast responding services but network working slow for a moment,
- corrupt messages..
Antonio Molina & Nick Zeeb – What I Learned Writing a Trillion $
Interesting story built around lessons learned during development of system dealing with massive money amounts going through Forex. Namely 1900000000000$ during one year in their case. Is it even possible to work with such (continuously deployed!) system without 80% heart stroke rate per year among developers? It is. It wouldn’t be without the knowledge they’ve learned till this day. And some of the lessons I noticed are:
- Test like crazy. They have 10 000 acceptance tests. And many times 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 at the end. Otherwise… : 2. Sometimes less is more. LMAX discovered that in their case spreading across multiple repositories brought more pain then gain. Also fancy ‘branch per feature’ attitude was ditched. Oh, and there is one slightly bigger company which does similar thing now : There is also some team culture involved here : always try to develop as small working piece of code as you can. And the whole team also tries to focus on the smallest achievable piece of functionality at time.
3. Accept your inferiority at estimating performance of your algorithms working in the world of deep stack traces. You know the big ‘O’ notation? That is great, you can prove you were right in the performance test you will write. But some day it will prove you were so, so wrong, and it will allow to avoid big ‘O’ on your face on the release day.
No silver bullets, but going to attend Geecon next year to try find one, for sure! 😉