Faire face aux défis d’utilisabilité des APIs:du développement au déploiement des applications
logicielles
Mohamed Aymen Saied

1

Portrait géneral de mes travaux de recherche

Amélioration dela productivité desingénieurs
logiciels

Réutilisation

2

Automatisation

Portrait général de mes travaux de recherche

L’identification desproblèmes de réutilisation
des APIs?

3Solutions pour une
réutilisation correcte desAPIs

Inférence des composantsréutilisables à partir desAPIs

Réutilisation d’APIs pour ledéploiement d’application
dans le CloudApplication Programming Interface (APIs)} Les logiciels réutilisent des fonctionnalités fournies par des librairies logicielles} Les librairies exposent leurs fonctionnalités via des APIs} Documentation décrit comment interagir avec l’API

4

Développement logiciels et APIs}

Les logiciels modernes utilisentintensivement des APIs}

L'utilisation des APIs demande
beaucoup d'efforts}

La mauvaise utilisation des APIs
entraîne différents types deproblèmes}Impact sur la productivité

5

Documentation
souvent
incomplète

Comprendre
et apprendre
à utiliser lesAPIsSuivrel’évolution desAPIs

Identifier lesfonctionnalités
nécessaires

Comment améliorer l’utilisabilité des APIs?
Méthode}Pré-conditions (paramètres de la méthode)API : plusieurs méthodes d’une API
Quelles méthodes utiliser ensemble} Ordre et/ou contraintes d’appel}

Plusieurs APIs
Combinaisons possibles d’APIs} APIs compatibles et faciles à intégrer}

6

Méthode

API : plusieurs méthodes d’une API

Plusieurs APIs
7

Exemples de contraintes
Identifier les pré-conditions(contraintes) sur les paramètres
de la méthode}“Range limitation”} La restriction sur les valeurs de paramètres va au-delà des restrictions définis par les types

déclarés8Motivation
Fréquence dans 24 APIs (incluant JDK)

9Documentation de contraintes (excluant JDK)Inférence utilisant des programmes clientspublic clientMethod(int p){...
if (p >= 0 && p <= 100)
apiObj.apiMethod(p);
...
}

10

Inférence utilisant le code de la librairie}

Analyse intraprocédurale{ ttl : ] − ∞,+ ∞[ }if (ttl < 0)
{ ttl : [0,+ ∞[ }{ ttl : ] − ∞, 0[ }
TF

throw

if (ttl > 255)

F
getImpl().setTimeToLive(ttl){ ttl : [0,+ 255] }........

{ ttl : [0,+ 255] }11returnTthrow{ ttl : ]255,+ ∞[ }Inférence utilisant le code de la librairie}

Evaluation (intraprocedurale)} 13 APIs

Précision
Range Limitation

100%

Range Limitation

Rappel
85%

Nullness Allowed

96%

Nullness allowed

78%

Nullness not Allowed

97%

Nullness not allowed

84%

Type Restriction

100%

Type restriction

94%

12MéthodeAPI : plusieurs méthodes d’une APIPlusieurs APIs13

Inférence de patrons
Quellesméthodesutiliser ensemble} Patron d'utilisation}

Un sous-ensemble (ordonné ou non) de méthodes pouvant être utiliséesconjointement par les programmes clients} Problème de clustering

Distance de co-utilisation entre les méthodes de l'API} Les données}} Code client vs librairie
14

Inférence de patrons non ordonnésCas où les programmesclients sont disponibles}

Client_method1:

m1

m2

m3

m6

Client_method2:

m1

m2

m3

m4

m5

Client_method3:

m1

m2

m3

m4

m5

Client_method4:

m1

m2

m3

m4

m5

Client_method5:

m1

m2

m3

m6

Distance de co-utilisation des méthodes} Proportion de méthodes client partagées

15

Inférence de patrons non ordonnésCas où les programmesclients ne sont pas
disponibles

Nouvelles
APIsAPIs nonpopulaires}

Estimer la distance de co-utilisation entre les méthodes} Proximité structurelle: proportion d'objets de la librairie partagés entre les méthodes} Proximité sémantique: similarité cosinus (avec LSI) entre les vocabulaires des méthodes

16Clustering des méthodes
Regroupement basé sur les distances/estimations de co-utlisation} Seuil sur la distance}

ε17Clustering hiérarchique des méthodes}

Grouper les méthodes en plusieurs niveaux en fonction de leurs distances / estimations de coutilisation}

