After living with microservices for three years at Gilt we can see advantages in team ownership, boundaries defined by APIs and complex problems broken down into small ones. Challenges still exists in tooling, integration environments and monitoring, Yoni Goldberg explained in a presentation at the QCon London conference describing the challenges they encountered moving to a microservices architecture.
Goldberg, lead software engineer at Gilt, a flash sales business, described how Gilt started as a traditional start-up in 2007 using Ruby on Rails. Two years later they needed thousands of ruby processes running and the database was overloaded.
At this point they moved to the JVM and started what Goldberg calls a Macro/Micro-service era where he distinguishes between a macroservice which handle a specific domain, e.g. sales or payments, and a micro service which you get by breaking a macro service down into smaller services. They also introduced dedicated data stores for the services. First they created 10 macroservices for the core business, services that are still in use and that all other services are depending on. Using these are a set of supporting services, e.g. user preferences, which are less critical, the business will still work if one goes down. On top of these are another set of services generating the views for all users. This new architecture solved 99% of their scaling problems but left some of the problems developers experienced with the new services being semi-monolithic and lacking clear ownership of code. They also had problems with deployments and long integration cycles.
To overcome these problems they increased the number of microservices and could then empower teams to take responsibility for not only developing a service but also testing, deployment and monitoring. This also clarified ownership; basically a team became the owner of a service. The biggest benefit though for Goldberg came with the smaller scope in a microservice, making it easier to grasp and reason about. At the same time they started work with lots of small web applications (LOSA) by breaking web pages up in smaller pieces.
All these microservices have created a lot of dependencies between them, the biggest challenge Goldberg can see for developers is that for every change they have to make sure they don’t break any other service. If they do a breaking change it must be done in small steps, after the change is done all clients must be moved to the new endpoint before the old one can be deleted. A problem they have experienced is that many web applications are doing the same calls to e.g. generate a user profile. To overcome this they have created something Goldberg calls a mid-tier microservice, a service that knows the calls needed to create the user profile and which the web applications can call instead.
One final challenge Goldberg mentions is data ownership. Since they moved to one database per microservice ending in a lot of small databases they need a way to manage the schemas for each one of them that are a relational database and are using versioning to keep track of all changes.
Goldberg's slides can be downloaded here, the presentation will be published on InfoQ during the coming months.
