I am a Principal Architect working for Senacor Technologies, a German consultancy. If this sounds like Powerpoint and Excel, well, in that case think of me as a regular software developer.
Microservices were practically unavoidable during the last couple of years. First – as always in our industry – presented as the solution to all our problems, and as reality came back into the discussion, as something that may involve certain tradeoffs. Especially if you leave Greenfield-projects and Hello World-projects behind you.
Ah, and I am a father of three and a total football nut!
As developers (and architects) we tend to jump unto the latest bandwagon. This talk is about anti-patterns and tradeoffs that we encountered in various rather large projects within the financial and insurance industry.
I don’t believe that what I am talking about is terrible innovative or new, but rather well known. Nevertheless, we sometimes ignore lessons learned and keep burning ourselves time and time again.
I try to look at the errors we keep repeating and hope that we all have a couple of laughs while doing so.
For me, architecture is mostly answering the question: “how do I want people to communicate when working together”. I was approached by a fellow coder, who thought I was discouraging the use of microservices. To be clear: I am not! As with every tool, we just need to be aware of the tradeoffs.
To cut it short: if you are working in an agile software delivery process, then my first instinct would be, that microservices could be a good fit.
Basically: “It depends”. Maybe I should come up with a talk “Microservices are hard, but so is your Monolith”. There are no easy answers.
Beware naive advice. Beware silver bullets. Always keep in mind, that success stories always come with an untold story… something like “we needed 5 years of hard work to get where we are”
#microservices #epicfail #resumedrivendevelopment