Scott Raio is Co-Founder and CTO of Combatant Gentlemen, a design-to-delivery menswear e-commerce brand. Read our Combatant Gentlemen customer story to learn more about how Heroku helped them build a successful online business.
What microservices are you running in Heroku Private Spaces?
We’ve written an individual service for every business use case. For example, we have services for order processing, product catalog, account management, authentication, swatch display, POs, logistics, payments, etc.
With all these different services, we chose Heroku Private Spaces as a way to make service discovery easier. We’re currently running about 25 services, which is a relatively small number compared to Netflix or Twitter (who employ hundreds of services). But we’re growing, and we’re always evaluating our services to determine which ones are too large and need to be broken out.
Most of our services work autonomously and share nothing between them. When the services are isolated and containerized, then changes are much simpler. It’s a very clean approach.
What languages did you use to write your microservices?
Most of our services are written in Ruby, due to the language’s development speed and flexibility. We leverage Grape, a Ruby framework for creating REST-like APIs.
We use Go for some services due to its raw speed. For example, our API gateway is written in Go. It consumes all the host and service information, and does various things such as circuit breaking, fail over, and error management. We’re really excited about that and just deployed it in Heroku Private Spaces.
The client-facing service that backs our UIs is written in Node.js and powers our Backbone and Marionette front-end apps. We use MongoDB for all our database needs.
How do you handle service discovery?
We needed a microservices “chassis” – something that could create a platform for us to rapidly deploy services without having to worry too much about the inner workings of those services. We found many piecemeal technologies that could address different parts of the solution we needed, but nothing that could glue them all together. So we built our own framework that we call “Vine” (relating to “Grape”) that connects all the services together and helps us maintain shared code between each service. The shared code aspect is more about the developer experience than service functionality. The framework’s plug-in architecture lets us write new core functionality that is modular. Anytime we need to add functionality to a group of services, we can write code once and share it everywhere. For example, this allows us to manage service configuration of our Fastly CDN really easily.
How did you decide to create your own framework to manage your microservices?
There was nothing in the Ruby world that worked for us. We’re not dealing with large amounts of data, but we’re dealing with a very broad and rich dataset with many different constituents touching that data. Also, our industry is greatly influenced by changing conditions in local markets and with global suppliers. We needed the ability to respond quickly with new features or updates.
In a sense, we modeled our framework after our experience with Heroku. We didn’t want our engineers worrying about inter-service discovery and service communication. Instead, we wanted them to focus on building features and launching product. This was why we switched to Heroku a year and a half ago, and it’s the same reason we built our Vine framework.
We’re really excited about Heroku’s upcoming DNS service discovery feature that’s coming out soon. It will help us stabilize a lot of aspects of our system and we plan to integrate it into our existing architecture.
How do you handle inter-service communication?
We use RabbitMQ for asynchronous message passing and HTTP with MessagePack or ZeroMQ for our synchronous communication.
We’ve explored ideas around using Kafka, but we’ve invested a lot of time in RabbitMQ so we’ll continue using that for the time being. We’ve been able to deploy really fast serialization between services, which is something we could only do in Heroku Private Spaces. Because it’s an isolated environment, we can talk to services directly rather than having to go to the internet.
What has been your experience working with Heroku Private Spaces?
We’ve worked really closely with Heroku Support and the Private Spaces team on getting our service discovery working smoothly. Heroku Private Spaces has given us all the benefits of the Heroku platform combined with the architectural flexibility we needed to simplify private dyno communication and service discovery. Because we don’t have to go over the internet, things are inherently secure and can be optimized without authentication later.
Our next step is to get down and dirty with our data layer, connecting our Private Space to an Amazon VPN. This will allow us to connect our database to the same private network as our Private Space.
Any advice to others looking to take a microservices approach?
To me, the world of microservices is like the Wild West right now. There are so many opinions, directions, and projects out there, creating a lot of noise in this area. To figure out the right microservice approach for your project, you just have to dive in and go through it yourself. You have to experience the bad with the good in order to come up with a strong opinion about which way to go for your project or company.