Microservices architectures „“ Thoughts from a SOA perspective

Thoughts by: Sven Bernhardt, Richard Attemeyer, Torsten Winterberg, Stefan Kühnlein, Stefan Scheidt

A frequently discussed topic these days is the Micorservices architectural paradigm. Discussions on various internet blogs and forums are showing the trend that proponents of this approach are not tired of emphasizing why Microservices are different to a holistic SOA approach, when dealing with breaking up or avoiding monolithic software architectures.

For this reason it“™s time for the Cattle Crew team, to take a closer look on this arising architectural style and the corresponding discussions from a different perspective.

Microservices Architectures

Amongst others Martin Fowler published a blog about what is characteristic for Microservices and applications build on the foundation of this architectural style [1].  According to this and other blog posts (see also [2], [3]), the goal of a Microservices approach is to avoid software systems to become monolithic, inflexible and hardly manageable, by splitting a system into modular, lightweight and maximum cohesive services. Applications build on this architecture should ensure the agility regarding changes caused by changed business requirements, because affected services of an application can simply be adapted and be redeployed independently from other components.

Effectively a Microservice is a in itself cohesive, atomic application, which fulfills a dedicated purpose. Therefore it encapsulates all needed elements, e.g. UIs, logic components, may also have its own separated persistent store and may run in a separate JVM, to ensure as less impairment to other services as possible. Furthermore the implementation technologies for a specific service may vary. For each service the best-fitting technology should be used; there should be no restrictions regarding the used technologies.

To ensure consistency as well as compatibility with already existing components in case of changes and to guarantee seamless release management of changed components, a Continuous Delivery procedure is indispensable for succeeding. In addition the implementation efficiency benefits from the Microservices approach, because different components may be developed in parallel. Communication between the services, if needed, is done via lightweight protocols such as HTTP. Well defined interfaces are depicting the service contracts.

Where there is light, there is also shadow“¦

One of the basic questions, we asked ourselves when discussing the Microservices approach, is how to determine respectively which metrics to use for evaluating, if a service is a Micorservice or not. Resulting from that it would be interesting what if it is no longer a Microservice: is it directly a monolithic service?

A clear definition about what are the differentiating and unique characteristics of a Microservice cannot be found. Metrics like lines of code or number of classes are no appropriate characteristics, so something spongy, like specific business functionality has to be taken as a distinctive mark for a real Microservice. But that“™s not really measureable“¦

Besides the missing clarification about the Microservice term as such, building business applications using a modular Microservices architecture means a higher complexity than when using a classical monolithic approach. From conception to delivery to the operating this higher complexity may raise the following challenges:

• Right level of service granularity; not too coarse grained, not too fine-grained
• Comprehensible service distribution for scalability reasons and the corresponding monitoring
• Complex testing procedures because of loose coupling and service distribution
• Consistent and tolerant Error-handling, because a referenced service might be down for maintenance reasons (Timeouts, Retry mechanisms, etc.)
• Reliable message delivery
• Consistent transaction handling, because of cross-service communications using non-transactional protocols like HTTP mean the establishment of complex compensation mechanisms
• Guarantee of data synchronization and consistency, when services have their own and exclusive persistent stores
• Sophisticated Service Lifecycle Management, because every service has its own lifecycle including challenges like how to deal with incompatible interface changes

Another risk we see with a naive implementation of the Micorservices architecture is a fall-back to the days of distributed objects: Calling a magnitude of services is not a good idea because of latency and (missing) stability.

Microservices and SOA

When dealing with the Microservices approach it is conspicuous that at least one paragraph could often be found, stating something like „Microservices vs. SOA“, where it is depicted that Microservices and SOA are conceptually different. In this context the idea of SOA is often reduced to technology terms like WS* or ESB and therefore referred to as heavyweights. This definition of SOA only covers possible implementation details, because from a conceptual perspective SOA is also an architectural paradigm, making no premises regarding implementation details or the corresponding technologies to use for a concrete SOA implementation.

When looking at the sections before, describing Microservices-based architectures and its challenges, it can be stated that very similar concepts and challenges arise in SOA-style architectures, because characteristics for Service-oriented architectures are loose-coupling, standard-based and stable service contracts, distributed services and flexibility as well as agility regarding changing business requirements. The resulting challenges are nearly the same. As a reason for this, in our opinion the both approaches aren“™t so different essentially.

SOA-style architectures historically often use SOAP-style communications. But regarding this fact we are observing a change: the number REST-style SOA services is growing. A trend which is mainly influenced by the increasing need of multi-channel support, e.g. for mobile devices, where REST-style communications by using a JSON-based data format is the preferred variant. The big software vendors, e.g. Oracle, also recognize this trend and therefore have extended out-of-the-box support for REST services.

In system architectures that are based on the SOA paradigm, an ESB is often used to integrate different enterprise applications. Classically it cares about routings, protocol as well as data transformations and service virtualization. So point-to-point integrations between systems can be avoided and makes an IT system landscape more flexible regarding adding new applications as well as services. In our opinion this can“™t be called heavyweight and is indispensable for increasing agility.

Furthermore the microservices proponents do not say any word about service governance. This is also ok for some sorts of SOA services. We often differentiate services into public and private services. Systems consisting of multiple components are often organized as a set of collaborating private services [4]. These interfaces are not published enterprise-wide and must therefore not adhere to more strict policies applied to public services. The offical / public interfaces of a system are in contrast published as public services.

Thus from our perspectives, Microservices are nothing new, but rather an implementation of the concept of private services.

Summary

Microservices architectures are primarily focusing on a local, application-based scope and provide a very flexible as well as modular approach for developing easy-to-extend applications. In summary it can be said that the Microservices architectural paradigm seams to deliver great benefits though it must be stated that the approach is not a completely new concept. Compared to that a SOA approach has a farsighted, global scope aiming at the enterprise level. From a SOA perspective, Microservices could be understood as private services, not necessarily exposing their functionalities for reusing them in other systems or services. But that is ok, because in service-oriented architectures one does not expose a service, when there is no need „“ which means no need for reuse in other applications or services „“ for it.

Taking all points discussed in this article into account, we would recommend that discussions about differences between Microservices and SOA should be avoided. Instead it should be evaluated how and if a coexistence of these two very similar approaches is possible to deliver the most valuable benefit for system architectures as possible, making IT system landscapes more flexible and therefore promoting business agility.

[1] http://martinfowler.com/articles/microservices.html

[2] http://microservices.io/patterns/microservices.html

[3] http://www.infoq.com/articles/microservices-intro

[4] http://www.oracle.com/technetwork/articles/soa/ind-soa-canonizing-language-1957510.html