Microservices Architecture Reading List

Microservices Architecture Reading List

Microservices Architecture is more than just buzz. It has crossed the chasm and is now a movement. This is an attempt to come up with a reading list for Microservices.

This list provides articles, slide decks, talks, etc. to help you on your microservices journey.


Microservices by James Shore and Martin Fowler.
Abstract: "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."

  • Componentization via Services
  • Organized around Business Capabilities
  • Products not Projects. (dev ownership, i.e., DevOps)
  • Smart endpoints and dumb pipes (anti-ESB)
  • Decentralized Governance
  • Decentralized Data Management: Services own their data, and free to pick best tech to store data: LevelDB, RDBMS, Cassandra, JSON files.
  • Infrastructure Automation: Automated testing, automated deployment and automation of infrastructure (cloud orchestration, EC2, Boto, Chef, Docker, Jenkins, etc.)
  • Design for failure: Distributed, More monitoring, more resilience, service discovery, health monitoring. (etcd, consul, ZooKeeper, Nagios, etc.)
  • Evolutionary Design: Smaller, modular services enable more frequent releases and more change overall.

Microservices Architecture by Rick Hightower. Abstract: "Just remember Microservices are not a new thing, and they are not cool or hip. Microservices are obvious evolutionary architecture to address the revolutionary things that already happened: web, cloud, mobile, server virtualization, OS containerization, multi-core servers, cheaper and cheaper RAM, 64 bit computing, 10GBE, 100GBE, etc. This is not extreme or cool. This is obvious reactionary architecture to this amazing tech landscape that we live in. It is less about the fashion show of technology coolness and more about not using tools and techniques that are antiques in this environment. Give up your punch cards, and WAR files, and join in."


Microservices - Not A Free Lunch!Summary: Cloud, DevOps and Continuous Delivery lay the foundation of microservices hype. There are benefits to microservcies including: .... Is microservices more than hype? What about operations overhead? Services could be spread accross tens of servers an applications might consist of tens of distributed microservcies. Turning a single webapplication into 20 services with 60 processes has overhead in deployment. Espeically when you include load balancers, messaging layers, and plubmbing between services. More moving parts to monitor than a single application server or two. The wheels of your plethora of Microservices through your release pipeline and into production needs a lot of greasing and automation. Microservices require more operations overhead. Developers will need to be trained into DevOps like roles to mind the gap. Many microservices will need their own datastore and if you follow the practice of picking hte best tool for the job, you may end up with a wide assortment of NoSQL and traditional DBs. The developer will need more knowledge of the database in a DevOps/Microservices world. Finding these types of developers is difficult so this might hamper your already difficult recruiting efforts. Collaborating components, means you are introducing interfaces and contracts between them, which could include message formats. "In a Microservices environment, this might mean that simple cross cutting changes end up requiring changes to many different components". Some of this can be mitigated by using eager readers and such, but it can't be avoided completely. There is an increase in integration testing due to more moving parts. Other things the article mentioned was the "Duplication Of Effort", "Distributed System Complexity" (network latency, fault tolerance, message serialization, unreliable networks, asynchronicity, versioning, varying loads), "Asynchronicity Is Difficult" (manage correlation IDs and distributed transactions), and "Testability Challenges". "Distributed systems are an order of magnitude more difficult to develop and test against, so again the bar is raised vs building that unsexy monolithic application." "However, when considering Microservice like architectures, it's really important to not be attracted to the hype on this one as the challenges and costs are as real as the benefits."

Application How we build microservices at Karma.

Carving it up: Microservices Monoliths & Conway’s Law Summary: "Microservice architectures, although they have gained currency due to a recent post by James Lewis and Martin Fowler, are not a new concept. Lewis and Fowler note a pedigree going back as far as 2011, and in the opinion of Steve Jones, “Microservices is SOA, for those who know what SOA is” (debateable). Roger Sessions published a 3 part series in the fall of 2012 detailing his concept of a “Snowman Architecture”, which is fundamentally similar to the Lewis and Fowler model." Microservice summary. Nano services are bad. 

High Speed Microservices . Summary: "This article endeavors to explain high speed microservices architecture. High speed microservices is a philosophy and set of patterns for building services that can readily back mobile and web applications at scale. It uses a scale up and out versus a scale out model to do more with less hardware. A scale up model uses in-memory operational data, efficient queue hand-off, and async calls to handle more calls on a single node. In general the cloud scale out model, employs a sense of reckless abandon. If your app has performance issues, no problem spin up 100 servers. Still not fast enough. Try 1000 servers. This has a cost. This does not replace a cloud scale out model per se. It just makes a cloud scale out model more cost effective. Do more with less."

Reactive Microservices Summary: "Reactive Services, Reactive Manifesto and Microservices. Many disciplines of software development came to the same conclusion. They are building systems that react to modern demands on services. Reactive services live up to the Reactive Manifesto. Reactive services are built to be robust, resilient, flexible and written with modern hardware, virtualization, rich web clients and mobile clients in mind. The Reactive Manifesto outlines qualities of Reactive Systems based on four principles: Responsive, Resilient, Elastic and Message Driven. These are also important for Microservcies.

Mobile applications: the biggest drive for Microservices Architectures? by Rick Hightower
Many of the articles and talks about microservices architecture leave out an important concept. They mention the influencers to microservices, but leave out one of the major influencers of microservices architecture: the mobile web and mobile native applications. One of the major influences to microservices architecture is the mobile web and the proliferation of native mobile applications. You can't create a service in an efficient manner with frameworks that were written for monolithic web applications. The frameworks themselves were developed to develop monolithic websites.

SDTimes: Digging into microservices | Microservices Architecture

" 'Microservice architecture is the idea that rather than building large monolithic applications, where you have one enormous thing that tries to cover thousands and thousands of different pieces of functionality and lots of different business services, we are going to try to break these out into smaller components, each of which represent an individual business action,' said Andrew Phillips, vice president of product management at XebiaLabs. 'And then we are going to treat them as independent applications, which can be written and easily updated.'"
" 'With microservices, organizations don’t have to worry about spending time, expense and taking risks to push out so many changes at the same time. There is no more waiting six months for things to come out.' "
Microservice architecture vs. service oriented architecture. Does SOA overlap with microservices architecture? " 'Service oriented architecture is an approach that says that we can more effectively build systems, which are made up of collaborating services,' he said. 'Microservices are exactly that. They are just more opinionated. In many ways you can think that microservices are to SOA what scrum or XP are to agile. So SOA is the general idea, where microservices are a specific way of achieving this idea.' "
The article ends with some salient advice about microservices adoption.

Four reasons why Microservices Architecture Resonates. by Neal Ford 

Neal Ford has four reasons why Microservices Architecture Resonates. DevOps and virtualization 2.0 laid the foundation for microservices by automating machine provisioning and deployments. He argues the cost to make changes was reduced. He argues that the Microservice architectural style puts a high value on operational concerns as one of the key aspects of the architecture. He makes the common connection between Domain Driven Design's Bounded Context and microservices architecture. He goes on to explain how Microservices Architectures make change less expensive. He warns of the complexities of microservices but also the unique opportunities that Microservices Architectures provide.

References and reading materials:

1. Microservices by Martin Fowler and James Lewis
2. Microservices Architecture by Chris Richardson
5. Micro service architecure by Fred George
6. Microservices are not a free lunch by Benjamin Wootton
11. Migrating to microservices by Adrian Cockroft
15. Microservices and DevOps by Adrian Cockcroft
17. Microservices on the JVM - Alexander Heusingfeld
18, Microservices Shaun Abrams

More to come