What can we learn from the Microservices movement?

If you’re into integration, SOA or web services, you’ve probably heard the term Microservices fairly often lately. Is applying Microservices architecture the one-size-fits-all solution that can replace the traditional one-size-fits-all SOA solution that doesn’t fit anymore? Of course not, because the world isn’t just black and white and both architectural concepts have their pros and cons. However, I think we can learn from the Microservices movement to improve and modernize our traditional SOA systems.

Microservices vs traditional SOA?

As tradition dictates, you can’t write an article about Microservices without explaining what Microservices are. So here’s a link to Wikipedia and a picture: https://en.wikipedia.org/wiki/Microservices

So, now we have a clear understanding about Microservices, let’s also have a clear understanding about what I call “traditional SOA”. Traditional SOA, according to me, is a monolithic, semi-loosely coupled way of doing web services, where all services are deployed on a single platform (e.g. WebLogic Server), where services have a lot of dependencies, where scaling is an all-or-nothing effort and where most of the services are both stateful and synchronous. Typically, a canonical data model is used and services are sharing data stores. Obviously, there is much more to it, but you don’t need me to repeat whatever Thomas Erl and countless of other authors have already written.

Flexibility vs Reusability

Quite often, I sense the vibe that traditional SOA is old and irrelevant, while Microservices architecture is the only way forward. This is nonsense. In the end, what it comes down to is that traditional SOA relies heavily on reusability, while Microservices architecture relies heavily on flexibility. So, the main question in your reference architecture should be how much flexibility you need and how much reusability you want to give up on it. If you’re working on a disruptive new system that needs to adapt to changes rapidly, you have a different use case from traditional ERP or CRM integrations, where changes only occur occassionally and sudden scaling demands are not likely to happen. So, before you go and embrace Microservices, think about what kind of business you’re actually in and even if you have a need for Microservices, you probably won’t need them for all your integration efforts. I also strongly recommend using common sense in this matter, because dogmatic belief never leads to anything good. Basically, ask yourself what kind of system your service is for: a system of stability or a system of innovation?

What can traditional SOA learn from Microservices?

Let’s just say that you are not Netflix or Union Pacific and a traditional SOA approach prevails for your needs. Then you should still occasionally re-evaluate your SOA standards. Ideas that may have been great in 2011 might just have reached their expiry date, while new innovations can be analyzed to improve your architecture. I think that the traditional SOA approach can learn from the Microservices movement, because it gives a fresh perspective on things and makes us re-evaluate things we’ve been taking for granted. Even if your SOA implementation is successful and you hardly encounter any problems, establishing that you’re still on the right path can be useful! I’ve been doing SOA for a long time now and in many different projects I’m finding the same problems. How can we learn from Microservices to handle those problems?

Challenge #1: Scaling

Since everything is deployed on the same platform, scaling whatever needs more horsepower means scaling everything. With multitenancy in WebLogic Server 12.2.1, it’s possible to create domain partitions to overcome such problems. Try splitting up your SOA layer into different domains of services that scale together, possibly do the same with the underlying database, add work managers to those domains and you are already winning a lot. For example, I am currently involved in a project that deals with courthouse cases. Some cases are short running and happen often, while others are more rare, but longer running. Putting these into different domains will give you the flexibility to treat them differently, although dealing with underlying reusable services can still be a challenge. Those services could also be in their own domain though, but you could also go as far as deploying them to multiple domains or even having two different versions of such a service. Once again, it depends on the balance between flexibility and reusability.

Challenge #2: Performance

“Our services don’t perform!” is something that I hear too often. Obviously, here you need to look at the platform too: what’s the purging strategy, are we applying patches, is the configuration right? Tons of improvements can be made on that side, but pointing and blaming is no longer cool in the DevOps world, so we also need to look into the mirror: are we doing what we can to make our services perform well? Here we can apply some Microservices patterns: for example, if you are integrating between SaaS applications or between BPM processes and a relational database, do you really need stateful services in between? Think about the minimum of metadata that you need for each service and act on it: maybe use Service Bus instead of a Mediator, look at the use of each component in the service layering and get rid of redundant capturing of state. It will make your services run much faster. Try to be as stateless as you can be without getting into trouble.

Challenge #3: Dependencies

Dependencies are real killers of success. While Microservices are fully responsible for their own well-being, traditional SOA services tend to aggregate, orchestrate and use shared resouces. Aggregation is inevitable, but for orchestration there are some nice alternatives. For example, I’ve worked at a project where we had two BPM layers: one for end-to-end business processes that do orchestration and one for domain-bounded processes that do the actual processing. Instead of letting the top layer do orchestration through web services, you could also make it more loosely coupled through JMS or Events, so the entire building doesn’t collapse when one floors burn downs. At least consider it.

Another major dependency is the canonical data model. Having a general CDM that affects all services can be extremely inflexible and leads to unclear service definitions. I prefer a domain driven CDM approach (also see Challenge #1): make a CDM for each logical domain and have internal reuse of the objects (same namespace), while between domains there can be differences. For example, I have an Employment domain and a Person domain: in this case, a change in Person without relevance for the Employment domain will have no impact. This has the downside of needing some transformations, but at least you have a reasonable balance between flexibility and reusability. Personally, I don’t believe in taking such an approach for each individual service (hello Microservices), because you probably still want to be able to push through non-breaking changes quickly. Find your own balance in this, but try to avoid extreme measures.

Challenge #4: Purpose

With a Microservice, you always know exactly what it does, because it does exactly one thing. In SOA, we should also embrace such an approach, at least partially. Always try to make a service about exactly one object and make seperate services for “get” and transactional operations for the sake of scaling. Logically, aggregations can’t always be avoided, but then the aggregation itself should be considered one object. Also try to not make too many variations of basically the same operation: if needed, use a specific, non-reusable connector service for applications who need specific sorting, filtering etc…

Conclusion

Many organizations are struggling with their SOA approach, while not having a clear use case for rebuilding everything in a Microservices architecture. I believe that reading into the subject helps to understand the challenges that come with traditional SOA and I hope that this blog can help you address those challenges, as well as trigger you to put your design patterns under scrutiny on occasion. By gathering inspiration from different architectural approaches, we can already make a difference without fully adopting those approaches.