Hello and welcome to the first of our 3 part series exploring the wonderful and innovative world of software subcultures. Even us geeky IT kids can get a little radical from time to time, and it’s a pretty good job that we do, too. In fact, much like the hippie subculture that gave rise to the popularity of The Beatles, who subsequently managed to change the face of pop and rock music forever, so too have some of software’s most influential figures started off by going against the grain, and yet have wound up being the genesis of some of the most important movements of our time. This series will explore 3 such movements – Microservices, DevOps and Agile – and will serve as introductions to a mini-series of eBooks which we are due to publish very soon. This week it’s Microservices. We hope you enjoy the series.

What Is Microservices?

The perfect question to start things off. Fundamentally, for those of you who have not come across the term before, ‘microservices’ doesn’t describe any particular builds or structures of code that can be deployed into a software program, but rather a methodology for teams to adhere to when building software. Indeed, this is where the idea of a ‘subculture’ comes in.

Perhaps it’s best to start with a definition from one of microservices most vocal advocates Martin Fowler:

“‘Microservices’ became the hot term in 2014, attracting lots of attention as a new way to think about structuring applications. I’d come across this style several years earlier, talking with my contacts both in ThoughtWorks and beyond. It’s a style that many good people find is an effective way to work with a significant class of systems. But to gain any benefit from microservice thinking, you have to understand what it is, how do it, and why you should usually do something else.”

Indeed, the “style”, as Fowler puts it, of microservices is not one for the fainthearted – but what is it exactly?

Well, microservices is a software architectural style, in which the mandate is to develop and build a single application as a suite of small services. Each suite runs in its very own process, and communicates with extremely lightweight mechanisms, often an HTTP (hypertext transport protocol) resource API (application programming interface).

Importantly, these individual microservices are independently deployable from one another – a function that is managed by fully automated deployment machinery. Centralised management of these individual services is kept to a bare minimum, and indeed they may even be written in different programming languages if a particular language is more suited to one microservice than another.

Now, admittedly, this sounds as if the microservices architectural style might actually overcomplicate an already decidedly esoteric procedure – building a software application is surely hard enough without embroiling the process even further by mixing up languages. However, applications – especially those that are deemed to be enterprise-grade – are of course extremely large entities, and so by deliberately separating the various components, in actual fact the whole process of building, identifying and maintaining the program (or rather the individual and independent microservices within the larger program) can be made easier.

Sam Newman describes it like this:

“Codebases grow as we write code to add new features. Over time, it can be difficult to know where a change needs to be made because the codebase is so large. Despite a drive for clear, modular monolithic codebases, all too often these arbitrary in-process boundaries break down. Code related to similar functions starts to become spread all over, making fixing bugs or implementations more difficult.”

The Key Properties Of A Microservices Architecture

This is something that we discuss in great depth in the eBook. But, for the purposes of this introductory blog post, I think it pertinent to take a look at the bullet points that make up the key properties of a microservices architecture:

• The services are easy to replace
• Services are organized around capabilities, e.g. user interface front-end, recommendation, logistics, billing, etc
• Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best
• Architectures are symmetrical rather than hierarchical (producer – consumer)

Now, some people in the software development world might sit up at this point – and you may, too – and say, hang on a minute, isn’t this just SOA (service oriented architecture) rebranded? Indeed this is a very strong argument that is held up by a number of important figures in the software industry.

For some, microservices is actually nothing more than another term for service oriented architecture (SOA); for others, microservices is actually a specialisation of SOA; and for more people still, microservices is indeed something new entirely.

The Controversy

Although having been discussed as a concept from perhaps as early as 2011 or 2012, ‘microservices’ as a term didn’t really begin to gain prominence until an article entitled ‘Microservices’ was published on Michael Fowler’s blog in March 2014. The now famous (or infamous, depending on you point of view) article offers the following definition of the microservices architectural style:

“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

Now, let’s take a look at a definition of SOA for comparison so we can see what all the fuss is about:

“Services are unassociated, loosely coupled units of functionality that are self-contained. Each service implements at least one action, such as submitting an online application for an account, retrieving an online bank statement or modifying an online booking or airline ticket order.”

Interesting isn’t it. On the surface of things, SOA and microservices do seem to merge into one and the same thing, and this indeed is what determined advocates of SOA have been trying to emphasise in order to try and squash the microservices movement.

