Service Oriented Architecture (SOA)
It is a design approach. It's fundamentally a new way of approaching the design of solutions for an enterprise in much more modular componentized fashion. It has origins in component based development in the 90s, functional decomposition in 80s and modular systems programming. It is not about a particular technology approach WS* standards, or any of those particular technology standard is fundamentally about a new design paradigm of how we design solutions.
Why it is so important?
Together with its ally business design approach - a discipline of Business Process Management, it's at the heart of design of a new approach that delivers a much more agile organisation where it's much simpler to change processes in source regarding source capabilities and operate in a industry deconstructing model.
Integration and evolution over time:
We started with integration approaches of what's generally referred to as point to point, where an application A needs to talk to application B. We built an interface between them, and if application A need to talk to another application C then we need to build another interface between them, and the result over that ended up in what generally is referred to a spaghetti architecture. It is a ball architecture with the whole pile of interconnections in the place that makes the overall environment in an organisation incredibly fragile and bitter and difficult to change.
This evolved in to what is called an enterprise application integration where we put a piece of middleware, typically a message broker in between, and then if application A wants to talk to application C, common functionality like logging and massive transformation etc. were delivered in this piece of middleware. But fundamentally if application A wants to talk to application B we would still build an interface specifically for that purpose. If A wants to talk to C we build another interface. So it's an improvement. We now have a hub and spoke model, where we have a central point for monitoring and everything going through a single point for common functionality to be implemented. But still we are building effectively dedicated interfaces between them. And it was still designed from an application centric perspective.
So then we want to move to Service Oriented Architecture. This is a real paradigm change. Here we did not design any more interfaces for the specific applications need, but rather we look at the whole overall environment in a business, and designed a set of services that could be consumed by anywhere else in the organisation to perform proved business functions. So fundamentally it's a different way of thinking about solutions and designing services to deliver a much more agile ecosystem.
And then came microservices (not much fundamentally different from SOA). It differs from SOA on two fundamental point of view.
- It adopts a much lighter weight protocol like HTTP rather than WS* standard etc., and typically it's viewed as not having an ESB.
- There are smart endpoints but dumb pipes, rather than being viewed as ESB (enterprise service bus) or no ESB. People see them as technically new concepts, but they are just technical implementation details. The overall design paradigm has not changed. SOA and microservices has much more in common than difference.
Some common points:
- They both must be independently deployable.
- Must encapsulate the data they own.
- The service interfaces are separate from the implementation.
- They are language and platform independent.
- They are loosely coupled.
- They are designed for multi-use independent of any particular customer.
A lot of advocated of micro service architecture would say that there is critical difference between it and so don't use ESB. They say that don't use some of higher order functions that came with the ESBs like business process execution language or BPL orchestration, WS choreography and some of those things. But most ESBs are built on message brokers, and microservices architecture requires some way and some dumb pipe even for it to be delivered and for these communications to exist between the two endpoints.
Even if you use an ESB for a microservice architecture, you don't use some of the higher functions. (What functionalities an ESB should use and what should stay away.)
What results in inappropriate use of ESB is two core problems:
Not understanding the correct granularity of your services.
Not understanding difference between a process orchestration and a service orchestration. (In technical terms, what functionalities should be implemented on a BPMS or a businees process management suite, and what funcitonalities should be implemented on your integration platform (be that an ESB, a message broker or an enterprise application integration platform)).
Service Granularity - We kind of know inherently that process loan mortgage origination is a full intent process and organization, and not a service. So it is too coarse to be an enterprise service. On the other extreme update customer first name, update customer second name etc. are too fine grained. Somewhere between those two is the right granularity. But finding out what that is - is a non-trivial exercise and requires quiet a bit of rigor to be brought to the design process. But once you do so, it will effectively deliver a microservice architecture. It will deliver the service with right level of granularity. The term "microservices" emerged because most of the implementation of SOA used too corase service granularity and cause bad design. But it also just as bad to go too low to the level of granularity in the microservices. Ex update customer first name service. Update customer second name service etc. Microservices should be right sized services in terms of granularity.
Understanding - when what should be implemented in enterprise service or your integration platform, and what should be on a business process management platform. If you get this right you will avoid inherently using some of the more complex functionality which in our view should probably should not have existed in an enterprise service bus like deepal. In fact the hint is in term itself business process execution language. It's inherently a process execution language and not a service orchestration language, and attempting to implement processes on an ESB instead of on a BPMS and is what has largely resulted in the bad name for SOA.
Microservices is SOA done right.
The critical difference is the service granularity.
SOA really is four sentences:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Service compatibility is based on policy
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralised management of these services, which may be written in different programming languages and use different data storage technologies.
From this definition, it's clear that microservices fulfil at least the first two tenets (with a real emphasis on the second), but it's questionable whether they fulfil the third. The reason the third tenet may not hold for microservices is that one of the characteristics of microservices is that they are generally exposed over a RESTful API, which, one could argue, does not expose contract and schema at all.
Following the original tenets of SOA does not prevent me from manually copying my service binaries into my production environment, but with the microservices approach, the service deployment and management should be fully automated.