Microservices Guide

In short, 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.
-- James Lewis and Martin Fowler (2014)
A guide to material on martinfowler.com about microservices.
Late in 2013, hearing all the discussion in my circles about microservices, I became concerned that there was no clear definition of microservices (a fate that caused many problems for SOA). So I got together with my colleague James Lewis, who was one of the more experienced practitioners of this style. Together we wrote
We wrote the article to provide a firm definition for the microservices style, which we did by listing the common characteristics of microservice architectures that we saw in the field.
We also looked at common questions such as “how big is a microservice” and “what's the difference between microservices and Service-Oriented Architecture”. The article catalyzed interest in microservices.
“Do we use it, do we not use it?
… and what on earth is it in the first place?”
In my short introductory talk (~25 minutes) I pick out the most important defining characteristics, compare microservices to monoliths, and outline the vital things to do before putting a first microservice system into production.
Any architectural style has trade-offs: strengths and weaknesses that we must evaluate according to the context that it's used. This is certainly the case with microservices. While it's a useful architecture - many, indeed most, situations would do better with a monolith.
(from Microservice Trade-Offs)
The microservices architectural style has been the hot topic over the last year. At the recent O'Reilly software architecture conference, it seemed like every session talked about microservices. Enough to get everyone's over-hyped-bullshit detector up and flashing. One of the consequences of this is that we've seen teams be too eager to embrace microservices, not realizing that microservices introduce complexity on their own account. This adds a premium to a project's cost and risk - one that often gets projects into serious trouble.
As I hear stories about teams using a microservices architecture, I've noticed a common pattern.
This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .
evolutionary design microservices
In the last few months, I’ve heard repeatedly that the only way to get to a successful microservices architecture is by starting with a monolith first. To paraphrase Simon Brown: If you can’t build a well-structured monolith, what makes you think you can build a well-structured set of microservices? The most recent – and, as usual, very convincing – rendering of this argument comes from Martin Fowler on this very site. As I had a chance to comment on an earlier draft, I had some time to think about this. And I did, especially because I usually find myself in agreement with him, and some others whose views I typically share seemed to agree with him, too.
I’m firmly convinced that starting with a monolith is usually exactly the wrong thing to do.
As I talk to people about using a microservices architectural style I hear a lot of optimism. Developers enjoy working with smaller units and have expectations of better modularity than with monoliths. But as with any architectural decision there are trade-offs. In particular with microservices there are serious consequences for operations, who now have to handle an ecosystem of small services rather than a single, well-defined monolith. Consequently if you don't have certain baseline competencies, you shouldn't consider using the microservice style.
In P of EAA I said "don't distribute your objects". Does this advice contradict my interest in Microservices?
API design microservices
goto conferences asked me to do an interview with Sam Newman on his book: “Monoliths to Microservices”. This turned into a general conversation about microservices and when to use them. Sam considers the three main reasons for them to be independent deployability, isolation of data, and reflecting the organizational structure. I'm more skeptical of the first, but consider data and people to be complicated parts of software development.
interviews microservices
Microservice architectures are fairly new, but I've been fortunate that we've worked with them at Thoughtworks since their earliest appearances. For a cohesive description of how best to work with them, the best introduction is Sam Newman's book Building Microservices which he wrote based on our experiences and other published accounts.
There has been a shift in service based architectures over the last few years towards smaller, more focussed “micro” services. There are many benefits with this approach such as the ability to independently deploy, scale and maintain each component and parallelize development across multiple teams. However, once these additional network partitions have been introduced, the testing strategies that applied for monolithic in process applications need to be reconsidered. Here, we plan to discuss a number of approaches for managing the additional testing complexity of multiple independently deployable components as well as how to have tests and the application remain correct despite having multiple teams each acting as guardians for different services.
testing infodecks microservices
As monolithic systems become too large to deal with, many enterprises are drawn to breaking them down into the microservices architectural