In the process of rebranding we decided to switch our architecture from a Django monolith to microservices. We had 4 weeks to redesign, rebrand and rebuild our entire site and so needed to figure out how to do all of this the lean way. We carefully split our architecture decisions into thin vertical slices that could be implemented over time. In this post I’ll talk about the main challenges we focused on, how they were implemented and how we built a microservice architecture while still staying lean.
Before I go into depth about the process, here is a quick diagram of our architecture:
To get there, we split the process into 3 main tasks:
1. API Layer
The API layer acts as a gateway and is the entry point to our architecture. It is pretty dumb and, for now, only does 2 things:
- Route requests to services
- Authenticate users (not authorise)
**there are some great libraries to easily set this up. For example, we use https://github.com/auth0/node-jsonwebtoken*
2. Decoupled Frontend
Building the API layer was the first step in decoupling the frontend. The next was to move out of Django, which was currently serving our templates, to a self contained frontend which consumes the API. To do this we chose Angular.js. There are currently a lot of mixed emotions in the tech community when it comes to frontend JS frameworks, be it which one to choose or downright hatred of them all. We didn’t want to again be locked down in an all-encompassing framework, such as Django, which would defeat the point of changing the architecture in the first place. Saying that, lock-in was one of our biggest worries with Angular, as it has a particular way of doing things that ties you into its way of development. At the end of the day though there are very few frameworks that don’t lock you in to a certain extent.
Frontend JS frameworks represent the direction that the web is heading, providing a lighter more seamless experience. Until there are improvements with Web Components, Angular represents one of the best of the bunch. Backed by Google, it has a growing community, ongoing development and support and I suspect it is going to be around for the long haul. Even if it is not, or even if we find a fundamental flaw with its implementation, having decoupled the frontend it allows us to easily re-write without affecting the rest of our system. This separation also forced us to ‘dog food’ our API which is going to be used by third party integrations (such as the 3 Beards), instilling best practices, such as versioning and proper RESTful design, from the get go.
3. Exposed Monolith
Finally, how do we deal with our monolith? We decided to treat it as if it was a (very large) microservice. We exposed our endpoints using the Django Rest Framework and registered it and its auth token with the API layer. Most of our logic had been abstracted out of views and into model methods which limited the amount we had to rewrite, although despite that there is still a lot to refactor…
After all this, there is still lots to do. We’ve not implemented any caching, our API documentation is terrible and test coverage is sparse: at first it was a surprise when anything worked! But these are all things that can be fixed gradually over time. Often when you read online about the Netflix or Instagram architectures, the steps they took to get there get lost. What I wanted to share is those early steps on that journey and that you can architect a stripped down microservices system using Heroku, cloud hosted systems and no devops. As with all things, moving to a microservices architecture will not solve all your problems and it has to be done well. It has different challenges to a monolith and, being fairly new, these challenges tend to be less documented. We’ll see in time how our architecture evolves at Hubble. The beauty and curse of a marketplace is that there are so many moving pieces that I’m sure it is going it’ll be a hell of a lot different in 6 months time.
And don’t forget if you are looking for some awesome London office space you can check our website.