Des patrons à différents niveaux de forces de co-utilisation

ε1
ε2ε3…
εn18

Inférence de patrons complexes}

Plus que de simples groupes de méthodes}

Exemple} Lorsque la méthode m1 est appelée, la méthode m2 est appelée juste après et la méthode m3n'est jamais appelée plus tard, ou m2 n'est pas appelée juste après et m3 sera appelé}

Peut être exprimé en LTL (Linear Temporal Logic)!(# → %!(! ')) ⊕ !(# → %! *)19

Inférence de patrons complexes
Apprendre les formules LTL} A partir des traces d'exécution} Utilisation de la programmation génétique}Espaces de formules LTL possibles(Toutes les combinaisons de méthodes avec des opérateurs temporels et logiques)

Knowledge derivation
Traces(Séquences d'appels des méthodes de l’API)

20

Formules LTL(conformes aux traces)

Inférence de patrons complexes

Créer une population initiale deformules LTL

Retourner lemeilleur ensemble
de formules
Oui

Appliquer des formules sur destraces et évaluer leur applicabilité

Critèresde finNonRemplacer la population actuellepar la nouvelle

21

Dériver de nouvelles formules enutilisant des opérateurs
génétiques

Assister les développeurs dans l'environnement dedéveloppement

22

Méthode

API : plusieurs méthodes d’une APIPlusieurs APIs23

Patrons d’utilisation de librairies
De nombreuseslibrairies

Comment choisir deslibrairies
complémentaires etfaciles à intégrer

Les librairies sontdocumentées
séparément

} Intuition}

24Les librairies fréquemment utilisées ensembles ont des fonctionnalités
complémentaires et sont faciles à intégrer

Patrons d’utilisation de librairies} Inférence des patrons}

Problème de clustering}

Distance de co-utilisation} Proportion de clients partagés}

25

Patrons = groupes en multi-niveaux

Les APIs du développement au déploiement} les APIs sont importantes pour l'environnement de déploiementEnvironnements infonuagiques (Cloud)} Infrastructure virtuelle}} Créée, modifiée et supprimée par des APIs}les applications} Configurées et déployées par des APIs} Appliquer l’inférence de patrons sur des APIs de déploiement d'applications}

26

Inférence de patrons/schémas de déploiement

Application basée sur les Microservices (Cloud-Native)
Application Monolithique

Application Microservices•

Un seul bloc intégrant toutes lesfonctionnalités•

Sépare les fonctionnalités en
différents petits services•Déployées et exécutées en un seulprocessus•

Déployés indépendamment

BD

27

Microservice
Microservice

Microservice

MicroserviceBDBD

Microservice

Microservice

BDApplication basée sur les Microservices (Cloud-Native)} Application Microservices} Application Monolithique}}

Passage à l’échelle}}

Variation du trafic}

Cloner toute l'application dans plusieurs serveurs

Serveur1

Serveur2

Individuellement (plus d’instances pour les servicespopulaires)

Serveur3

Pas suffisamment flexible

28

Passage à l’échelle

Plus de flexibilité (Cloud-Native)

Kubernetes et les microservices

Une plateforme pour l'orchestration de microservices} Offre une API qui permet d’automatiser}

le déploiement
ü la mise à l'échelle
ü la gestion du cycle de vieü}
29

Nous avons appliqué l'inférence de patrons à l’API de Kubernetes

Microservices (stateless deployment pattern)

App = X
Deployment Controller

App = XD
Replicas: 2Server1
Service 1
Selector:
App: X
30

Server2

Disponibilité des microservices stateless avec
Kubernetes}

Aptitude aux systèmes hautement disponibles}}~5 minutes d'indisponibilité par année

Nous avons évalué le taux d'interruption des services pendant les pannes pour les patrons identifiés
OpenStack Cloud
Node 1Master
Deployment
controller
Replicas: 1

Kubernetes

app: X
DockerUbuntuOpenStack Cloud
Node 2
serviceselector:
app : X

Pod A

DockerUbuntu

No-Redundancy Redundancy Model
31

Deployment
controller
Replicas: 2

app: X
DockerUbuntuNode 1MasterDocker
UbuntuKubernetes

Pod A

Node 2
serviceselector:
app : X
Pod B

app: X

DockerUbuntuN-Way Active Redundancy Model

DockerUbuntuDisponibilité des microservices (expériences et mesures)
1 f/y….

