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.
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.
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.'"
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.
1. Microservices by Martin Fowler and James Lewis
2. Microservices Architecture by Chris Richardson
3. Micro services – Java, the Unix Way by James Lewis
5. Micro service architecure by Fred George
6. Microservices are not a free lunch by Benjamin Wootton
7. Antifragility and Microservices by Russ Miles
9. Conway’s Law
11. Migrating to microservices by Adrian Cockroft
15. Microservices and DevOps by Adrian Cockcroft
16. Building and Deploying Microservices - Bart Blommaerts
17. Microservices on the JVM - Alexander Heusingfeld
18, Microservices Shaun Abrams
More to come