Ok, I think after writing the last article, I generally understood: The usage of Microservices is good because it makes your IT landscape very flexible. Changing them is easy, testing them is easy, redeploying them takes in best case seconds. If you use them successfully, this advantages help you to deliver new features quickly to your users which nowadays is key in the competition.
When reading further articles about the topic, I found some interesting reports about big tech companies using microservices productively. That’s pretty interesting because reading theoretical books is one thing, but gaining insights and experience reports of real usage is another level of information.
One prominent early adopter of the microservices-approach is Netflix. Originally, this article was supposed to cover several copanies and their IT philosophies. But Netflix has is too interesting to write less than one article about it.
The streaming-company seems to like that role as leader – they are giving quite a lot of information about their experiences around the microservices architecture. Plus, they even share (some of) their programs with the rest of the world as open source on github!
There is one very good talk (takes 50 minutes) where a guy who introduces hisself “senior lots-of-things engineer” tells about the way Netflix manages its highly flexible IT landscape:
And besides making the time quite entertaining, he presents some numbers that made me rest for a second… the most shocking ones:
- 1000s of daily production changes
- 100.000s customer interactions per minute
- 10.000.000.000 (10 billion) hours of streamed videos in a quarter!
- they run that world with only 10s of operations engineers
One reason they have so few operation engineers is that the developers are responsible for running their code on their own. That should motivate developers to keep the software easy supportable plus it brings the expert of the software right to the error point instead of making an generic administrator making understand what this specific piece of software is meant to do… and here it is, the “you build it, you run it”-paradigm that you hear in every discussion about DevOps.
The developers (or probably, “software engineer” is really a better word here) are on call 24×7 – I understand why they do that, but I think it’s also a quite hard rule.
It’s remarkable how many insights they got over their service landscape, they created quite a bunch of applications on their own for themselves… you need to have some of the better developers in your team to gain that.
That Netflix has humor is quite good visible in their creation of the Simian Army . An army of monkeys kills instances and even nodes on purposes to kind of train the cloud solution for crisis. ( I think the monkeys are only a metaphor and in reality, they have programs for that… but how cool is the illustration? )
Good idea, but boy you have to have balls for training monkeys to shoot on your own productive landscape.
It is also worth an extra line of text to mention that Netflix’s blog article with Simian army’s introduction is from 2011. So they are already in the game for quite a while.