Daniel Bryant in Coding 10 minutes

The business behind microservices: A less ordinary reading list

Here at notonthehighstreet.com (NOTHS) we’re always looking for less ordinary ways to innovate, both from a business and technical perspective. Although the current industry buzz behind microservices could be described as anything but less ordinary, we’re exploring the sometimes ignored business and organisational motivations behind this latest trend.

This blog post will share the beginnings of our journey into the exploration of the microservice architecture, and hopefully provide guidance for anyone else looking to start this journey…

Although many of us within the technical team are engineers at heart, we’ve grown more interested in the business and organisational issues over the past few years. We have also come to appreciate that we need to better understand these topics in order to build software that delights our users and customers.

Many people who investigate the microservice architecture have stumbled across the often quoted Conway’s Law in relation to the impact the structure of an organisation has to the design and implementation of software, and although this is a very useful rule to remember, it is really only the tip of the iceberg.

Rather than simply answer the question of what impact the business and organisation has on the implementation of a microservice architecture (and vice versa), we are keen to share with you a series of books that have helped us form an answer and also provided further insight.

The Connected Company - Providing Inspiration

Connected Company

The first book on our list discusses the difference from a business perspective between the traditional ‘command and control’ enterprise-style organisation, which the book labels a ‘divided company’, and the emerging autonomy-driven service-based ‘connected company’. The primary motivation of this book is to provide suggestions and techniques on how to move from one type to the other.

The Connected Company clearly shows that there are parallels between the business drivers of an organisation and the technical decisions of whether to implement a monolith or microservices. Although the book is very much focused on the business and human factors of creating a connected company, much of the advice offered here is also directly applicable for analysing, designing and implementing software.

Anyone reading this book will instantly recognise the ‘connected company’ archetypes, such as Amazon, Netflix, Spotify etc., which are also often referred to as the ‘DevOps Unicorns’. Whatever you may think of the companies, it is difficult to argue against their recent success, and this book provides a useful insight into several of the approaches and patterns used within these organisations to not only increase velocity, but also deliver what customers want.

Examples of the key trends discussed are the move from a hierarchical to holacracy-based management structure, and the move away from division of labour focused into specialised teams towards ‘fractal’ autonomous work units, the famous Amazon ‘two pizza’ team or a Spotify ‘squad’. Here at NOTHS we work in small cross-functional product teams (partner, consumer, delivery etc), but we don’t yet have a cool sounding name for these teams…

The author summarises that a ‘divided company’ is predictable in stable environments, and a ‘connected company’ is adaptive in uncertain environments. This is great food for thought as to whether the microservice architecture is appropriate to your organisation. As our business is focused in the uncertain and constantly evolving e-commerce market, we believe that the microservice approach is worth investigating further.

The discussion of these topics is a great primer to learn how to determine if your organisation would benefit to the move to microservices e.g. are you competing in a market where ‘speed wins’ and the ability to adapt is paramount to survival. If you do decide microservices are for you, then this book will provide a great introduction to some of the challenges you may face from a human and organisational perspective, and will also offer very useful guidance.

Domain Driven Design

Domain Driven Design

Adrian Cockcroft (of Netflix fame) recently proposed at Dockercon that microservices are ‘loosely coupled service-oriented architecture with bounded contexts’. ‘Domain-driven Design (DDD)’ is the original DDD book, which also introduced the term ‘bounded contexts’.

The core premise of the book is that it is essential to correctly model the business processes within any software deployed. The use of a ‘ubiquitous language’ throughout the business and tech team is thoroughly discussed, as the creation and use of entities, aggregates and value objects, and dividing the business process model into bounded contexts of logically grouped code.

Here at NOTHS we have been utilising DDD for quite some time, and we recognise that although some parts of the business are easy to model in code, others are not, and we are making efforts to increase the understanding of DDD throughout the organisation. Just recently several of us in the technical team presented a guide to DDD for the product management and UX teams. Hopefully we may share details of this presentation soon (please let us know if you are interested!)

In our current experiments with microservices we are starting to see benefits of implementing bounded contexts as small services. Although it’s obviously possible to implement DDD when using a monolith, it can be easier to ‘cheat’ with a single codebase by allowing contexts to overlap and blur with each other, and ownership/accountability of code changes can be easier to abuse.

Implementing encapsulated services which expose functionality through a coarse-grained API allows us to create ‘hard’ (technical) boundaries, which can also promote increased inter-team communication, for example, when a service API change is required by a consuming team.

In summary, ‘Domain-driven Design’ is essential reading for anyone looking to understand the motivations of splitting a code base into a collection of encapsulated contexts that are organised around business functionality (archetypal ‘microservices’?), and also provides techniques on how to model and implement this.

The Phoenix Project

The Phoenix Project

This a a classic-in-the-making novel focused around DevOps and ‘lean’ methodologies, which was inspired by ‘The Goal’. This book provides a great overview of the Theory of Constraints and the business motivations behind the current DevOps movement.

At NOTHS we think is would be easy to argue that before an organisation can properly implement (and leverage) a microservice architecture, the notion of agility (e.g. XP, Scrum) within the SDLC must have fully been embraced alongside DevOps-inspired practices, such as continuous delivery, automation, infrastructure as code, and real-time monitoring.

We are big supporter of agility at NOTHS, and we embrace extreme programming, including pairing extensively when working with code. We have also invested heavily into continuous delivery, and release to production several times per day (using git, Jenkins, Capistrano and OpenStack)

This book comes highly recommended, and will provide a great primer to the foundational DevOps methodologies from a business perspective.

Architecting the Cloud

Architecting the Cloud]

Many organisations are now embracing ‘Cloud Computing’, whether it be private cloud created within an internal data center, public cloud such as AWS or GCE, or a hybrid of the two.

At NOTHS we run our platform on a combination of private and public cloud, and we have definitely seen the benefits in terms of scalability and reliability.

Microservices, DevOps and Cloud are also often packaged together as the holy trinity of agile software delivery, and this book provides a superb business-oriented overview of cloud computing and the deployment models available.

Topics covered include cloud service models (SaaS, Paas, IaaS etc), architecting for the cloud, data and security considerations, SLAs and monitoring, and the organisational impact of the cloud model.

In Summary

We begun our experiments at NOTHS with microservices late last year, and we wanted to share some of our reading (and the initial journey) behind our decisions and motivations. At NOTHS we take great pride in being less ordinary, and although the topic of microservices is becoming mainstream we are definitely seeing some unique benefits, both in the business and technical teams, with this style of architecture.

We’re keen to keep exploring, and we’ll keep everyone updated on our progress via this blog. We would love to hear your thoughts and feedback on this article, and so please do get in touch!