As microservices continues to spread through the industry as a dominant pattern for building modern cloud applications, marquee examples from large-scale companies such as Netflix and Twitter may appear daunting to companies still on a growth path. When powering through agile cycles to release new features at a rapid pace, the last thing on your mind is maintainability. Well, maybe not the last thing, but it is a lesser concern.
It’s rare to have the foresight to recognize future bottlenecks early on, so when we came across a series of blog posts by Tom Watson, the CTO and Co-founder of Hubble who did just that, we took notice and had a quick chat to discuss his experiences. As it turns out, taking a moment to reflect on how things scale as they grow actually put them in a position to release features quicker and more effectively by injecting a lean methodology of focused microservices development patterns and operations.
Hubble is an online marketplace for London office space that began in January of 2014. Coming out of Entrepreneur First, a European accelerator program that brings like-minded people together, the founders Tom and Tushar Agarwal met to form a company to solve the many challenges of searching and finding the right space to work. (If London is anything like San Francisco, then we can most certainly sympathize!) The premise of Hubble is to connect hosts who have spare space with tenants who need it. These hosts range from people who have a spare desk to startups who may have five desks available in their office. Once the connection is made, the platform facilitates an open dialog between the hosts and the tenants to serve each other’s needs.
Ditching the Monolith
As a small team going through the rigors of an accelerator program, priority #1 was to get up and running as quickly as possible, so they picked Django as the framework for the MVP. Full stack frameworks such as Django and Ruby on Rails are a great way to quickly prototype and build core functionality, but can quickly become bloated with dependencies. This makes onboarding new developers a challenge to ensure all the right packages are in place across the whole development lifecycle, and it slows down deployment as a single entity for tests and builds. Speed is important to a startup, so after gaining some traction early on, Tom recognized the bottlenecks with their monolithic application and looked for a better architecture pattern that would give them greater development speed and effective scalability as they grew.
Getting Distributed and Going Micro
Moving from the monolithic application pattern to microservices seems like a monumental undertaking on the surface as it’s a completely different approach to structure, however it doesn’t have to be an all-in switch. One of the key benefits of the pattern is the ability to tackle piece by piece without losing the work that had already been done. This is how Hubble approached the process after reading up on the subject and talking with other startups who were already further along in their own lightweight service-based approach.
Through analyzing the core feature set, they were able to identify candidates that each fit the single responsibility principle. This is in line with the microservices pattern of separating components based on their business objective. The first obvious feature to split out was billing; all the direct processing and payment info objects. The next feature was messaging; how messages get sent between users and link up as threads. Once going through the process a few times, it became second nature, and piece by piece the application became less monolithic and more streamlined via microservices.
“Over time we plan to keep doing that sensibly so that we’re spending more time building features and less time worrying about infrastructure.”
– Tom Watson, CTO, Hubble
The API Gateway
When moving towards a microservices architecture, one consideration is ensuring requests are delivered to the proper service. A common approach, which Hubble adopted using Node.js and Express, is to have an API Gateway that handles routing and authentication. This lightweight layer accepts requests from the clients and routes to the individual microservice. Each service is considered to be in a trusted network, and is accessed through a private token, with authorization handled at the component level to avoid any duplication.
Queue all the Things
As Hubble split out more and more components, one thing became very clear – they needed a message queue to communicate between services in a reliable manner as opposed to direct execution. After first looking into RabbitMQ and Redis, they found IronMQ, which better served their needs.
“I wanted something that was hosted and easy to use, because I was trying to stay as lean as possible. I didn’t really want to have that overhead of DevOps. With IronMQ, not only did it do what I wanted, it also took a lot of the hassle away,” said Watson. “The message queue is such a critical piece of an architecture, but it’s one of those that you just don’t want to maintain.”
Once Hubble spent some time working with IronMQ, they came to a realization that much of the work they had split into microservices was better suited to run asynchronously. Each service is stateless with only the required dependencies for the task, making IronWorker a logical extension as it not only provided a streamlined environment for developing and deploying the individual microservice functionality, but it also provided for more effective scalability. If the community picks up and more people interact through messaging, those workers can scale up and down on-demand without affecting the rest of the application.
“Because you’re dealing with stateless microservices,” said Watson, “one could even foresee a time where you just did all of your logic in IronWorker.”
The Microservices Future
As an early adopter of modern cloud patterns and technologies such as microservices and Iron.io, Hubble has formed a lean organization that can rapidly deploy new features at a fraction of the time and cost as they would have if they kept down the monolithic path. A new architecture comes with a new set of considerations, of course, but the benefits are clear. “There’s still a lot of figuring out to do with the future of application development, but what’s been cool about it is how the community’s evolved and how people have really figured out some interesting ways to solve complex problems,” said Watson. “Things like Iron.io that weren’t around when Netflix started out are going to make people think about microservices in a completely different way.”
Tom Watson is CTO and Co-Founder at Hubble. He studied Computer Science and while at University, after a short stint at IBM, he realized that building a startup was what he really wanted to do straight after graduating. Since then he co-founded Hubble and has sought to make the tech behind it as cutting-edge as possible. You can read his original blogs on microservices here.
Hubble helps startups and small companies find their perfect home. They are an online marketplace for office space, matching those looking to rent space with co-working spaces, serviced offices and people who just have a few spare desks. Currently the platform is only available in London (UK) but they hope to expand that in the coming months.
How to Get Started Today
To give Iron.io a try, sign up for a free IronWorker or IronMQ account today.
As a reward for signing up, we’ll even extend to you a 30-day trial of advanced features so that you can see how moving to the cloud will change the way you think about application development.