Real-World Redis Tips

Redis might sound like it’s just a key/value store, but its versatility makes it a valuable Swiss Army knife for your application. Caching, queueing, geolocation, and more: Redis does it all. We’ve built (and helped our customers build) a lot of apps around Redis over the years, so we wanted to share a few tips that will ensure you get the most out of Redis, whether you’re running it on your own box or using the Heroku Redis add-on.

Read more →

How Combatant Gentlemen Solved Service Discovery Using Heroku Private Spaces

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.

Read more →

Powering the Heroku Platform API: A Distributed Systems Approach Using Streams and Apache Kafka

We recently launched Apache Kafka on Heroku into beta. Just like we do with Heroku Postgres, our internal engineering teams have been using our Kafka service to power a number of our internal systems.

The Big Idea

The Heroku platform comprises a large number of independent services. Traditionally we’ve used HTTP calls to communicate between these services. While this approach is simple to implement and easy to reason about, it has a number of drawbacks. Synchronous calls mean that the top-level request time will be gated by the slowest backend component. Also, internal API calls create tight point-to-point couplings between services that can become very brittle over time.

Read more →

Neither self nor this: Receivers in Go

Andrey Petrov is the author of urllib3, the creator of Briefmetrics and ssh-chat, and a former Googler and Y Combinator alum. He’s back again to free us of our old ways of thinking, so that we can embrace what's really special about receivers in Go.

When getting started with Go, there is a strong temptation to bring baggage from your previous language. It’s a heuristic which is usually helpful, but sometimes counter-productive and inevitably results in regret.

Read more →

How Emarsys Approaches Service Sizing on Heroku

Based in Budapest, Hungary, Andras Fincza (Head of Engineering) and Rafael Ördög (Technical Lead) work for Emarsys, a global marketing automation platform. Read our Emarsys customer story to learn more about their migration experience on Heroku.

How did you introduce microservices at Emarsys?

We take an evolutionary approach to our architecture. Our marketing automation platform was originally designed as a monolithic system built in PHP and MySQL and running on in-house infrastructure. We were running two major services on our in-house infrastructure: one for HDS (historical data service) and the other for smart insights and analysis. However, it was hard to grow the platform effectively because it required heavy support from our system engineering resources. Our system engineers were regularly inundated with requests, and it took a while to make any changes.

In late 2014, we started experimenting with a service-oriented architecture to ease the burden on system engineering and allow us to experiment with new technologies. We wanted the ability to deploy and scale some features independently. We also wanted to try different languages and data stores without adding an extra burden on our system engineering team.

Read more →

Browse the blog archives, subscribe to the full-text feed, or visit the engineering blog.