When discussing microservices, essential reading is the insightful article written by Martin
Fowler over a decade ago. If you don't read the whole article, at least review the table of contents.
It highlights characteristics of a microservice architecture and provides some insight into what
should be
considered before deciding if this is the right architecture to implement.
You'll notice that there are non-technical aspects that must be considered!
you should read this now:
Microservices
Background
I've long been an advocate of using microservices as an architectural choice, even before Martin and
James published their renowned article. I've spent countless hours discussing microservices with software engineers,
tech leads, architects, product managers, and even CEOs.
These conversations often revolve around solving issues with existing systems,
such as the monolithic nature of their current architecture or the 'slow delivery speeds' of teams
due to the lack of microservices.
Conversations
As a CTO, I expect to have these conversations.
They're an excellent opportunity to learn more about the challenges teams and businesses face.
I enjoy discussing the impact of technology, architecture, and people on products and businesses.
Recently, in my interactions with new and potential clients and former colleagues, microservices have
become a topic of discussion.
These discussions typically highlight two perspectives:
Microservices are needed to fix issues with existing
systems such as performance problems or excessive complexity slowing delivery.
Microservices bring too much overhead,
making the environment too complex for the size of the business and its software needs.
A challenge
This presents a clear challenge. The architectural choice of microservices is often seen as a panacea for current software implementation issues. However, the consequences of this choice are not always well communicated, understood, or managed throughout the software's lifecycle. All software and architectural choices have consequences that need to be understood and managed over time.
There is no panacea for designing, building, and running software. It requires capability, competence, focus, and hard work throughout the software's life.
A Way Forward
Microservices may be precisely what is needed!
However, there are essential questions that need to be asked and answered before coding begins. If you don't know the questions to ask, find someone who does. If you can't get the questions answered, find someone who can provide the answers.
So, what are the questions? There are many. Here are some to start with:
What is the documented business strategy and plan? This provides context.
Does the documented technical strategy provide a north star and vision aligned with the business strategy?
What is the capability of the team or partner delivering the software?
What are the current friction points, and what technical lead indicators can offer insights into upcoming challenges?
What is the size and scale of the business today, and what are the leading business indicators for realistic growth trajectories?
What is the business's data strategy?
What are the security profile and requirements of the business?
These questions might seem abstract and unrelated to architecture. But architecture is foundational, the
basis on which more is built. It's one of the most important aspects in technology and better decisions on
architecutral design can be made if great context can be provided.
Great software can be built and deliver significant organizational and customer value if approached with consideration, skill, focus, and passion. These attributes are crucial regardless of the architectural approach.