Source: infoq.com
At several points throughout his career, Phil Calçado has worked on transitioning monoliths to a microservices architecture, but recently the challenge for him has instead been in migrating to serverless. In a presentation at the recent QCon New York conference, he talked about his experience combining the serverless concept with microservices.
Calçado, previously having worked for Meetup and SoundCloud, and currently at SeatGeek, started by defining microservices as being highly distributed application architectures, and emphasizes distributed application with a focus on business logic, in contrast to the commonly used term distributed system, where he believes there is too much focus on infrastructure.
From his microservices perspective, Calçado finds it hard to define serverless and notes that people seem to have very different definitions. He therefore refers to the book What is Serverless? written by Mike Roberts and John Chapin, both at Symphonia. One distinctive feature of serverless, he points out, is that there is a disconnect between the code you work with and the concept of service, which means that you don’t think about CPU, memory, and so on.
Meetup is one of the original New York City startups and is mostly based on one big monolithic JVM-based application, which is hard to work with. In an attempt to move towards serverless, they started a project aiming for a new asynchronous event-based design. In the new design, events are created from changes in the database made by the monolith, and these events are then stored and processed by lambda functions and finally stored as specific views (CQRS projections) needed by the business.
The project was not so successful; they reverted their approach and went back to using an API. One problem that often occurred was that solving a bug also meant reprocessing all data, since the code change could mean a change in logic and incorrect data in the views. Another problem was how to handle writes back to the monolith. This ultimately was too complicated, so they took a pragmatic approach and used the legacy code as an API for writes. But this solution raised the question if all the work with events and lambdas when reading data was necessary. The biggest problem howver, was the lack of governance; they had no control of ownership, where functions were deployed, which ones that were in production, and other similar problems.
Calçado notes though that some things worked out much better than he expected. Getting new engineers to be productive went faster than expected. Having the engineering teams both own and operate their own deployments worked much better than he had experienced before, and he believes one reason for this is the small size of lambdas, which makes it easier to have full control. Developer happiness was only higher than he expected.
A problem Calçado sees with serverless is that with microservices, we still have a fairly limited number of small services, but with serverless the features are split into a huge number of functions. Often these functions also communicate with other functions in a form of peer-to-peer network, which makes it very hard to know what’s happening anymore. He refers to a tweet by Chris Ford and calls this: Pinball machine architecture.
To avoid this type of architecture, he refers to Martin Fowler and his article from 2002: Public versus Published Interfaces. Although there are interfaces that are public, they still should not be used. The provider of a library or similar type of software should provide a published interface, which is the only one that should be used. Based on this idea, Calçado and his teams separated all functions into groups with an API gateway in front of each group, and the gateways are the only way of accessing the functions. He admits that this is like creating services with functions as the computing units — using serverless as building blocks for microservices.
Calçado notes that at Meetup they went full on AWS, but even though they did everything the Amazon way, he still had about 10% of the engineering teams dedicated to tooling and platforms. There are still a lot of loose ends with things that don’t communicate with each other, and other similar problems.
When looking back at what they have achieved, Calçado is not sure if the result really is serverless, but emphasizes that the important thing is that they have managed to take a couple of steps from a big and complicated legacy application, towards a world of serverless computing. He notes that although serverless looks like the future, we are not there yet. But with better tooling, he believes it’s the right way to go.
