The term "Microservice Architecture" has sprung up over the
last few years to describe a particular way of designing software
applications as suites of independently deployable services. While
there is no precise definition of this architectural style, there
are certain common characteristics around organization around
business capability, automated deployment, intelligence in the
endpoints, and decentralized control of languages and data.

Many development teams have found the microservices architectural style to be
a superior approach to a monolithic architecture. But other teams
have found them to be a productivity-sapping burden. Like any
architectural style, microservices bring costs and benefits. To
make a sensible choice you have to understand these and apply them
to your specific context.

Infrastructure as code is the approach to defining computing and network
infrastructure through source code that can then be treated just like any software
system. Such code can be kept in source control to allow auditability and
ReproducibleBuilds, subject to testing practices, and the full discipline of
ContinuousDelivery. It's an approach that's been used over the last decade to
deal with growing CloudComputing platforms and will become the dominant way
to handle computing infrastructure in the next.

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.

As with any bit
of new architectural terminology, it's hard to get a decent
definition of what microservices are, so this talk kicks off by tackling
that, based on the article by James and I that helped fuel the
interest. I then compare microservices to SOA, compare the
architecture to a more monolithic approach, and outline
important things you have to get right before you should deploy
a microservice application.

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.

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.

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.