Microservices vs. Service- Oriented Architecture Mark Richards Microservices vs. Service-Oriented Architecture by Mark Richards Copyright © 2016 O’Reilly Media. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Editors: Nan Barber, Rachel Roumeliotis Interior Designer: David Futato Production Editor: Nicholas Adams Cover Designer: Randy Comer Copyeditor: Eileen Cohen Illustrator: Rebecca Demarest Proofreader: Nicholas Adams November 2015: First Edition Revision History for the First Edition 2015-11-17: First Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Microservices vs. Service-Oriented Architectures and related trade dress are trademarks of O’Reilly Media, Inc. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is sub‐ ject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. 978-1-491-95242-9 [LSI] Table of Contents Foreword. vii Preface. ix 1. The World of Service-Based Architectures. 1 Service Contracts 2 Service Availability 5 Security 7 Transactions 8 Too Much Complexity? 9 2. Comparing Service Characteristics. 11 Service Taxonomy 11 Service Ownership and Coordination 14 Service Granularity 17 Granularity and Pattern Selection 19 3. Comparing Architecture Characteristics. 21 Component Sharing 22 Service Orchestration and Choreography 24 Middleware vs. API Layer 30 Accessing Remote Services 33 4. Comparing Architecture Capabilities. 35 Application Scope 35 Heterogeneous Interoperability 36 v Contract Decoupling 39 5. Summary. 43 vi | Table of Contents Foreword People either love or hate the idea of microservices. I must admit that I was in the former camp initially but have changed my mind over the last six months. Originally, I had thought the management of a plethora of individual services that make up a full application would be fraught with error and troublesome to both development and operations staff. However, over the last year we have seen a rise in popularity of a key piece of technology that is now enabling us to take advantage of this design pattern in a more efficient manner. This new technology is the rise of the container application platform and the tight integration with DevOps principles around automa‐ tion and scalability. An organization can implement DevOps without microservices, but should not implement a microservice architecture without a DevOps culture. Using a container application platform for the deployment of micro‐ services will allow you to truly see the benefit of breaking up appli‐ cation logic into logical individual components. As your application grows in usage and demand, using this approach will allow you to quickly scale the most utilized components instead of scaling the entire application. As an example, one of the first applications that I developed many years ago was a CRM system that retrieved data from a datastore and then presented the information to the user. One of the most complex and non-performant bits of code was the actual searching of millions of customer records. Unfortunately, this code block was the most heavily used part of the system. In order to handle demand and the response times the users expected, we scaled the entire application just to have more instances of this search ser‐ vice. Keep in mind, this application was a full Java EE–based appli‐ cation, and therefore scaling would require additional hardware to handle the large and complex application. Had we had the tools we all have available today, such as a container application platform, we could have trivially scaled the search service to 50 containers while leaving the not-heavily-used services alone. This would have saved us a tremendous amount of time, headache, and cost while also pro‐ viding the users with the experience they desired. Are microservices the right solution for every application? Of course not. However, if you think that your application could take advan‐ tage of scaling independent components, give it a look and see if it fits well with the goal of your application. Of course, let’s not forget about the reuse aspect of microservices. Having your application logic broken up into independent compo‐ nents will afford you and your development team a tremendous amount of flexibility in reusing code across projects as well allow for a true polyglot environment where you can finally use the best tool for each individual task. I am excited about the adoption of microservices and the impact it will have on our craft. —Grant Shipley, Senior Manager, Developer Advocates, Red Hat, Inc. Preface In the mid-2000’s, service-oriented architecture (SOA) took the IT industry by storm. Numerous companies adopted this new architec‐ ture style as a way to bring better business functionality reuse into the organization and to enable the IT organization and the business to better communicate and collaborate with each other. Dozens of best practices for implementing SOA emerged at that time, as well as a plethora of third-party products to help companies implement SOA. Unfortunately, companies learned the hard way that SOA was a big, expensive, complicated architecture style that took too long to design and implement, resulting in failed projects that drove SOA out of favor in the industry. Today, microservices architecture is taking the IT industry by storm as the go-to style for developing highly scalable and modular appli‐ cations. Microservices architecture holds the promise of being able to address some of the problems associated with large, complex SOAs as well as the problems found with big, bloated monolithic applications. But how much do microservices and SOA differ? Is the industry destined to repeat the same experience with microservices as with SOA? In this report I walk you through a detailed comparison of the microservices and SOA architecture patterns. You will learn the basics of each of these architectures and core differences between them in terms of the architecture style, architecture characteristics, service characteristics, and capabilities. By using the information in this report, you will know how these two architecture styles differ from each other and which of the two is best suited for your particu‐ lar situation. ix CHAPTER 1 The World of Service-Based Architectures Both microservices architecture and SOA are considered service- based architectures, meaning that they are architecture patterns that place a heavy emphasis on services as the primary architecture com‐ ponent used to implement and perform business and nonbusiness functionality. Although microservices and SOA are very different architecture styles, they share many characteristics. One thing all service-based architectures have in common is that they are generally distributed architectures, meaning that service components are accessed remotely through some sort of remote- access protocol—for example, Representational State Transfer (REST), Simple Object Access Protocol (SOAP), Advanced Message Queuing Protocol (AMQP), Java Message Service (JMS), Microsoft Message Queuing (MSMQ), Remote Method Invocation (RMI), or .NET Remoting. Distributed architectures offer significant advantages over monolithic and layered-based architectures, includ‐ ing better scalability, better decoupling, and better control over development, testing, and deployment. Components within a dis‐ tributed architecture tend to be more self-contained, allowing for better change control and easier maintenance, which in turn leads to applications that are more robust and more responsive. Distributed architectures also lend themselves to more loosely coupled and modular applications. 1 In the context of service-based architecture, modularity is the prac‐ tice of encapsulating portions of your application into self-contained services that can be individually designed, developed, tested, and deployed with little or no dependency on other components or serv‐ ices in the application. Modular architectures also support the notion of favoring rewrite over maintenance, allowing architectures to be refactored or replaced in smaller pieces over time as the busi‐ ness grows—as opposed to replacing or refactoring an entire appli‐ cation using a big-bang approach. Unfortunately, very few things in life are free, and the advantages of distributed architectures are no exception. The trade-offs associated with those advantages are, primarily, increased complexity and cost. Maintaining service contracts, choosing the right remote-access protocol, dealing with unresponsive or unavailable services, secur‐ ing remote services, and managing distributed transactions are just a few of the many complex issues you