A little while ago I summarized some great articles and experiences with microservices. As it continues it’s travel along the hype cycle new excellent (and balanced) stuff is coming out, so I just thought I would add some of them.
I think these articles go more in depth about the trade offs and reasons behind choosing to build a microservices architecture. So read this post before you go back and review the ones in the first part. 🙂
These are the guys that had videos in my first post. Go there to see them. 🙂
I’ve been working with Microservices for the last couple of years. It was kind of an uncharted territory back when we started. But the attention on the net and in the community has increased a lot over the past year and this spring and summer brought quite a few sobering experience reports. It is definitely not failing, but there are some real considerations to be aware of, and some of them are quite major non-technical issues. Culture and organisation needs to be changed to support working in a highly distributed manner with Microservices.
So if you’re considering Microservices, you’ll be in for an exciting ride. For many it makes sense, but do read these articles and watch the videos to make sure you don’t just make a gigantic leap of faith. Being prepared for the issues will help you move forward when the going gets tough. 🙂
So here we go:
And if you have only two hours, watch these videos. A very clear message by two very good speakers:
If you’re Norwegian speaking you might also want to check out our talk about our experiences at my current client: https://vimeo.com/album/1807533/video/105777592 .
Let me know what I’ve missed. 🙂
I was reading an interview with Renzo Piano in this fridays issue of D2. He is one of the most revered architects of our time and is responsible for many great buildings, amongst them the Pompidou centre in Paris which was his first big break through. He is known for his innovative ideas, but also his very good technical and functional execution of the designs. He was interviewed in connection with the Tjuvholmen project in Oslo, and one of the quotes was just spot on (my translation):
My fundamental reason has it’s origins in my builder background. To me, architecture is a craft. You can’t separate the idea of a building from the execution of it, even though a lot of architects act like it. This has been catastrophic for architecture. – Renzo Piano
In the software world there seems to be a notion that you can draw the architecture, and then let someone else design the details. Because it is based on high level ideas and sometimes faulty assumptions it becomes a resistance for building a good solution, in stead of enabling a solid foundation. Stop separating the architecture from execution, and make sure it is something that is flexible and evolves as execution moves forward. In other words: Architects need to take part in the execution to see the constraints the architecture imposes, and see new opportunities for the architecture to evolve into.
I’m not going to go into that rant now, that’s content for another post, but that also means that the architecture must be evolvable. And less code is more flexible than a lot of code. Strangely enough most architectural constraints tend to lead to more code, not less. 🙂