0740-7459/17/$33.00 © 2017 IEEE JANUARY/FEBRUARY 2017 | IEEE SOFTWARE 91 Editor: Cesare Pautasso University of Lugano c.pautasso@ieee.org Editor: Olaf Zimmermann University of Applied Sciences of Eastern Switzerland, Rapperswil ozimmerm@hsr.ch INSIGHTS MICROSERVICES are the latest fash- ion in software architecture and devel- opment practices. Since 2014, the dis- cussion has been controversial, with opinions varying from “holy grail” and “must adopt” to “nothing new” and “won’t work in the long run.” Here, service-oriented architecture (SOA) and microservices insiders Mike Amundsen, James Lewis, and Nicolai Josuttis share their experiences and predictions with department editors Cesare Pautasso and Olaf Zimmermann. Opening Positions Olaf Zimmermann: Let’s start with some fundamentals. Sam Newman wrote that we should “think of microservices as a specific approach for SOA in the same way that XP [Extreme Programming] or Scrum are specific approaches for agile software development.” 1 Do you agree? Cesare Pautasso: More specifically, how does REST [Representational State Transfer] fit in, and what was miss- ing in previous SOA implementation approaches? Mike Amundsen: Let’s start with REST. What I find fascinating about Roy Field- ing’s description of his “network-based software architecture” style is that he chose to use a unique formula for de- fining it: architectural properties + do- main requirements = interaction con- straints. I’ve not seen anyone else take this approach to defining an architec- tural style. Most writers today focus on his list of constraints (client-server, stateless, cache, uniform interface, and so on) and don’t talk much about his list of architectural properties (network performance, scalability, simplicity, and so on). 2 And I would say that it is this list of desired properties that ties back to what we’ve seen in SOA over the last decade and what we are now seeing in microservices. The properties you wish to “design for” will drive the constraints you need to apply to the implementa- tion of a system. In the book Microser- vice Architecture, my fellow authors and I propose a capabilities model for this property–constraint relation. 3 Nicolai Josuttis: Let me answer the ques- tion a bit differently. I tend to agree that microservices, according to my understanding, are a special approach for SOA. I had better skip the question about the difference between SOA and REST, which gets loaded and biased eas- ily. Microservices recommend to con- strain an SOA in very similar way that I recommend and teach to constrain any SOA to be successful. 4 This has to do with the context and complexity of Microservices in Practice, Part 1 Reality Check and Service Design Cesare Pautasso, Olaf Zimmermann, Mike Amundsen, James Lewis, and Nicolai Josuttis