New Web service architectures are not the old SOA
What is the difference between the old SOA that everyone hated, and the new REST / Microservice / MAXOS service architectures? The old version of SOA (service oriented architecture) was promoted 10 years ago as the next big thing in enterprise software development, and then discarded because it was so annoying. The new service architectures are taking over the world. Both systems contain re-usable services. But the two system are very different in the way that they handle changes. The old SOA was designed to produce long-lived components that don’t change. The new service architectures are designed to be used and evolved and modified by humans.
The old SOA was designed with the goal of building long lived components. They would be reused, but they wouldn’t be changed. They would go into a catalog of services that were strongly typed, and the locked down. Defining and using an API was a lot of work. The old SOA was designed to be reliable without testing. If you don’t change a component, you don’t need to test it. If you have a strongly typed and defined API call, it should work the first time.
It had to be that way, because people were not running continuous integration. Continuous integration produced a revolution in the way that services could be tested and evolved.
Enter continuous integration
The new service architectures are designed with less structure in the API. The API calls can contain variable data. They don’t need to be strongly defined in advance. They use HTTP to communicate between different programming languages and platforms. And, they change. With all of those variations and options and changes, it’s not guaranteed to work the first time. But, it’s easy to get it to work because we are working hands on with the code (coding is much easier now) and we are testing with continuous integration. It’s a malleable system that grows and evolves quickly and easily.
Continuous integration is the enabling technology that allows us to get away with using these more loosely defined API’s, and make them reliable. And, the enabling technology for continuous integration is cloud servers. The old SOA services were often locked down on physical machines, to be moved and updated only with great care. With on-demand cloud servers, we can always get test versions and new versions of our services.
Here are some of the technical differences:
Old protocol: SOAP — highly structured calls with related strongly typed arguments and code for describing and discovering the API calls and arguments. Proprietary authentication and security. Building a SOAP service is complicated. Using a SOAP service requires many special libraries. Before SOAP was CORBA, which was even more cumbersome.
New protocol: REST — Any Web-type app can accept REST calls. Arguments are loosely typed, typically in JSON strings that can be extended with new kinds of data. HTTP authentication and security.
Old language: Java — or related languages with libraries for SOAP and service discovery
New language: Any computer language, often mixed
Old catalog: designed to be used by machines doing service discovery
New catalog: designed to be used by human programmers working with living code and running test systems.
These are big differences. It takes only a few minutes to make up a REST call from almost any language. I remember being blocked for days when trying to make a call from Ruby to a SOAP system.
