Many people think Juval Löwy wants to create services everywhere, but he contends microservices are simply the logical outcome of a thoughtfully decomposed system.
Löwy designs and builds systems in which every class is a service, an approach he pioneered in 2007 and continues to teach in the fourth edition of his book, Programming WCF Services. Service-oriented applications are more maintainable because of a clean separation between business logic and underlying plumbing, and Löwy has overcome limitations of software development platforms to drive this separation through all layers of the system.
InfoQ asked Löwy about his software design methodology and where he sees frequent failure in traditional approaches.
InfoQ: For over a decade, you have proposed "every class as a service." What led you to this approach?
Juval Löwy: Service orientation in general is not a quantum leap – it is just the next step in a long journey of the evolution of software engineering. If, for example, object orientation was a good idea, you would not stop at the system or subsystem level and say that is as granular as objects go. Quite the opposite, you will try to push the benefits of objects as far down as you can, making even the primitives objects.
Services are the industry's attempt to decouple the business logic (what the customers care and pay for) from the underlying plumbing required to sustain it, like security, activation, synchronization, transactions, error handling, deployment, etc. It turns out that the plumbing consumed the majority of the development time and effort, and developers tended to do a poor job at it. With services, you opt for using ready-made, off-the-shelf plumbing, so you keep the boundaries where they are while benefiting from standard plumbing.
Since plumbing is evil regardless of scope (at the enterprise, system, subsystem, class) it would make sense to leverage the benefits of services as much as you can. Taken to the ultimate conclusion, the integer or the string must be services. Why should developers secure their strings, worry about synchronizing their integers etc.?
The issue that you run against is that the development platforms at the time (and today) do not support such out-of-the-box usage. I was able, however, to address this and come up with augmented technology that allows you to use services at the level of every class, if you wish to, while maintaining the programming model and overall cost of ownership of regular classes.
InfoQ: How does every class as a service compare with SOA patterns over the past decade, and with the microservices movement we see today?
Löwy: Comparing implies there is a contrast or a conflict. There are none. To succeed you should use services at the level of granularity I have identified a decade ago. It is just sound design.
Your body is not one giant tissue. A system that only has a giant monolith of a service is unmaintainable, a pain to own, and rife with defects. Nothing is reusable and extensibility is impossible.
There is nothing wrong with providing a BIG service or a feature to the outside world, but the way to do that is by integrating the microservices. This, by the way, is a universal design rule: Features are always and everywhere aspects of integration, not implementation. This is true with anything, like houses, cars, laptops, factories, etc. Your car has a very important feature, take you from A to B, but there is no box in your car that implements that. You provide the feature by integrating the car's internal components, a driver, fuel, and road.
InfoQ: What is the right way of decomposing a system and how is that different from traditional design approaches?
Löwy: It turns out that most people break down the design based either on functionality or on domains. So if they need to do A, and B, and C, they will have an A service, a B service, a C service, or they would look for places (domains) to place the A or the B. The problem with this approach is that over time (and not that much time), what you need to do will change, and as a result your design will change. And when the design changes it is very painful.
The conclusion is that you should never design against the requirements (or the features, or the use cases, or the user stories). What you must do instead is identify the smallest set of building blocks, call them microservices if you like, that you can put together to satisfy ANY requirement: present and future, known and unknown. There is a strong process angle of how you go about doing just that.
The right design approach is to identify areas of volatilities, and those you encapsulate in (micro)services. Then you implement the required behavior as the interaction between those services. A new requirement would simply mean a different services interaction, not a different decomposition, so now when the requirements change, your design does not.
In addition, since the decomposition was along areas of volatilities, when something changes there is exactly one place to go and deal with it, so you have contained the change. With functional or domain decomposition, when a change happens it is not in one place, so you have maximized the impact of the change, making it the worst way of doing the architecture.
This approach for decomposition is supercharged by microservices because services are all about ease of interaction and integration. Furthermore, in most software systems there are typical areas of volatility, so you can use that as a starting point. These areas also have typical patterns in their interactions, so once you recognize that, the design converges very quickly and correctly.
InfoQ: After performing a volatility-based decomposition, how does the development process adapt to a highly modular approach for building the system?
Löwy: You have to design and build the services, but also the factory to assemble them. When you want to produce cars, you start with designing the individual components of the car (gear box, engine, pumps, seats, etc.) but you must also design the assembly line to put the parts together. Design-wise, it is even more challenging than the design of the parts or the car itself. Anyone can design a pump for a car. Designing a pump that is good enough for hundreds of types of cars, or designing an assembly line that can build lots of different cars is not so trivial.
In the software world, you will have to design the microservices (the parts) and the project (the assembly line). It is not happenstance or an accident. You don’t organically build a factory. You can also, with experience and practice, improve the throughput of your factory by introducing multiple pipelines such as services, unit testing, integration, etc. And you do all that using a strong set of engineering guidelines that came out of the prescribed interactions patterns between the areas of volatiles.
The result is hyper-agility because you very quickly crank up new features and behaviors using those microservices. To use agile terms, you implement the user stories using the microservices you have already built, ideally without any new code. In a car factory, there is very little actual manufacturing going on – the parts arrive complete at the factory, and they just integrate them.
About the Interviewee
Juval Löwy is the founder of IDesign and a master software architect specializing in system and project design. Löwy has mentored hundreds of architects across the globe, sharing his insights, techniques, and breakthroughs, in architecture, project design, development process, and technology. Löwy is the Microsoft Regional Director for Silicon Valley and had participated in the Microsoft internal strategic design reviews for C#, WCF and related technologies. Löwy is a frequent speaker at the major international software-development conferences. He has published several bestsellers and numerous articles, regarding almost every aspect of modern software development and architecture. Microsoft recognized Löwy as a Software Legend as one of the world's top experts and industry leaders. You can contact Löwy via his website.
