Anyone who knows me for long enough knows that I have a thing with keyboards, and two common questions that I get from my friends are
How many keyboards do you have?
You bought another keyboard?
Well, I thought really hard about it, and I think that I might have a convincing argument that might win you over.
It has been suggested to me recently that, since I’ve been buying and selling my electronic devices rather regularly, I should start doing some kind of reviews. And the more I thought about it, the more it made sense. I did have a go at it a long time ago, but ultimately did not follow through.
Well, this will not be meant to be a comprehensive review, as you will be able to find that in a ton of websites, but more of my own personal take on what I feel is good and works well for me.
As such, it will be very opinionated, as it should be. If you know me and trust my taste in electronics, then follow along for the ride, I promise that any disappointment is not intentional.
Over the past couple of months I’ve been working on and reading up extensively on microservices. Numerous medium articles, and 2 books* later, here’s just a quick summary of the important points that I’ve learnt.
*Building Microservices – Sam Newman / Microservice Architecture – O’reilly
The organization that you are part of is a very huge part of whether the microservice architecture (MSA) is suitable for your project/product or not. Conway’s Law states that software design often reflect the organization communication structure, unsurprisingly, the inverse holds true as well.
While not a fact set in stone, there is less resistance when implementing MSA if your organization embraces the agile culture. I feel that this is mainly because MSA is an evolution of Service Oriented Architecture (SOA). Having small teams with defined roles and objectives helps with separation of concerns and works in line with the technical aspect of MSA.
This is also closely linked to the organization and culture in general. MSA is not a magic bullet that could solve all the issues with the moving target problem. The team(s) need to take ownership of the service that they are building. There is no hard and fast rule that one team should only handle one service, but the team that built the service should be the one in charge of maintaining/improving it.
There are many other factors that I won’t delve into as the books do a much better job as putting the information across. But briefly, the other factors are as level
So you’ve thought through all of these factors and decided, “I think my team/organization is ready for MSA, where to start?”