Mark Little spoke with InfoQ about how microservices reflect an evolution in our understanding of how to build services. The most important idea is to separate the architectural ideas, which have been present since the days of SOA, from the technological implementations which change over time.
Mark Little is vice president at Red Hat, where he leads JBoss technical direction, research and development. Prior to this he was SOA technical development manager, and director of standards. He was chief architect and co-founder at Arjuna Technologies, and distinguished engineer at Hewlett Packard when Arjuna was spun off. He has worked in the area of reliable distributed systems since the mid-80s. His PhD was on fault-tolerant distributed systems, replication and transactions. He is currently also a professor at Newcastle University.
InfoQ: For some who have read and heard a lot about microservices it seems like old wine in new bottles. The term SOA was captured by the vendors, and received a very bad reputation. Nonetheless, it seems that microservices are nothing other than service orientation. Do you agree?
Mark Little: I think it's important to separate the concepts behind microservices from the technologies that people are keen to use for building them. While it is great to talk about Docker, for instance, it's just one way of approaching containers and packaging of services. However, the underlying reasons for wanting to compose applications from services remain no matter what implementation approach you may use and it is very similar to the reasons behind the evolution of SOA. I agree that SOA is a term which was misused by some vendors and consultants, which has perhaps tarnished its reputation, but if you look beyond this there are a lot of good methodologies, standards and specifications that arose with the SOA acronym. Of course even SOA had its heritage in other techniques which predate it, including CORBA.
InfoQ: Then to rid ourselves of bad historical context, how would you define a micro-service, and how does service composition compare with other approaches. When would you not, as an architect, use service composition?
ML: First of all I'd try not to get hung up on the "micro" bit. Some people read that as "it shouldn't be more than 100 lines of code", but I think that's a very slippery slope. We've even seen people talking about nano-services! I think a micro-service, just like a service built using good SOA practices, should do one thing really well. It shouldn't try to be everything to everyone. It should have a well-defined interface as part of a contract that will exist between it and its users. Of course a service interface could hide the fact that what appears to be a single micro-service could actually be several cooperating to provide a larger business task or function, just as we've seen over the years with composite services in SOA.
In terms of when you shouldn't use service composition, I don't think those reasons change between "traditional" SOA (I'm not really sure what to call it) and microservices. A good architect should be taking into account various requirements such as performance and fault tolerance. Does the division of a task into multiple services which potentially communicate remotely with each other give a benefit that outweighs any downside on remote invocations or managing multiple services? If the failure of a single service cause the entire application to grind to a halt then replication should be considered, but perhaps closely related microservices should be a single micro-service that can fail and recover as a single unit. I also think this article (http://www.infoq.com/news/2014/08/microservices_ballmud) summarizes another problem succinctly - don't think factoring your application into microservices is going to be a panacea for a poor architecture.
InfoQ: Are you saying that microservices are just services, and what is new is that the industry has made some progress in understanding more of the issues involved around service composition, and these issues are independent of the underlying technology?
ML: Yes and no - though I may be nit picking. If SOA were "just services" 10 years ago then we'd not have seen all of the SOA related standards, books and best practices that sprang up. I like to think that SOA is "services done right", with all that entails, e.g., composition, interfaces, contract definitions, etc. microservices should be just the same. As you say, where microservices benefit is also around the technologies, processes and understandings that have been learnt over the years and also most recently. Things such as containerization (e.g., Docker) help developers. It's funny to think also though that so-called container-less approach is also growing in popularity for microservices. One size definitely doesn't fit all.
InfoQ: But much of the material around SOA seems to have been focused on the Enterprise, and the microservices crowd seems to be in the focused on so called “cutting edge” projects. How can these two worlds understand that they are trying to solve the same set of problems, but with different constraints? Not every application is a world-wide, Internet scale, distributed application, and most developers and architects do not live in that world. How do those people learn about microservices?
ML: I think it's important to state that not everything that has gone under the banner of SOA was really SOA. We saw a lot of vendors, consultants etc. jumping on the SOA bandwagon just as we've seen with pretty much every wave in our industry. In terms of where initial microservices deployments compare with SOA, I suppose it does depend where you look. I've certainly seen many enterprises wanting to understand where and how microservices can fit into their existing systems and this often requires those micro-service implementations to possess enterprise characteristics too. But you're right in that a lot of the information we're seeing and hearing around microservices at the moment does seem to be from greenfield development, where people want to start simple and build up their layers of complexity as and when needed. And I think that's always the right approach: rarely does throwing the kitchen sink at a problem result in the right solution (well not unless you're building a kitchen!) I'll paraphrase Einstein, but we do need to keep things as simple as possible but no simpler.
To learn about microservices I believe the best starting point is to learn about the best practices of the industry over the past decades. Obviously I'm expecting a little bit of focus here because there are a lot of things that have gone on in computing that aren't relevant to microservices. We need to learn the good and the bad from the past and sometimes I'm worried when I see developers ignoring what's gone before because they either don't believe it has relevance or they don't care to do the background research. I do keep coming back to SOA but I'd also include REST in the picture - despite the amount of anti-SOA/anti-REST debates we've seen over the years, they both have a lot to offer microservices developers. I know that some people don't like various standards that were developed over the past decade or so under the SOA banner, but there are a number that do make a lot of sense. The OASIS SOA Reference Model for instance. And of course sites such as InfoQ do a great job of capturing articles that are published covering best practices. We can write as much as we want in standards, but it's the real world experiences that count, and most of the good standards are based upon years of experiences, both good and bad.
If the only thing microservices does for the industry in the next few years is to become a term that is associated with only good service-oriented best practice then I think it'll be worth it. We can argue about whether micro-service is a term we need at all if all it is can be captured by SOA, but as I said earlier, people were doing SOA before that term was coined. Ultimately I care less about what we call these principles of service-orientation and much more about the fact that the industry can get behind something like this and make it a fundamental part of an architect’s toolkit. But we've also got to realize, as a lot of the later SOA work did, that composing things into services is complicated and yet is just the tip of the iceberg of the overall complexity in a services environment.
InfoQ: What about technology independence? microservices are not automatically REST, or HTTP. It seems that architects have difficulty separating architectural approaches and want to make them concrete and clear with a particular technology choice.
ML: Yes I agree. Just as with SOA there's no inherent architectural requirement for a specific technology or communication mechanism. Many people still forget that even REST doesn't require HTTP, it's just the baseline everyone knows. I've said for years that if a vendor or consultant says they have a product that will "give you SOA" then you should have a healthy degree of skepticism: technologies, including the much maligned ESB, can assist in architecting and implementing SOA, but it takes more than that; it's a change in mindset and approach to developing applications. It's just the same with microservices: if you don't understand the architectural principles behind building things from services, the implications for inter-service communication, fault tolerance etc., then having the best tooling and products in this area doesn't help. Think of understanding these fundamental principles just like the Rosetta Stone (http://www.britishmuseum.org/explore/highlights/highlight_objects/aes/t/the_rosetta_stone.aspx) - it unlocked the secrets of reading hieroglyphs and everything flowed from there. Understanding good SOA principles irrespective of implementation is crucial to unlocking microservices. Furthermore, what you use to implement them today may need to be very different to what you use tomorrow: services don't exist in isolation and the environmental impact must always be taken into account, as well as overall application needs.