Welcome everyone to the API360 Microservices Summit. It’s great to be with you here in New York at this stunning venue, and we’re very excited to deliver a packed agenda full of insightful speakers and panelists, covering very important content that cover all perspectives on microservices.
Before we begin the event, I would like to take a brief journey through time. One of the most important perspectives we can take is historical. It’s always good to learn from the past so we can prepare for the future. And analogies help. So here we go…
Once upon a time, rail was the most popular form of travel. Throughout the nineteenth century, the technology of train travel experienced repeated innovation. Trains took more people to more places than ever before.
But there were problems. It was very expensive and labour-intensive to lay down tracks and other infrastructure required for train travel. Destinations were limited. And travelers needed to depend on the schedules of the railroads to determine when they could travel, and what other stops would be required.
So at the end of the 19th century, in spite of the incredible progress people had experienced through train travel, the motor car was revelation. Drivers could take cars where they wanted to go, when they wanted to go, with more freedom on road type. It gave these drivers more control and independence. However, cars were initially only available to the rich or to hobbyists willing to put a lot of time into maintaining their prized possessions.
When Henry Ford created the Model T and the assembly line method of production to go along with it, he made cars more accessible to the masses. Now more and more people could take advantage of this independent mode of travel.
But with that mass adoption came a new set of problems. Traffic. Pollution. Accidents. Although the experience of the driver felt self-controlled and independent, all those cars together created an intricate system that suffered from issues of complexity.
In order to take full advantage of car-based transportation, society had to adopt controls and supports at local and general levels: traffic control and highway systems, gas stations and petroleum production, repair shops and automotive research facilities.
I think this is somewhat analogous to software engineering today, and in particular where we find ourselves with microservices.
In contrast to monolithic systems, microservices are touted for their independence and manageability, much like the contrast between trains and cars.
Modularization technologies—especially web APIs and containers—bring similar benefits to the production of software as the assembly line did for automotive manufacturing.
But with all of the enthusiasm around the benefits of microservices—the equivalent of a turn of the 20th century motorist hitting the open road on a Sunday afternoon—how can we prepare for and deal with the system aspects of microservice architecture that will ultimately decide its impact on the software world? That’s what today is about.