The SOA Argument

One of the leaders of this side of the debate is Steve Jones of Capgemini, author of Enterprise SOA Adoption Strategies. Jones is a member of several standards bodies including the OASIS SOA Reference Model Group.

Last year, in response to James Lewis’ and Martin Fowler’s blog ‘Microservices’, Jones wrote a rather sarcastically titled post in reply: ‘Microservices – Money For Old Rope or Re-badging SOA For The Cool Kids’.

Here’s what he says:

“Martin Fowler is peddling a new approach, ‘Microservices‘ which… wait for it is a way of developing applications as a suite of services.  Each one of which has its own process thread and ‘communicates via lightweight mechanisms’ such as…. over HTTP.

“But wait there is more, you’ll be stunned to know that these services can be built using different programming languages and even use different data stores.

[…]

“Martin Fowler really should know better than this in not paying any heed to what has gone before and promoting an approach as if it’s actually new.  The article reads like an extremely basic description of SOA from about 2000 without either the industrialisation of WS-* or the dynamic power of things like Jini.  Above all it doesn’t move forward the question of how to architect such service architectures and how they need to map to the business and how although there might be fine grained services it is critical to understand the management structure and hierarchy of those services to actually enable the degree of autonomy and flexibility required in these sorts of architectures.

“Microservices is just another take on SOA and one that doesn’t move the game forwards as it yet again focuses on technical aspects over the business architecture that is realised.  Putting forwards as new something that would be recognisable to people working on CORBA in the 90s and certainly Web Services in 2001 is just poor quality advice. It neither learns from the past, educates the reader nor moves the game forwards, it’s just selling an old approach with a new name.

“Microservices?  What is that SOA 3.0?  Nope its just an old school form of SOA without the learnings that came from doing that.”

Unsurprisingly, Jones’s post kicked off a rather heated debate on Twitter.

In Defence Of Microservices

Here’s Fowler’s reply, left in the comments section of the ‘Money For Old Rope’ blog post:

“As we say in the article ‘We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix.’ We find that SOA means many different things, and the approach we talk about is one that its advocates feel needs its own label.”

In fact, the microservices pair even felt compelled to update their article in further response to Jones’s blog by adding a side bar, which explains to Steve Jones the world exactly how they differentiate microservices from SOA. I reproduce the whole thing here for your perusal:

“When we’ve talked about microservices a common question is whether this is just Service Oriented Architecture (SOA) that we saw a decade ago. There is merit to this point, because the microservice style is very similar to what some advocates of SOA have been in favour of. The problem, however, is that SOA means too many different things, and that most of the time that we come across something called “SOA” it’s significantly different to the style we’re describing here, usually due to a focus on ESBs used to integrate monolithic applications.

In particular we have seen so many botched implementations of service orientation – from the tendency to hide complexity away in ESBs, to failed multi-year initiatives that cost millions and deliver no value, to centralised governance models that actively inhibit change – that it is sometimes difficult to see past these problems.

“Certainly, many of the techniques in use in the microservice community have grown from the experiences of developers integrating services in large organisations. The Tolerant Reader pattern is an example of this. Efforts to use the web have contributed, using simple protocols is another approach derived from these experiences – a reaction away from central standards that have reached a complexity that is, frankly, breathtaking. (Any time you need an ontology to manage your ontologies you know you are in deep trouble.)

“This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA, perhaps service orientation done right. Either way, the fact that SOA means such different things means it’s valuable to have a term that more crisply defines this architectural style.”

So – SOA? Microservices? Are They The Same Thing?

Well, there are clearly some similarities, and clearly some differences. In the end, it comes down to how software developers have been doing SOA all of these years to determine which side of the fence they sit on. Jones, for example, declares that this is exactly how he has been doing SOA, and so microservices is nothing new at all. For others, the manner of performing SOA has always been a sticking point, and so the microservices movement seems to answer all of their problems.

So, subjectivity, as ever, seems largely at play, and we discuss this in greater depth in our soon-to-be-published eBook, which we encourage you to look out for. In the meantime, we hope you’ve enjoyed this introduction to microservices. Next week, we’ll be taking a look into the DevOps subculture – a movement that is not entirely free from controversy either. Let us know where you fit into the spectrum in the comments below.