HAPI Project
Hapi is the name given to an API that my team and I have created to provide the catalog of services of our team available in Self Service to our client.
​
- 5% of installations via Wabot (cf Achievements).
- 95% of installations via Puppet recipes developed by our teams concentrated in a service called PPAAS (Puppet As A Service) provided by Unix teams.
Above PPAAS service (which contains all the puppet recipes developed by the infra teams), is placed ITAAS service (IT as a service) which is no more than an overlay API which calls recipes PPAAS managing more authentication and permissions.
So we are in 2017 and the teams are starting to communicate with each other to provide the best overall service.
​
So we have cloud teams that can deliver virtual machines in hours by automatically managing quotas and decommissions.
​
Itaas also allows the customer to play our recipes of installations in order to stock up new environments in a few minutes.
​
The HAPI project was born from a discussion we had with a colleague about the level of automation that we could bring in addition to what already existed.
We already had beautiful things but we could always do better!
So we thought about what we could do already and what we could not do yet.
What we could do already:
- install all the middlewares that we managed via automated puppet recipes
- Automatically monitor these new installations.
​
The constraint:
All the Puppet code we provided was stored in a version control tool (GIT) and submitted for validation by a Git moderator.
As this tool is common to all SGCIB teams, it took a long and tedious time to propose any modification of an existing recipe or even to create a new one.
​
​
What we could not do yet but would interest us:
- integrate automated flows based on a tool other than Puppet (ideally create an abstraction layer allowing to use playbooks ansible, Powershell scripts ...)
- launch automated actions other than Middleware installations.
- have flexibility and responsiveness in developing new recipes.
The idea came to us to start creating an API.
​
The Project
​
We began to document each other on our own and we agreed that:
- We are not developers.
- We needed a common working method that was efficient enough to see significant progress quickly enough.
- We wanted to make an API in the form of Micro Services.
- We wanted at least to allow to deliver via the API the PPAAS recipes (Apache / Tomcat / IIS installation).
So I discovered what was the AGILE method and DevOps.
As a startup, we have created a Story Mapping to better plan the future of HAPI.
We also started the daily team points as well as Sprints.
A thorny technical problem was to be solved: We were not developers but we needed fast results.
We turned to the new tools available on the Web and found Swagger that we used as a code generator.
The principle is simple: you provide it with an API described in YAML and it transforms it into a large choice of languages ​​allowing you not to have to code your code structure.
Python Flask seemed like a good language choice to start and so we started coding the features of our API.
I started by coding the Apache installation feature as well as IIS (based on already existing Puppet recipes).
Context
​
We are in February 2017 and the deliveries of Middleware platforms are distributed as follows:
I was able to discover all the new tools that are part of those of the image above and to interconnect them to make a coherent, functional and efficient whole was a big challenge that was raised.
​
With the API as such, the interest of the project is the entire process of CI / CD that we put in place around the application.
Indeed, based on the Git and the Jenkins Pipeline, the Deployment Pipeline that I participated in creating allowed us to deliver:
- In a very regular way
- In an automated way
- Securely (thanks to unit tests).
I had to think in OPS either as I usually do but as a real DevOps.
This is another aspect that I really liked about this project: The fact of being in the shoes of our customers and living their constraints.
This helps us to better understand their problems and improve the quality of my service.
​
These were our first big hits for HAPI but we were not able to provide services other than those that already existed.
So we thought about what the customer might need on a daily basis but was forced to ask us for lack of rights.
So, in order to create this layer of technological abstraction, we integrated a Jenkins (orchestrator) within our API in order to execute Jobs in a totally agnostic way (Ansible / Powershell ...)
Nowday and thanks to the association of all these technologies, we are able to:
- Restart, start, stop, know the status of our middlewares
- Deploy applications
- Install certificates
- Deploy SSH keys
...and the possibilities are endless.
For me, the difficulties were many because the API is composed of many tools that I did not know.
So I had to train on it, test and failures as well as exchanges with my colleagues allowed to move forward and grow together.
I have also learned a lot from the world of developers from both a technical and a methodological point of view.
For example: I learned to code by integrating my unit tests at the same time as my code.
Future
​
For the future, we've passed HAPI in production so we'll continue to deliver new features to satisfy the client and free us time to create more.