What is the impact of distributed architecture to API lifecycle?
As part of co-operation with apidays conferences, and apidays Helsinki 2020, a joint online event was held in collaboration with Joint Research Centre of the European Commission on public and private sector co-design on API development.
After presentations by public sector organizations from around Europe, a panel discussion summarized and aimed to answer the questions coming from these public sector organizations.
Private sector seasoned API experts Alan Glickenhouse (IBM) and Marjukka Niinioja (Osaango, panel chairperson), as well as Lorenzino Vaccari (European Commission, JRC consultant) discussed API-related questions presented by the public sector speakers in part II as well as topics brought on by the audience.
Panel concentrated on questions related to lifecycle management, discoverability, API design and security.
What is the impact of distributed architecture to API lifecycle?
Questions for the panel:
- How does moving to microservices or distributed architecture impact the API lifecycle?
- How to handle this change organizationally?
Glickenhouse: API and microservice are not the same thing. Not every API is built on microservice and not every microservice has a managed API. Microservices are a great way to introduce agility to the architecture, but that is a separate topic from which APIs to provide to our consumers. The consumer might be in a different network environment (e.g. on-premise or cloud) than the other service it consumes, and you might use an API for that. Inside one application, you might not integrate the multiple microservices that make up the application via APIs.
Niinioja: When I was co-authoring the book “API economy 101” we went through a lot of research, and one area was about the impact to organizational structures, the move from “integration paradigm” to “ecosystem paradigm”. The “ecosystem paradigm” means that independent teams inside and outside the organization can work and communicate together by exposing their capabilities via APIs.
Vaccari: Also because of the extreme heterogeneity of public services they offer, public organizations are frequently working like internal silos, often developing their own APIs. These are not necessarily microservices, while some are. The problem is to exchange information across the silos on who is developing which of these small programs and capabilities. Sometimes two departments are developing the same components. Still the change from monolith to smaller components is good and creates dialogue between the silos, even if it at first starts with the technical issues. Then you get to the organizational level and the question turns into how to mutually provide better public services for the society by using multiple software modules from many sources. So, on the positive side, using microservices promotes reuse, but also requires a lot of coordination.