interruption de service(secondes)

300.852 -Kubernetes (configuration par défaut) !

• f/y: Nombre d'interruptions de services autorisées par année pour les systèmes HA (hautement disponibles)
9 f/y

32.019 -Temps d'arrêt total autorisé (315,36 secondes)
…….

f/y =

1.766 -

temps moyen d'interruption de service

178 f/ypanne dans leconteneur d'application

panne dans leprocessus du pod

panne dans lenoeud

No-Redundancy Redundancy Model (1 pod)
f/y: (failures per year) Nombre d'interruptions de services autorisées par année pour les systèmes HA (hautement disponibles)32

Disponibilité des microservices (expériences et mesures)
1 f/y

….

interruption de service(secondes)

300.852 -

8 f/y

9 f/y

38.58232.019 --…….

La redondance est un mécanisme importantpour améliorer la disponibilité des services

0.730 1.766 0.579 -178 f/y544 f/y

432 f/ypanne dans leconteneur d'application

panne dans leprocessus du pod

panne dans lenoeud

No-Redundancy
Redundancy
Modelpod)
N-Way Active Redundancy
Model(2 (1pods)
f/y: (failures per year) Nombre d'interruptions de services autorisées par année pour les systèmes HA (hautement disponibles)33

Microservices (stateful deployment pattern)StatefulSetSS} Les clients recevant le service depuis app-0

connaîtront une interruption de service jusqu'à
ce que app-0 soit redémarrée et récupère ledernier état enregistré de PV1.

Name: app
Replicas: 2} Les instances de microservice ont des étatsdifférents¨ Non interchangeable

34

app-0

app-1

PV 1PV 2

Enrichir Kubernetes avec un contrôleur d'état} Un standby pour chaque pod actif} Répliquer l’état du pod actif dans le pod standby} Gérer les cas où le nombre de pods change}

Interruption de service}

Passage à l'echelle (Scaling Request)} Avec notre solution

Amélioration du taux d'interruption (40% - 98%)
} Brevet provisoire déposé}

35

Enrichir Kubernetes avec un contrôleur d'état
Application Service:
Selects pods with label:
HAState= Active

r/w
PV0

Activereplicatesapp-0r/w
PV2

Activeapp-2
36replicates

StatefulSet controller
Replicas=2 4

API Server

Scaling Request
State ControllerSCSS

Replication Service:
name: replicate-app-0

Replication Service:
name: replicate-app-2

Standby

w
PV1

app-1

Standby

w
app-3

PV3

ActiveStandby

app-0

app-1

app-2

app-3

Enrichir Kubernetes avec un contrôleur d'état
Application Service:
Selects pods with label:
HAState= Activer/w
PV0

Activereplicatesapp-0r/w
w
PV2

ActiveStandbyapp-2
37

replicates

StatefulSet controller
Replicas=4

API ServerState Controller
SCSS

Replication Service:
name: replicate-app-0

Replication Service:replicate-app-3
name: replicate-app-2

Standby

w
PV1

app-1

Standby
Activer/w
w
app-3

PV3

ActiveStandbyapp-0

app-1app-2

app-3

app-3

app-2

Travaux futures
Migration vers le Cloud-Native} Objectifs à long terme}

Supporter et automatiser (autant que possible ) la migration vers les applications etles architectures cloud-native} Objectifs à court terme :} Considérer d'autres modèles de redondance plus efficaces} Proposer une méthode pour la prédiction et la prévention des interruptions des services} Proposer une méthode pour extraire des microservices à partir de la décomposition desmonolithes} Proposer une méthode de test/ verification pour les systèmes migrés
38

Travaux futures
Défis d’utilisabilité des APIs} Patrons d’API pour d'autres écosystèmes (App mobiles)}Tenir compte des permissions d'utilisation d’APIs (aspects de sécurité)} Évolution des patrons}

Étudier comment les patrons d'utilisation évoluent dans le temps} Autres sources de données pour l’inférence de patrons d’API}

39

Historique de changement, Q&A site stackoverflow

Conclusion

Inférence de contraintes
d’utilisation desmethodes

Inférence de patrons d’utilisationd’une API

Inference de patrons d’utilisation deplusieurs librairies} Une vision holistique et pragmatique}

Tous les niveaux d'utilisabilité sont importants et complémentaires}

L'approche doit être pragmatique par rapport à la disponibilité des données

40Merci41