To address microservices issues, turn to OOP principles
Developers may graduate to microservices from object-oriented programming, but the fundamental principles of OOP still apply, even if the techniques have changed.
Microservices development and object-oriented programming are quite different, particularly since microservices focus on the creation of independent stateless services and OOP looks at stateful objects with a lot of dependencies.
However, many of the problems that organizations face with microservices mimic problems developers faced with OOP. The lessons learned by those developers can apply directly to microservices creation. Let's look at the fundamental OOP principles that still apply in microservices and how developers can follow these principles to address common microservices development issues.
The SOLID principles
If you've ever programmed in object-oriented languages, you're probably already familiar with the SOLID principles originally presented by Robert C. Martin. The good news is that most of the patterns associated with microservices architecture overlap with these principles.
Single Responsibility Principle
The first principle is the one most often cited in the context of microservices and states that each software model should have one, and only one, reason to change. The key word here is change. Since objects are all linked, changing one thing usually means something else breaks.
However, this same change management issue applies if you have overgeneralized microservices. The difference with microservices is that problems are often related to data rather than code. Issues occur when one overgeneralized service calls a number of downstream services to perform tasks that will change its format.
Open-Closed Principle
The Open-Closed Principle, first coined by Bertrand Meyer, states that software entities should be open for extension but closed for modification. This means that we should be able to change what a module does without modifying any existing working code. OOP popularized this way of hiding the internal workings of objects, and the same concept applies in microservices. Domain-driven design isa good example of this concept at work in microservices architecture.
Liskov Substitution Principle
The L in SOLID stands for the Liskov Substitution Principle, which basically states that a data subtype cannot alter the behavior of any overarching data types. In object-oriented programming this is called a God object -- an object that either knows too much or does too much. This can also occur in microservices if developers create microservices that do too much, which is easy to do. A good example of this is Gilt's admission of when it accidentally created a Java-based monolith that consisted of large, loosely typed JSON/HTTP services.
Interface Segregation Principle
Developers can overcome a lot of microservices challenges by looking at past lessons we've learned from OOP.
The Interface Segregation Principle (ISP) states that an object should only depend on the interfaces it requires and shouldn't be forced to implement anything else. In object-oriented programming, this is called method chaining, which occurs when developers link too many objects for convenience. This often leads to the domino effect, and one little break can cause a train wreck. The same applies when developers chain too many microservices calls together. It's best to keep the call stack as shallow as possible to avoid rippling failures.
Microservices also abide by the ISP when designed around bounded contexts. This is because there is always supposed to be a boundary between interfaces that separate them into discrete and independently deployable units.
Dependency Inversion Principle
The last but not least of our SOLID principles, the Dependency Inversion Principle (DIP), states that abstractions should not depend upon details, but details should instead depend upon abstractions. This means that high-level modules should not depend on low-level modules. In a microservices architecture, this translates to the API gateway pattern and the fact that the gateway acts as a single point of entry between a client and a microservices architecture. Just as the client owns the API defined by the API gateway, a higher-level module should own the service interface.
Both OOP and microservices are still relevant and have their respective places in the enterprise. In fact, microservices build on OOP principles, and developers can use object-oriented techniques to create microservices. The good news here is that we don't have to reinvent the wheel, and developers can overcome a lot of microservices challenges by looking at past lessons we've learned from OOP.
