After spending years doing big rewrites and seeing how much time people spend building software that they throw away, Chad Fowler at the GOTO Berlin Conference declared that he believes we should be thinking of legacy as something positive that we want to leave for coming generations, not as a bad thing that is so common today.
When Chad joined 6Wunderkinder, the company behind Wunderlist, as CTO, he saw a large monolithic Rails application, a large monolithic database and a monolithic deployment process. One of the big problems contributing to building monoliths that Chad sees is that we let it grow and as it gets more complicated we build abstractions around it, trying to maintain that one growing thing. If we instead want to keep things separate and replaceable, Chad thinks we must bring in some level of decoupling by making everything heterogeneous, and this has led him into a Microservices architecture.
Instead of rewriting the whole system they begun building new functionality implemented as new services. At the same time they started prototyping for a new system and also worked with splitting the large database into smaller databases including migration of all data. After all this work they had proof that the new architecture would work and they then did a big rewrite creating a whole new architecture for the backend and partially for the clients. This did work, even though Chad is not proud of that.
In their new architecture all requests come in through a top-level server, a web-socket server accepting requests from the web browsers then streaming content back as it becomes ready. Below there is a more traditional HTTP server that deals with authentication and authorization at one level. Chad notes that these first two layers are fundamental, when breaking a system up into a number of services you still need one way to talk to the system. They today have around 60 services making up the system backend and they found it important to expose one API instead of forcing developers using the API having to considering these 60 services figuring out where to find certain functionality.
Inside these two top layers they have two inner layers of services, one with no database connection whatsoever where a check is made that a user is allowed to perform the request, and a second layer which basically acts as the database. Every time a change happens a mutation record is generated with information about what changed and on which item, e.g. a task changed its title. This record is then picked up and fanned out to all services in the second layer that might be interested in the event. A risk in this is that a change might create an event that creates the same type of change, effectively creating a loop; this is avoided using aggressive monitoring.
Monitoring is for Chad extremely important in this sort of architecture and one advantage he has found when using microservices is that they make it possible to see exactly what is wrong; with a monolith it’s hard to separate out what the problem is.
The GOTO Berlin Conference 2014 is the second GOTO conference in Berlin, with around 550 attendees and 80 speakers.