The story about how one hackathon project sped up the development of our back office system by 2 days per feature. The story about how we enabled our teams to develop in the newest technology-agnostic stack by extending the architecture of legacy monolith application. The story about how we enabled our teams to extend a monolith back office without touching it.
In AUTO1, as in the majority of other companies, we also have a back-office software (aka “Admin”) where our employers can manage our business operations. We’ve got a lot of business processes, and therefore a lot of business logic put into the code.
A couple of facts about Admin:
From these facts, you can see, that what the thing we’re talking about - it's a typical monolith.
An authentication between requests was handled with a very common approach for PHP applications - PHP Sessions. With this approach the session identifier for the current user is put in a cookie, and on the server side, the session data is somehow stored as a document.
Then we’ve got our first microservices. Some business logic started to live its own life. And of course, our Admin should have had some control over it. So our Admin started to interact with our microservices, and initially it was treated more or less as a third-party API.
Our microservices are located behind an API gateway (we call it GateKeeper), every authenticated request should be signed with an OAuth token to get through it. Also, every request should be signed by the client application with an API key.
Admin has become one of the external clients of microservices API. It had its own API key, every user was obtaining an OAuth token, which is kept in a session document, as a part of a session data.
Months were passing. In general, an architecture stayed the same, apart from the fact the number of our microservices increased. And increased a lot.
More and more business logic was covered by services while less and less logic was implemented in Admin. Then at some point were realized, that what happens in Admin - it’s just a proxying of requests to a gateway. The usual code for a new feature was more or less - send a request to the Gateway, get a request, send this request to a front-end client. Not the most exciting engineering work ever.
Moreover, we’ve got another complication - some teams without any PHP engineer had to add some new features to back-office. For this, one needed to create a proxying code, and for this one would need some support from another team.
So we’ve started to think of possibilities to send requests to the Gateway directly from Frontend, in order to avoid a necessity to make any implementation in Admin every time we do a new feature. And challenges were:
Then unexpectedly a group of our engineers (Mikhail, Oleg, Alexey and Andy - thank you, guys!) came out with a prototype of Vigolante, as a Hackathons project.
Vigolante - a mix of GO and VIGILANTE (sp.), which means a guard.
The idea behind it can fit in one sentence: it’s an authentication layer, which uses the same cookie as Admin, gets a session identifier from a frontend request, connects to the sessions storage (Memcached), fetches a session data, gets a OAuth token from the data and, enriches the initial request with the token and then forwards it to a Gateway.
Quite a simple flow, but once in place helped us to save a lot of development time in order to deliver new features to Admin. From now on, we don’t need to make any changes in Admin, when we need to send a request to a microservice from Frontend.
We have chosen Golang as an underlining technology to build the project. The reasons are:
Basically, the project was developed by the efforts of 4 engineers in a bit more than one day. We are proud to say, that this time was not just for coding but also for taking care of bringing the software to production; things as:
There were few things yet to be resolved (such an implementation of mechanisms of refreshing of OAuth tokens, also there were some problems with encryption of PHP sessions from Memcached), but those were successfully resolved; one month later we released the first feature relying on Vigolante to production.
Feeling proud and fulfilled, we could now focus our attention on the our engineering challenges.
Analysis of Spring 5.X candidate component index applicability to boost our application startup time
Yet another use case for using containers.