When we decided to change our name from Spacious to Hubble we saw it as an opportunity to do more than just change the logo in the top left of the navbar! We’d been meaning to do a redesign for a while. Plus we had some architectural changes we wanted to make; in particular switching from our monolithic Django system to a Microservices approach. These had previously been on the back burner but this was the perfect excuse to fast track the and get them done.
I’m not going to go into much depth about what is Microservices, but rather why we wanted to roll it. Firstly, it is not because it is trendy, hipster, the new buzz word or whatever; often in tech there is a knee jerk negative reaction to movements like this. In our situation though, it felt like the right thing to do. Plus, people rarely talk about the benefits of new architectures and languages from a non technical perspective.
So why is it for us?
Obvious Individual Components
We have a multitude of parts that each could easily be self contained as their own service. For example: Messaging, Search, Authentication, etc. These all have different requirements and focuses and therefore lend themselves better to different languages. Also, looking at our roadmap, we have lots of sprints and projects coming up that could be implemented in their own silos. By splitting these into services this allows us to quickly test and iterate without worrying about the rest of our product. Whereas in a monolithic system these services are bundled together and can create a spaghetti mess of workarounds and packages.
Faster Development and Scaling
Having been a dev team of 1 for a long time I’d never experienced the headache of installing all the dependencies required by our Django system. It never really occurred to me that as I installed more packages, it was becoming incrementally larger and more complicated for new team members. Because of this, the monolithic Django system was already proving a headache to get quickly set up, running and understood by our new hires. Splitting it up into more digestible chunks (services) therefore should allow us to scale the team a lot quicker this year and beyond.
At this point you can probably tell that speed of development is a huge factor for us at Hubble; if we were optimising for anything it would be that. We don’t worry too much about code quality as I believe that that is fixed at the recruitment level. Good people write good code and, more importantly, ship good products.
Recruiting
This leads me onto the final benefit, recruiting. I mentioned earlier about the non technical benefits and this is the main one. Finding devs is hard and finding good devs is even harder. A microservices architecture is (fairly) new and it doesn’t tie you to a particular language. If you want to build a service in Lisp, Go, Elixir, etc then you can (assuming it makes sense). Good devs love to learn, experiment and hate being bored. A microservices approach encourages all of that. Also, this natural workflow of creativity and experimentation will hopefully later reveal more benefits down the line in the quality of work that is produced at Hubble.
Of course, this architecture isn’t without its cons. APIs must be well designed, maintained and documented, and having a lot of moving parts isn’t without its complexity. However, most of the cons are part and parcel with programming. You’re going to get versions of these problems whatever route you go down. I admit, at this point in time I’m probably wearing some rose tinted spectacles. But this decision was not taken lightly and should never be. It is a fundamental shift in architecture and major technical decision for our company.
Once we came to this decision, we had to figure out how we were going to do it. Especially how are we going to do this in 4 weeks?! In the next post I’ll explain how we setup our architecture, our plan going forward and how to do all this while still staying lean!
And of course, a little plug… if you’re looking for some great London office space then make sure you have a browse on our website.
