The amount of API traffic increases every day. But it’s no longer just the known players such as Google, Amazon, Twitter, Facebook and Salesforce (the API Billionaires Club) that will produce the related massive amount of data. Cisco estimates that by 2020 37 billion smart ‘things’ will be capable to connect with an API. The Internet of Things is here! But how should API-providers handle all these clients?
In most application landscapes services tend to pop up like mushrooms, with little to no attention being devoted to decent service design or decent service-oriented architecture (SOA). Frankly put, this means you’re doing it wrong.
Microservices are all the rage right now. It's an architectural style which promises fast delivery and robust, scalable systems. Some people say it's SOA 2.0. For a thorough introduction, I recommend reading this article by James Lewis and Martin Fowler. You could say that microservices are the love child of Continuous Delivery and DDD. Unfortunately, someone made a mistake when registering the baby. They got the name wrong.
In the last 5 years of my career as an enterprise architect, whenever the word "integration" came up, discussions started about the choice of an ESB (Enterprise Service Bus), SOA (Service Oriented Architecture), FTP or web services, SOAP or REST, XML or JSON, etc.
In short, when involved in discussions about "integration", one most likely finds himself drowning in a multitude of technical acronyms and technological standards.
I compare the technological side of integration to the "Dr. Jekyll" personality : it is the side well-known to everyone, stable, under control and increasingly complying to uniform standards.