[Z Blog] 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 of sorts. 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.

Basics

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."

Challenges

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. And more...

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.