Service-oriented or vertically integrated?

One of the success factors that helps Coldrift deliver qualitative applications with consistent reliability and latency is vertical integration. Vertically-integrated solutions are solutions that are much more tighly bound inbetween the layers.

An example of a vertically-integrated solution is an application that uses awareness of database-specific functions or database structure to speed up queries or implement failover functionality. Other examples of vertical integration are:

• boosting an application implemented in a higher-level language with modules written in lower-level language
• software that relies on specific functions of a specific operating system
• datacenter-aware software and deployment

Naturally, vertical integration makes evolution of an application more expensive, but if the odds are right this is sometimes the only way to deliver up to the requirements on time.

The opposite of a vertically-integrated solution is Service-oriented architecture (SOA). It's a software design paradigm where services are provided to software components by other software components through a communication protocol over the network. In this way components are theoretically isolated from each other and can be also arbitrary deployed. They also can be theoretically made independent of vendors, products and technologies. In SOA ties between the layers are strictly undesirable. That's why service-oriented way of thinking conflicts with vertically-integrated approach.

To make an application service-oriented you must slice its functions into components and attach them to a service-oriented message bus. A service-oriented message bus is a layer that interconnects all the components and manages coordination and communication between. In this way the message bus becomes the absolute point of failure. To service all requirements it must be absolutely reliable, it must be absolutely scalable and it must accomodate vast variety of interfaces and modes of operation.

Once it fits all the requirements, the message bus becomes a product of its own. Essentially, there are commercial implementations of service-oriented message buses and they're being marketed to you and there are operating costs to them.

However, the business landscape of the last decade has enourmously challenged service-oriented architecture. It adds a new requirement: a service-oriented architecture presumably must cost nothing to implement. That's because for emerging businesses, when a product is not commerically ready yet and generates no business, a service-oriented message bus is a pure liability.

Fortunately, in the last decade, again, the market has offered an a alternative to service-oriented message buses. This is REST, representational state transfer and cloud services.

REST already has its own coordination service (DNS), routing (HTTP load balancers), adaptation (proxying) and so on.

Cloud is pushing commercial service-oriented message buses into the enterprise world, where software components already exist and serving purpose, and setting up a service-oriented message bus introduces order into the chaos. In this way installation of the service-oriented message bus becomes commercially viable.

For the new projects, however the advice of Coldrift is to use REST as your service-oriented message bus. With this choice you provision yourself not only space to manouvre, but also extreme performance and adaptability that are so important for innovative projects.