When it comes to building digital services, there’s lots of chatter about microservices. It’s a recent way of thinking about software architecture, and it can be hard to find a clear explanation of what it means.
It’s as much about people as it is about technology: we are in the midst of a pattern of transition from brittle pyramids of control to resilient networks of collective responsibility.
This article was originally published via Medium.
So, services and microservices: what are they, and what’s the difference?
Services vs Microservices
The simplest language I’ve found to contrast the two is: a service is a whole, a microservice is a part.
Notice not all the parts are microservices. Microservices are one kind of part for your whole. They can be all sorts of shapes, sizes and colours. What’s inside a service can and should change over time. More on this later.
What’s a Service?
A service serves a user. It’s a whole. The user could be a person, or the user could be another service.
In the case of digital services, the word service can be thought of as equivalent to a DNS name. Whether you’re headed to google.com or gov.uk those names let you to reach the service you’re looking for. The technology–in fact pretty much everything–behind those names is diverse and could change from day to day, or minute to minute.
From load balancers to legacy systems, from firewalls to functions, technology design is specific to the job being done and the context it’s being done in.
The provider of a service will work independently to understand and meet your needs. As a user, a good service will work for you, communicate in your language, help you meet your goals in a way that makes sense to you and do the hard work to make it simple. As a service, getting out of the way and facilitating users getting on with their lives takes disciplined ambition, genuine curiosity and a healthy dose of humility to do well.
What’s inside a Service?
If you look inside a service, you’ll find any number of different things going on to fulfil that service. Some of these things are likely to be microservices, others can be pretty much anything. It depends on the specifics of the service.
Typically you’ll find databases, file stores and connections out to other services, like notifications, payments, addresses, maps – pretty much anything that can help externalise capability, and minimise the work done on things that aren’t core business to that service.
A service is literally a web of systems.
The service owner (usually a person, team or organisation) is responsible for designing the best possible—I would say the simplest possible—way to provide the service in a way that serves the user, is reliable (if that’s important) and minimises both the time to value of what’s being built and barriers to change over time. These are good ways to help what gets built stay focused and keep relevant.
The world keeps moving on and you need to be able to keep on adapting. Maintaining your ability to update, and replace and remove the parts that make up your service without disrupting users, is great.
One of my favourite design principles is “Be consistent, not uniform”. Know your purpose in all things (be consistent) but express that purpose specifically and contextually (not uniformly) in each situation, and for each job to be done.
Microservices work together, along with other components, to fulfil the service, much like an agile delivery team.
Just as people in a multidisciplinary service team each bring unique skills, experience, background and humanity to a collective shared goal, so each technical component of a service brings something to a shared goal of serving users.
The collective is the unit of delivery
Echoing micro and macro scales, if microservices are team members, services are teams, each with a clear area of responsibility. You’ll want to get to a network of independent, autonomous teams – working transparently and relating healthily to each other – if you want to be able to innovate and move at pace.
You may have spotted my sketch above references the logo of the Ubuntu operating system. Ubuntu philosophy is often translated as “I am because we are” – independent parts that become fully realised in relationship to others in a collective endeavour.
The more I work in digital transformation, the more I see the word for where we’re going is ‘collective’. As in tech, so in life. So you’ll see the pattern of transition from brittle pyramids of control to resilient networks of collective responsibility echoed wherever humanity is building systems: technology, teams, organisations, nations, power grids, food distribution networks, the Internet. I particularly like @jukesie’s thoughts on the atomisation of organisational structure as a way to move past monolithism.
Where mindset is transformed you’ll see the pattern expressed intrinsically, naturally – fruit ripening in season.
As monolithic software transitions from slow, central coordination and control to a dynamic network of fluent, independent and interrelated microservices, so you’ll see centralised command-and-control organisations transitioning to networks of teams working transparently in the open.
For example, where an Enterprise Service Bus used to hierarchically manage interactions between technology components, you’ll now see peer-to-peer services with collaboratively designed APIs, echoing the transition from top-down positional management to autonomous teams made up of expert equals.
As in tech, so in organisations
Technology already understands the structural shift needed to survive and thrive in the new world and it’s increasingly touching our organisations.
Understanding services and microservices as systems design – how that differs fundamentally from monolithic, orchestrated design – and recognising the agility that decentralisation enables, helps us express these transformational shifts to our organisations.
It’s good to acknowledge that evolution is an unpredictable, discontinuous and disorientating process. That’s OK. Feeling uncomfortable doesn’t mean you’re doing it wrong. Our sense of what good looks like will be disrupted. It’s helpful to understand that different parts of our organisations, and ourselves, will change at different speeds. That’s always going to create dissonance. Microservices and agile tend to be called out as strategic ambitions before those ideas reach and disrupt the centre of an organisation.
Devolving power from the centre of an organisation to the front-line is a prerequisite to releasing the power of transformation, but realising that is a hard journey.
If consciously allowing this dissonance in our organisations and ourselves helps us cross our personal chasm of digital transformation, then the journey is worth the hardship.
In spite of the very real strain and discomfort that transformation causes, it’s a mission to believe in and a reality that’s arrived, whether we choose it or not.