As a result, we implemented a Golang application, that did exactly the same, as it's predecessor-monolith, but outside of php environment. The current page lifecycle started to look like this:
\nThis is pretty good, huh? Of course, there are challenges in current approach also. We are investigating the best way to deal with user locales in SPA index, we learn how to do proper caching and authenticating user, but this is a topic of another story! The AUTO1 story started in 2012. In these six years company grew a lot. From one website\nwritten in PHP it evolved into a huge and complex system consisting of large number of components.\nThis article describes the evolution of AUTO1’s architecture from a monolithic approach to Microservices. The brand independent automotive company owns business units like auto1.com, wirkaufendeinauto.de and autohero.com. At the beginning we build several classic monolith applications that served different parts of business. The first phase was a great beginning of our journey to the world of microservices.\nWe got amazing results and most of our problems were solved: Unfortunately there is no silver bullet. The microservice approach approach has its drawbacks and we faced some of them. To resolve last of this problems we introduced the SPA approach.\nWe started using React. It allowed us to call microservices directly from the frontend with proxying requests through our monolith applications.\nTo be able to do so, we introduced simple proxy layers just for communicating with services.\nMore about this approach you can read in our blog article. As a result our architecture took it’s next look: For the last six years we passed a long way from old fashioned php websites to huge distributed net of microservices.\nHere are some numbers at the end of 2018: Microservices brought us lots of advantages, but along with advantages new challenges had come. 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.\nAnd 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.AUTO1 Group
\n#spa #monolith #mvc #engineering
","fields":{"slug":"/spa-evolution/","tags":["auto1","SPA","monolith","MVC"]}}},{"node":{"id":"3e19b9f8-fd63-5270-9ae1-29f538ecd8a9","frontmatter":{"category":"Architecture","title":"Migration to Microservice architecture","date":"2019-02-12","summary":null,"thumbnail":null,"authorName":"Alexander Egurtsov","authorDescription":"Team Lead Software Engineer","authorAvatar":{"relativePath":"pages/migration-to-microservices/avatar-big.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAIAAAAC64paAAAACXBIWXMAAAsSAAALEgHS3X78AAAD5UlEQVQ4y0WSy28bVRTG5z9gi8SSv4AFCySEkNggFqgVi4K6QSoqqgQBsUkfIJUFFKqKJiWgWrRNG/pQHk3TlpTUcgKOg+14HHvssed5Pe/XnRm/YztjxzFnbBWOPl2dxfzO9917htA0S9dtQ3f+k65ZluU7uK7IWkWQTBM7TlXgJY5F5RJfKDD5HE1m8qkkSZiOZzm+hUHV8LQ9168jXlyY+WH+4tQXH7534vj7d+YXTMMVBRlGsIxYojmKorPZPIH9uuc3vCoImppfbRimPXvus1PvvDb9wdvTx996/ZWX3nj15cjcHMY1JMowYhyBKxRKRL3RAjWaoWq1xn6vn46tXznz0fz5zzfnvkMbi2b8qfB4/upXn0gVRVMtSdKQqEx4otXutPe7EzWa7f5wtBSZvXz6RCcTG/n6UbcBGtnC+k8X6AKFsa8quiLrCMk8LxKd7kG3F4Cgabc7o9Fo5f69T999k7xxZe9+xE/H9M01Zimy/OM5UUSuWzUMS9NMWVYRkoiDoB+MBU2vd3A0GlHxv2bOnNyavRj/5bK+dtuOrVH3fmXXH/iuj13ftrFp2ppmSJJKDF5UfzAIgmAwHDZ8/9rUKeX54kgtC4uRQNgbOaKWitWabXhRx4WNYPBXVZ04HA5DjWswOAyCA0hOJuKPLk17WytPvvmysnyzvvPY5grwmNXxRhzsWZaj6yZxdHQ0fFFjfgCz9tutmbNTOz9/Ld262tp8yD6K2KbR7vRq9aZfrbte1XZc2GgIT2rCAwy971W/nzr97cfHCkvXiyvXEw9/b3WCVnsf1gH8xNy0nP/hCQ/mEDubE54sbVy7MH3+5LHlS2ejt39TVSvo90O40QJzDOY2JuDTMRbC0ENm264lU2w0RidTQvmf5IGQTSw/2N1lm63JH9Gp1RuT5CE8KQhcrbVRxS6VVIY1sntoJ8mld1GqKN64u55O8WQW7eUqsuwADMlDeGLYaHZ4wSozRqms84LJ8SYnWILosIzxLEaRlMpxVp5SMiRK7LCCaAIP1w6d9zu97SSbKyglziyxBsdbQkjaAKMKpouKJLmi6Aq8AyOSST6dEVyvht0xnKXE1ae7ZF6iGb3I6GXOgBQiAtiuVFyIA+Nk2asgzLEWhP97u1yRTNfzicHh4eofqWfR/F5BylKVXEGmWa1YViG5IITmJcZACMMUUQzPYlHbTjAcb4Rwt9tbXN2OxWmAU6QQ3cwXSwrNaCVGZTiD5U2Wt3mIIHkiwuWywbJWYocrFhUHu4Ru4JsLzzfjdCaHolvUn9HsnbsbaZILR7AaAzBnwuOLyAH/3YyYyYhbW0WSRJaF/wUqjPNz+4prxwAAAABJRU5ErkJggg==","width":50,"height":50,"src":"/static/63581729799e31fcd1a0b0f4271c9cad/45876/avatar-big.png","srcSet":"/static/63581729799e31fcd1a0b0f4271c9cad/45876/avatar-big.png 1x,\n/static/63581729799e31fcd1a0b0f4271c9cad/eb85b/avatar-big.png 1.5x,\n/static/63581729799e31fcd1a0b0f4271c9cad/4f71c/avatar-big.png 2x,\n/static/63581729799e31fcd1a0b0f4271c9cad/9ec3e/avatar-big.png 3x"}}},"headerImage":null},"html":"Original AUTO1 architecture
\n\n
\n\n
\nResults
\n\n
\nOnce upon a time, there was a startup which was built as a monolith...
\n\n
\nThe moment any monolith is afraid of
\nThere should be a better way
\n\n
\n\n
\n\n
\n