Architecture & Microservices
The panacea that can fix slow delivery teams
Key Points
There is no panacea! Having them or building them does not fix all technology sins.
Beware the implications, including operational and security aspects.
Architecture needs to suit and support the organisation and its strategy.
If executed poorly, the outcomes can be worse than what the now unpopular 'monolith' might deliver.
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.
    Author
    Andrew Todd
    These are my personal views based based on practical experience, influenced by aspects of my professional life, work engagements and often curious discussions with those I see as software, technology, leadership and strategy experts.
    Initially published on 03 July 2024