Zoekwoorden:
Application Development, information technology, Data
Type:
Stage
Locatie:
Amsterdam
Opleiding:
Bachelor (EQF 6), Master (EQF 7)
Gepubliceerd:
08/10/2021
Status:
Open
Reageer voor:
31/12/2021
Uur p/wk:
40

Beschrijving:

Context 

In ING we created a microservice architecture in order to deliver customer features in an agile way. We have employees working squads that are responsible for one of more microservices delivered as REST APIs. Working in small teams allows fast coding and high availability as the scope of the single API is limited. The result of this is a highly connected environment with a lot of interdependencies between APIs that brings another challenge. 

 

Challenge 

Fast coding? It turns out teams have a lot of dependencies that need to be in place before teams can code out their API. E.g. if API A needs data from API B to deliver its functionality then API B needs to have its documentation stable (Interface contract), test environment needs to be set up and stable, test data needs to be aligned with other APIs). 

 

High availability? As the single API can be quite stable, the whole chain of APIs is as stable as its weakest link. There appear hot spots APIs in the architecture that need to be called a lot by other APIs. These APIs can have a large change frequency and have to cope with high load. They are commonly the root cause of outages (both in test and production environments) 

 

For most of these APIs, tracing data is available. In the precious student assignment, an architecture diagram can be extracted from the tracing data. Based on this visualization, some graph metrics are applied to detect architecture changes and anti-patterns. Moreover, the performance information is also included in the edge attribute and visualized in the architecture. For example, response time, number of calls in the past an hour between two APIs etc. 

 

We would like to extend the previous assignment on the following directions: 

  • Using the architecture visualization for monitoring availability of customer features 

  • If a change happens, can we do a simulation on how the architecture is impacted? 

  • Improve visualization: currently the architecture is visualized as a graph, is there another way to visualize 

    it so that all possible paths in one journey can be visualized once? For example, applying process mining 

    techniques. 

  • Etc. 

Expected project outcome: 

  • Study current industry standards and the ING architecture and way of work, and identify gaps 

  • Study state-of-the-art scientific papers and the ING architecture and way of work, and identify gaps 

  • Create showcase applications to demonstrate the ING architecture, and conduct experiments to show how 

    dependency issues can be mitigated. 

  • Etc.

Candidate Profile:

  • We are looking for a student with the following profile: You... 

  • like developing applications, a JVM language that consume and/or produce REST APIs 

  • are curious about Graph theory, architecture visualization/refactoring, DDD, contract testing and TDD 

  • are interested in collaborating with different squads. 

  • are a team player. 

  • are able and willing to closely work with ING