When I was in engineering school, Computer Science classes covered many fascinating topics, ranging from the theory of programming languages to development methodology to actual coding projects. I was thus exposed to a variety of languages ranging from Pascal to Ada to Fortran to SQL to C -- and to the latest innovation: C++ (Java wasn't born yet). I'll readily admit that coding wasn't my forte, which may be why I am now a marketer of software rather than a developer.
Nevertheless, I recall that the paradigm that was emphasized the most in my C++ classes was its object-orientation, which promoted the development of code units that were autonomous and reusable. Having learned the basics of coding with forgiving Pascal, it was easy (and tempting) for me and my fellow students to replicate in C++ the same techniques, so it was really important for the teachers to ingrain these concepts in our minds. (Now, I must really sound like a dinosaur, but believe me there were even older languages and techniques! I never learned COBOL for example.)
Anyway -- fast-forwarding to recent application architecture, it is striking how the same concepts keep resurfacing, albeit in different contexts. A decade or so ago, applications were built as big, monolithic systems running in application servers (remember J2EE?). Of course, object-oriented paradigms were implemented in code units inside the application -- after all the Java concepts closely resemble C++. But the entire application was designed and developed as a whole, maintained as such, and retired in its entirety (or, most often, not at all).
SOA (Service Oriented Architecture) and the Enterprise Service Bus brought a partial answer to this monolith challenge. But SOA carried significant complexities of its own, and was never able to penetrate below the application layer: it is a solution for making applications work together, not an answer to the challenge of building modular applications.
Today, more and more applications are designed as a set of capabilities or services that interact through APIs. The latest trend is microservices:
a software architecture design pattern, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs (Wikipedia).
A microservice embeds its own application server or runtime, its business logic, and data if appropriate. It doesn't even matter which language the microservice is developed in, since interactions are performed through standardized RESTful APIs.
Moving back one level of abstraction -- APIs are also used for interaction and integration between applications. Modern development techniques expose data and business processes through APIs that can be consumed easily by other developers in their own applications.
The key to making applications work well together, is to insulate one application from changes in the other applications, or one service from changes in the other services. This is why APIs provide the right interface: An API developer can change the underlying business logic at will, as long as the interface with other systems (the “contract”) is preserved. This way, an update to a backend process does not require the redeployment of thousands or millions of instances of a mobile app, or the simultaneous update of dozens of applications that use this service (and are usually on different update cycles).
Of course, there are rules on how APIs must be managed if you want your applications to API-ly work together. I'll get back to these in another post.
This article is published as part of the IDG Contributor Network. Want to Join?