
Santiago Gomez Saez is a Technical Product Owner of the API platform offered by Volkswagen Financial Services. In this article, he discusses the automation of APIs in a highly compliant ecosystem.
One of our main challenges in enterprises nowadays is that we want to maximize the development speed and the releases of APIs while still being compliant in a highly regulated ecosystem.
Volkswagen Financial Services is the financial backbone of the Volkswagen Group. Approximately six years back, we started with a digital program aimed at digitalizing our business processes for our customers. That means bringing the customer data into the center of the equation. We can gather customer data and provide assessments to the customer. We aim to sell as many contracts as possible online worldwide. That meant that we needed to scale. For us, scaling doesn’t mean increasing the number of customers or the load on the system. This meant that we wanted to increase leads and increase the adoption of our digital customer journeys with our end customers.
This required us to look at how we were building technology. And more specifically, it required us to look at how we are standardizing. We standardized different layers of our architecture. We standardized the running of our workloads on top of Amazon Web Services. We standardized data provision within the organization, ways of building APIs, the tooling platform, and sharing APIs within the organization. Last but not least, we standardized our front-end development.
Standardizing our API layer
We have built our standards on the following four pillars –
- API platform-as-a-service atop AWS
- Standardize and automate API Lifecycle
- Tool chain supporting the API Lifecycle
- Our customers are API Engineering Teams in Volkswagen Group Financial Services
Our Architecture
We run on top of Web Services. Amazon Web Services offers the possibility to have a very highly distributed ecosystem. One API owner should not have access to another API owner’s infrastructure, and all of them should have access to the platform’s core components. With this, we were able to offer a highly distributed ecosystem, where we have a central account where we have the core components of the platform like API Gateway, API Portal, and platform APIs. Each team, project, and product has its own AWS ecosystem where they can deploy those APIs.
Using these four pillars and the deployment model helped us go from zero to 140 APIs in one and a half years. And those APIs are distributed in more than 100 AWS accounts. Our API platform is running in six regions. Nowadays, we are handling more than 500 million API requests per month.
API Lifecycle
- Design – We follow an API-first approach. That means that every API must start with a design requirement and then the design of the Open API specification. To facilitate the specification of an Open API document, we created a so-called API dictionary, basically consolidating a standard way of defining API models, especially for fields, e.g., name, description, type, etc. Everything starts with an Open API. Open API is a rich specification that can be used for specifying APIs and generating any kind of artifacts afterward. We have a governance model on the API dictionary to conduct reviews to ensure the quality of the dictionary’s content.
- Generate – We have generation tools to generate an executable API project. Let us assume that we have an open API specification and we run the tool. The tool will generate a project. It will generate the microservice with different information, for example, documentation, error logs, etc. It will also generate the main code that will serve as a skeleton for a developer to develop the business logic inside the API. The main advantage of using our tool is that it will give the developer specific endpoints for the API. The tools also generate performance test skeletons.
- Implement – The basic skeleton has been generated. The API developer has to implement the business logic within the API skeleton.
- Deploy and Publish – Once the API is ready and running locally, it must be deployed and published in an ecosystem where others can access it. The tool builds the necessary resources in the AWS ECS container, the Docker Image, and interacts with the Kong API Gateway to publish the API on our platform.
- Monitor – After the API is in the ecosystem, we monitor it for usage and any issues.