The Organisational, Architectural and Operational Challenges with Microservices

Microservices are the new shiny…

(Please note that if you have arrived here looking for my muCon 2015 talk, then this blog post talks about an old version of the presentation. The new slide deck is here -> “muCon2015: The Business Behind Microservices (Redux)“)

The perfect storm that has developing in the software development industry has helped greatly, and the issues with working with monolithic codebases, the associated value stream challenges (as documented by Phil Calçado), the prevalence of complex enterprise integration products, and the emergence of economically beneficial and operationally flexible (API-driven) cloud infrastructure has led many organisations to conclude that microservices are the only way forward. However, are microservices a good fit for every problem? One of the benefits of working at a consultancy such as OpenCredo is that we get to work with many companies that have made such choices before our arrival. After we have identified issues specific to each client, and worked with them to address these, we have the benefit of being able to identify a series of patterns. We believe we are now in a place to offer some advice on making the decision to implement microservices.

The presentation accompanying this blog post addresses these five issues in relation to implementing a microservice-based architecture:

Organisation design. Is your company a divided company or connected company?
Is your business ready? Is everyone aligned on the mission, are you agile, and is your planning process correctly leveraging IT as a competitive advantage?
Microservices and the need for speed. If you are a startup and still searching for product/market fit, then adding additional architectural and operational overhead to developing software may not be the best approach.
Architectural/design skills. Creating software as microservices will not compensate for fundamentally poor architectural skills, and on the flip-side, many companies have created such well-architected monolithic applications that they do not require further decomposition in order to meet current business and technical goals.
Operational maturity. As Martin Fowler has highlighted, there are operational prerequisites that must be adhered to before microservices become a viable delivery vehicle for business functionality.

Conway was telling the truth – deal with it!

No microservice presentation is complete without a mention of Conway’s law. As with many cliches, there is some truth to this, and several prominent members of the microservice community, including James Lewis and Raffi Krikorian, are advocating the use of the ‘inverse Conway manoeuvre’, where the organisational (team) design can be used to influence the software architectural design.

The anecdotal evidence for the benefits of creating cross-functional teams is also rising. These teams are typically long-lived and product-focused (as opposed to ephemeral and project focussed), and this allows an organisation to assign responsibility and stewardship for high-level business objectives and KPIs. In the presentation I talk about how Spotify, Amazon, and Gilt have implemented this very successfully.

All technology problems are people problems

This chapter of the presentation looks at the importance of business strategy, and here I heavily reference the great work of Simon Wardley, which includes copious advice on situational awareness and mapping, project management/delivery styles (agile vs lean vs Six Sigma), and enabling innovation. Drawing from my experience of running several microservice projects, I strongly recommend the creation and sharing of the vision, goals and associated KPIs (OKRs, CSFs or whatever you fancy). In addition to Simon’s work, I also draw upon the great books ‘Lean Enterprise’ and ‘Agile IT Organisation Design’.

I’m a strong advocate for the need for the architecture role within a team, and following the lead of Simon Brown, I typically recommend the inclusion (or development) of the hands-on master-builder type architect role within an organisation. This role has a need for good people skills, and the ability to communicate (verbally and visually) both business and technical goals to appropriate parties is essential in order to create shared understanding and ‘just enough’ upfront design. Both James Lewis and Sam Newman have also talked about the shift in architectural focus that comes along with microservices, and designing for replace-ability, scalability and fault-tolerance is vital. Standardisation and guidelines should also now typically focus on the underlying platform and glue between services, rather than within the code of the microservices itself (although this isn’t an excuse to be sloppy!).

At OpenCredo we appreciate the benefits of programmable infrastructure, and have been investing in this space for quite some time. However, many of our clients have not taken this approach, and this is often where we start in addressing Martin Fowler’s microservice operational prerequisites (using tooling such as HashiCorp’s Terraform, Ansible, Puppet etc). Experience has also taught us not to underestimate the people aspect of operations, particularly when running and maintaining services running in production. Here we subscribe to the thinking of Mikey Dickerson, and I base a lot of my recommendations for day-to-day operational running on his ‘hierarchy of reliability’.

Change management without the doublespeak

So, all this talk of microservices has got you interested in implementing this within your organisation, but how do you go about this? At OpenCredo we have helped many clients with transformation projects, and a key theme is always change management. This topic may have got a bad rap outside of the domain of business, but there is serious value to be had here for IT and associated technologists, especially if you are looking to implement lasting change.

In the presentation I talk about techniques learnt from the HBR books and magazine, which I have applied with good success. Key takeaways are the need for fair process, implementing transformation as a process (not simply as an action), and the need for clear communication. I also value the notion of teaching by showing, and at OpenCredo we regularly work closely alongside developers, QA specialists and operators within an organisation we are helping.

In my experience, leadership is also often an undervalued skill within IT, and I close the presentation with a call to action around this. I also recommend several project management techniques, such as the MoSCoW method, the RASCI matrix and RAG status spreadsheet, to help manage (and lead) the relationship between the business and IT.

In conclusion

You can find the video and slides of the ‘business behind microservices’ presentation below, which shares many of my learnings working with clients who are implementing a microservices-based platform. Hopefully you have found this useful, and if you have any comments or questions then please do let me know. We are also always happy to work with new clients, and if you are thinking of evaluating or implementing microservices (or are stuck doing this), or are looking for guidance and leadership around organisational transformation then please do get in touch at info@opencredo.com or directly at daniel.bryant@opencredo.com.