Microservices Stories

We’ve collected the stories of how companies have implemented microservices at scale. Posts can be filtered according to the different challenges of adopting microservices, and different company sizes. If you have a post you’d like added, please email austin@datawire.io.

Read More


Reasons to Read


  • Hubspot teams are cross-functional and full-stack (with no separate QA org), and will each take full ownership of a handful of services.
  • There are over 1,000 separately deployable microservices that can be scaled independently.
  • Most services are written in Java using the Dropwizard framework, and the front-end largely uses Backbone and React in CoffeeScript

How iHeartRadio moved their monolithic Java Backend over to a series of Akka apps and use Akka cluster to weave them into a microservice architecture and an explanation of the business outcomes that were the impetus for the change.

Read More


Reasons to Read


  • iHeartRadio’s major goals centered around reducing the dependencies of small deployments on one another in terms of testing so that deployments could happen faster and more independently.
  • By decoupling services, iHeartRadio expected to make it simpler to inspect changes and understand the implications of various changes.
  • A big priority for iHeartRadio was using Akka’s existing clustering infrastructure rather than building their own.

Amazon began refactoring their application from monolith to microservices, and part of their efforts became an early prototype for cloud computing as we know it.

Read More


Reasons to Read


  • The Software Development Lifecycle is the fabric of the development team, and Amazon found that the lifecycle as structured around a monolith kept developers separated from one another and less productive.
    The process of automating their deployment pipeline led to an early version of what they offer customers today.
    To increase the rate at which the monolith would be decoupled, Amazon instituted a rule that functions could only communicate with the outside world via their own web service APIs.

Gilt has an advanced and extensive microservices architecture that spans dozens of teams and hundreds of services. This post covers how Gilt modified their company structure according to their microservices architecture.

Read More


Reasons to Read


  • Rather than having a large “architecture” team, Gilt added architects to each smaller, cross-functional team.
  • Microservices increased the velocity of major feature releases, and eliminated nearly all risk of things breaking.
  • How they organize the teams that make corporate decisions about Gilt’s architecture and drive the efforts of all their engineering teams.

"…everything is fun and games until someone has to touch the monolith.” Phil Calçado describes Soundcloud’s journey from Monolith to Microservices to shrink the time from idea to deployment from 66 days to 16.

Read More


Reasons to Read


  • How Soundcloud created a Value Stream Map in order to see the *actual* steps it took to go from feature idea to live code.
  • Dev team reorganization increased connections and productivity between the Web and the App teams.
  • Questions Soundcloud addressed to shave an additional 8 days off their deployment time that may be useful to your organization.

Yelp’s explanation about how switching to microservices architecture allowed their 300 person engineering team to ship features faster across their multi-million line app of (mostly) Python code.

Read More


Reasons to Read


  • Yelp holds weekly education sessions for their engineers so that they know well how the company’s architecture works.
  • For tests that span multiple services, Yelp spins up private test instances inside Docker containers that can be pulled as dependencies for acceptance testing.
  • For service discovery, Yelp uses HAProxy and Zookeeper to maximize reliability.

Safari provides an online way to consume educational content via browser and mobile. This post details technical choices they made while refactoring their search feature from a component within a monolithic Django project into a microservice, specifically exploring efforts to break dependence on a shared database, use central authentication and plan for redundancy.

Read More


Reasons to Read


  • Safari selected their search feature to decouple into a microservices because it was one of the slowest services to deploy code to, and they wanted to speed this process up with microservices architecture.
  • The challenges Safari encountered emphasize the need for a standard microservices architecture and framework in order to avoid the costs of rolling your own from scratch after following the “monolith first” approach.
  • The initial estimates around moving to get an initial microservice added to the monolith were 4-6 weeks. After taking 8 months to complete, Safari realized the importance of having a solid microservice framework and set of tools to shorten development time.

Hailo is a taxi-hailing and scheduling app available in a number of cities globally. This 3-part blog series details how they broke their monolith down into microservices and solved a number of challenges around balancing customer data availability and latency in the app.

Read More


Reasons to Read


  • To date, Hailo has 160 services deployed across 3 continents, each with 3 availability zones. This increases scalability, but increases the complexity of the system.
  • Microservices allowed Hailo to switch from PHP to Go, which had the side benefit of helping them recruit from a large pool of Go developers in London.
  • Hailo used tools similar to Netflix’s Simian Army to test the app under load with failing components and degradation to make sure it could handle volatility.

Livefyre powers real-time commenting and curated social media across global media sites, and their platform had to be scalable to over 100,000 active users per JVM. This presentation covers how they architected a microservices solution to accomplish this, including very advanced monitoring.

Read More


Reasons to Read


  • Livefyre needed a polyglot architecture because some languages were better at solving certain problems at scale.
  • With increased microservices and high scale, building good monitoring tools was essential to identify patterns in edge case problems (that become common at high scale).
  • Livefyre built a cache on S3 for the 80% of their content that was less popular (the long tail) to conserve resources.

ThoughtWorks is an enterprise consultancy. In this post they break down the move of an unnamed enterprise to microservices using the 5 Martin Fowler-defined stages.

Read More


Reasons to Read


  • Building a microservices architecture is both a software task as well as a deployment and process task. It’s critical to think through how to make microservice deployment scalable early on.
  • Developers own the production deployment and support of their software, and this promotes best practices in their code.
  • The challenge of monitoring increases dramatically with decoupled architecture and lots of moving pieces, so it is key to investigate not just failing services but their transitive dependencies.

How Appsflyer handled authentication and authorization as they migrated to microservices.

Read More


Reasons to Read


  • AppsFlyer built their own authenticating and authorizing reverse proxy, Bouncer, based on the Gogeta Project to control user permissions.
  • To reduce the complexity and external dependencies of the backend service and to avoid having to access a central user data service from every backend service, Bouncer adds a user data header to the HTTP request which is sent to the backend service.
  • Bouncer has a client library which backend services use to communicate with it to register the backend service location, let the Bouncer know about the endpoints exposed by the backend service, then parse and add the user data header to the request object

Fiver’s blog post about migrating to microservices when the company reached a stage where system scalability and long-term quality became as important as delivery velocity was at an earlier stage.

Read More


Reasons to Read


  • Fiverr’s approach to dividing up key problem areas and their goals is a useful model for companies looking to adopt microservices in stages.
  • Implementing microservices from day one of an application isn’t practical, but designing for early it should be a priority.
  • After adopting microservices, the curve for new Fiverr developers was easily divided into stages, learning business modules one-by-one.

Karma is a wifi hotspot that works in over 460 US cities. This post focuses on Karma’s rationale for making the transition from monolith to microservices, and serves as a use case you can apply if your organization is also considering the switch.

Read More


Reasons to Read


  • Microservices vs. Libraries? Karma elected microservices over separate libraries combined as a single API. This enabled greater scalability, ability to version APIs, and the ability to use multiple languages.
  • As time progressed, Karma’s engineers reduced the size of each microservice according to an emerging belief that limiting microservices to a single responsibility is most effective.
  • Karma implemented two messaging systems for services to communicate with one another, HTTP and a message queue.