Some believe every technology start-up should incorporate messaging from day one.
The theory is that quick evolution of your software is paramount to survival. But, an open source software stack and toolkit is merely the starting point. What really matters is how well you use these tools to build apps that capture and serve customers.
This article’s Q&A session provides an inside look on how UK-based start-up, DrDoctor works with clients like the NHS and evolves their applications based on lean and agile practices designed into their architecture. With a focus on micro-services tied together by RabbitMQ messaging, one of their lead software engineers, Stephen Friend, shares an overview of their stack including a narrative on their lean development approach based on SOA, and the benefits they see.
While you may have read how Pivotal’s open source software solutions like RabbitMQ and Redis are used at start-ups like Instagram, Pinterest, Twitter, Hulu, and Soundcloud, DrDoctor uses a .NET stack with RabbitMQ, EasyNetQ, Topshelf, Castle Windsor, Magnum Library, Simple Data, and NancyFX.
Could you tell us a bit about DrDoctor as a business?
DrDoctor is a UK based start-up working to improve healthcare management for the benefit of patients and hospitals. DrDoctor provides online and SMS based transactional services for patients with functionality like appointment management, feedback, and results. These tools improve the experience for patients, and we significantly improve the efficiency of clinics. Of course, hospitals can also achieve a substantial ROI.
What initiated the focus on messaging as a central part of the architecture?
From the very start we believed that DrDoctor should be built using asynchronous messaging. One of the main reasons is because it’s such a natural fit for our problem domain. For instance, a typical scenario might be: a) we remind you that you have an appointment in five days’ time, b) two days later something comes up and you need to re-arrange it, so you send us an SMS, c) the DrDoctor brain e-mails the booking team so that a human is aware of the change, d) we send you an SMS confirming the change, and e) five days before your new appointment, we send you an SMS reminder.
What other reasons were there for a messaging-centric approach?
We also believe that asynchronous messaging is a great way for a lean start-up to build software that can be easily changed. We know we are going to need to add additional functionality or tweak existing logic as we discover more about our business. So, we create small, well defined services (or micro-services) that are connected together using RabbitMQ. When, not if, we need to change the way a service works, we can do so easily without bringing our whole system down. We can also add new services as necessary. For example, we added a dashboard application for monitoring our business KPIs that did not interfere with other existing services. This also enables us to retire old services just as easily.
Could you give us a bird’s eye view of the architecture and how messaging fits?
As mentioned, we have a services oriented architecture (SOA) built on asynchronous messaging. This isn’t because it looks good on our CVs—it probably doesn’t any more because there are new buzzwords now. Instead, the approach allows us to truly be agile. For example, when our clients asked us to quickly build a product to respond to a new government initiative asking patients the ‘Friends and Family Test’ question, we were able to extend our current system, adding in new the functionality quickly and easily. With the change, we also had zero downtime. As well, our development team is able to focus on the business question of what adds value. For example, our customers put a high priority on the quality and ease of reporting. So, we refined our ideas on the reporting service and deployed new functionality. Again, we created a new service alongside our application without disruption to our existing services.
How did you decide on RabbitMQ?
There are three key reasons.
Closely aligned to our belief in easier changes to software is a desire to use the right tool for the job. We do not like to re-invent the wheel. While our in-house development is done in C# on the .NET framework, we will happily consider any tool that helps us get the job done quicker and better. This is why our stack includes a number of open-source projects from both the .NET world and elsewhere.
When originally scoping the project, we looked for the right balance of ease-of-use versus complexity in our messaging infrastructure, and RabbitMQ came out on top. Based on previous experience, we knew MSMQ doesn’t come with as much ‘out of the box’ as RabbitMQ, even though it might seem like a natural fit for Windows-based development. At the other end of the scale, fully-featured ESBs like Mule ESB, bring a lot of complexity. This means a steeper learning curve without any benefit to our core systems.
Our clients who range from NHS Trusts, hospitals, and general practitioners, have stringent requirements about privacy and data protection. They require our software and data to be secure and hosted in the NHS’s N3 network. The security requirements prevent us from using a cloud-based provider like Amazon or Azure. Also, while performance is important to us, it is not our primary concern. The speed of light is never going to be a limiting factor for our business like it is for some global high frequency trading platforms. Resilience and data durability, on the other hand, is extremely important to us. We need more than in-memory queuing, and our team will sleep soundly at night knowing our messages are safe until they’ve been delivered. Again, Rabbit fits the bill.
What benefits have you experienced with RabbitMQ?
In terms of day-to-day use, RabbitMQ has been a real pleasure to work with. The EasyNetQ library from Mike Hadlow also really helped us out. EasyNetQ has meant that we can keep our C# hats on as we’re developing new features and not worry about how our services are going to interact with the underlying messaging infrastructure. In the typically resource constrained environment of a startup, it’s vital to start quickly and focus on writing core code.
Similarly, the installation on developer machines and servers was a breeze. We were able to get a working spike running in two days. Then, the spike was turned into a paid product very quickly and has been running ever since. In the background, we’ve made tweaks and changes. Of course, RabbitMQ continued to do exactly what it says on the tin—so far it has been “messaging that just works.”
Ultimately RabbitMQ was the right choice for us because it means we can iterate on our software quickly, and it bakes in resilience and durability. We are confident that it can grow as we do.
As our business grows we’ll be kicking the tyres some more. While we don’t know what the future holds (apart from change), it seems likely that we’ll need to scale different parts of our systems in different ways and integrate with different services. With RabbitMQ at the backbone, this actually sounds exciting rather than scary.
Learn more:
- .NET Case Study: Scaling .NET and RabbitMQ to 100s of Millions of Passenger Messages
- More RabbitMQ Case Studies: Lucid Logistics, Norwegian Broadcasting Corporation, Roblox, Instagram, and Soundcloud as well as for a 1.2 billion person biometric identity application and ocean data observatories.
- About RabbitMQ 3.2.0 and Federated Queues
- How micro-services architectures fit with Spring and Java
- Using RabbitMQ with JMS
- The Polyglot Rabbit, an expert interview on using RabbitMQ with HTTP, MQTT, STOMP, AMQP, OpenVMS, Python, Ruby on Rails, cURL, and more.
- RabbitMQ’s Clients and Developer Tools, including a tool for Hadoop
