Notbinary
Published in

Notbinary

Services and Microservices

What are they and what’s the difference?

When it comes to building digital services, there’s lots of chatter about microservices. It’s a recent way of thinking 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.

What’s the difference?

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 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, might be completely different, 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 maximise work not done where something isn’t core business to that service.

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 fulfil a service in a way that serves the user, is reliable (if that’s important) and minimises both time to value of what’s being built and barrier 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, replace and remove the parts that make up your service, without disrupting users, is great.

So, what’s a Microservice?

A microservice is a member of the service team. It’s a part. It does a specific job as one of a group delivering a service, in collaboration with the other, different parts.

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 — 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 this piece by @jukesie talking about 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 becoming able to see the agility that decentralisation enables, allows us to come to a place where we can 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. It’s going to disrupt our sense of what good looks like. 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.

Realising that devolving power from the centre of an organisation to the front-line is a prerequisite to releasing the power of transformation is a hard journey

If consciously allowing — choosing, even — 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.

--

--

--

On 5th October 2020 Notbinary became a part of Foundry4. To continue to read our latest articles and blogs head over to foundry4.com

Recommended from Medium

cs371p Blog 9 Gavin Garcia

Configuring a Python 3 Environment on an AWS EC2 Ubuntu 20.04 Server.

Too Many Chefs in the Kitchen

Web Scraping with BeautifulSoup and Requests

Build Your Own Chatbot Using Deep Learning

Banging out expense reports like a boss

Two Quick Tips for Better Video Calls

Color coded directory listing with PowerShell

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
David Carboni

David Carboni

Hands-on culture and techology. Work hard be kind. CTO at Policy in Practice (https://policyinpractice.co.uk)

More from Medium

Enterprise Application Architecture Patterns & the Immutable Laws of Change

Applying the Micro Batching Pattern to Data Transfer

Data Access between Micro/Services

A complete understanding of Microservices

monolith vs microservices