Microservices: The Matrix and The Architect
Maybe one of the most infamous and crucial characters of the movie series which made geek = cool (thank you Cohen brothers!) was “The Architect”.
Everything happening in that virtual world was of its design and reflected a structure which was designed to satisfy the needs of all (well…) of its “forceful” — some more than others — hosts, thus infamous.
But even the infamous Architect understood that its survival depends on how happy he can make his hosts to guarantee its own survival — I accept this isn’t the best metaphor but fits nicely in the 7 pillars:
Vison, Empathy, Collaboration; Adaptability; Autonomy; Governance.
Microservices implementation requires a lot of re-thinking; re-engineering; re-code etc…
It’s not one single person to do it it’s an organisational shift with sponsorship and vision from above.
The Architect or even better the Architect Board are working with the business and the teams or squads to ensure the transition is done successfully.
Going from SOA or Monolith architecture to a Microservice Architecture will mean huge changes and challenges.
Your approach is key, gradual change can be made and implemented which will benefit and ensure its gradual success.
First things first, counter-intuitively, and sound sense is to identify 3 main areas, 1) Strategic Goals 2) Principles and 3) Practices.
Strategic Goals are aligned with the business outcomes and needs, it’s non-technical and influenced by the company heading and values to the high-level goals.
This will be naturally influenced by your organisation's departments and divisions.
Principles aka Rules are influenced the identified and conceptualised goals.
The same good Principles are size matters, “Fit a Poster”; “Fits in my Head” means small and easy to remember with a reduced nr, maybe 12 like recommend by Agile to ensure they don’t overlap or repeat themselves.
Golden rule very much like in Agile Methodologies, should reflect the kind of culture you want and aligns with your goals, make sure people first over-processed or tools, and the rule of thumb is don’t push it or you do it wrong.
Let's talk about Practices, here it’s also influenced by the above and the main objective is to support the principles you have established ex: if you are using containers then use best practices, agree to use RestAPIs for all communications; the lines of code MAX for a service; sizes of teams; etc.
As an Architect your main functions are, to build the team and help and coach people to take ownership, ensure the vision and strategic goals are being executed, and teach and coach how to do it as opposed to do it yourself which ties in nicely with ownership.
A good practice is to also do a bit of coding with the teams as opposed to just doing meetings.
This will ensure you are spending time with the teams and aware of the progress but also verify how well the principles and practices are practical and helping (or not) your teams allowing you to further change for the good of everyone.
There will be some trade-offs which you have to be aware of, with such a distributed architecture monitoring is a challenge to pinpoint issues and performance bottlenecks, this requires different skills and solutions since alerts can be an effect but not the cause build Continuous Improvement into your monitoring systems.
Interfaces are a great idea to save time but can create unwanted dependencies un-welcomed when you are building services that you want to decouple so control that integration and look for the tradeoffs.
Technical debt will happen and sometimes a team owning a service can find itself without the knowledge to handle the service when team members shift so watch out for this with a log or other preferred model.
A possible solution is to uniform the stack and create your own development on top of that stack, great if you are open sourcing your team's work which ties in nicely with excellence because it’s now public too.
Governance is crucial (yes you have to) to keep documentation in a useful state and create a service template to ensure you make everyone's life easier, as with everything this is important and relevant to what everyone believes to be the best principles.
A key point to mention, with many things and Governance especially, it’s good to have your Architecture Board working with, the sum of knowledge is wiser than one.
With the board we can better understand Priorities; Direction; Needs (business/teams/skills); Conditions and Options which allow bettering decision making, a more cohesive performance monitoring of the teamwork and business success and progress especially if we are talking of large change etc.
I want to end with one note which is crucial and sometimes put as secondary from my experience.
Were there are trade offs there are limits.
One such which is pivotal to your success is the happiness of your teams, don’t lose sight of why you are doing this transformation and the business is nothing more than the reflection of an organisation and the people who make that same organisation, talent is hard to find attract and maintain if you don’t have a clear vision for it and you don’t want to end up with a Ferrari without parts or mechanics to keep it FAST!!!
