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.
Amongst others Martin Fowler published a blog about what is characteristic for Microservices and applications build on the foundation of this architectural style . According to this and other blog posts (see also , ), 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… Read the complete article here.
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.