Decreasing BSS/OSS “integration tax”: Part 4 – Cloud Native Architecture uses interfaces internally for greater flexibility

This BLOG post is the fourth and final in a series of short articles on the changes in BSS and OSS architectures arising from the changing underlying data communications, middleware, and data modeling software technology. In the last posting, we looked at how the Service Oriented Architectures (SOA), designed with integration in mind, further dropped the interfacing costs. Here we describe how these lower costs led to Cloud Native architectures from the major web-scale companies in the 2010s.

As SOA swept through the industry, it became popular to try to bring old legacy applications into the SOA framework. Of course, they could be rewritten, using modern software techniques. But it was (and has been for many years) a tradition that one takes the old systems and “wraps” them in a new technology (in the 1980s I first used this, “wrapping” an old subsystem and then adding it to one of those fancy new “busses” while building out the new functionality as other modules on the bus). In this case, a wrapper was used that provided SOA calls, including brokering and security capabilities for interfacing to other systems. Vendors like WSO2 (www.wso2.com ) and Apigee (www.apigee.com ) provided (and still provide) good systems for doing this. The whole approach became known as a “dual-speed architecture,” because IT shops could be split, with one team organized around the new (faster) methodologies, while the legacy systems people could continue their work. Oracle, in particular, is using this principal with its proven Siebel system and its new customer care software.

The SOA principal was very successful and computing resources became much cheaper in the last decade with the advent of utility computing and public clouds from the likes of Amazon, Google, and Microsoft. The cost reductions meant that other large software platform-based, web-scale companies such as Facebook and Netflix could also afford their own large (virtualized) data centers. The transcendent need of these companies was for agility – the ability to build out large-scale software systems quickly and evolve them quickly. (Note that the word “efficiency” was not in that sentence.) These companies (often called the FAANG companies – Facebook, Amazon, Apple, Netflix, and Google) pioneered a new software architecture that used the SOA concepts – but even for internal interfaces. They virtualized the software, containerized the software, and built it with internal SOA interfaces. These allowed the individual software components (dubbed “microservices”) to be developed, tested, and deployed (almost) separately (using a process often called “DevOps”), with frequent small microservices releases, and without requiring the large-scale integration testing of the past. This overall architecture is often called “cloud native,” since it grew from the cloud.

Cloud native software architecture is sweeping through BSS and OSS architecture, as is DevOps processes (but evolving into DevSecOps, perhaps, as security is added into the process mix). More on that later.