Moving to Microservices at SoundCloud with Lukasz Plotnicki
Podcast: Play in new window | Download
Subscribe: RSS
“You can have a monolith, and it can be a perfectly good thing.”
Monoliths versus microservices – the architectural debate continues across the internet. SoundCloud is a popular music company that experienced the rapid development benefits of a monolith, as well as the long-term technical debt. That technical debt has since been relieved by a move towards microservices. In this episode of Software Engineering Daily, Lukasz joins Jeff to talk about the realities of moving from a monolith to a microservices architecture, and walks through the lessons learned at SoundCloud.
Lukasz Plotnicki is a consultant and software engineer at ThoughtWorks, which helps clients address their software development challenges and needs.
Questions
- What are the application requirements of SoundCloud?
- Is there something about Rails that lends towards apps becoming monolithic?
- How did SoundCloud gradually ease into using microservice architecture?
- How did the variety of front-end interfaces affect SoundCloud’s monolithic architecture?
- What is the difference between a BFF and a microservice?
- What are the downsides of a BFF implementation?
- What are the lessons the SoundCloud case study has taught you about software architecture?
Links
- SoundCloud
- BFF @ SoundCloud
- Thoughtworks
- Monolithic application
- How we ended up with microservices
- The Strangler Pattern
- Bounded Context
- Domain-driven design
- Lukasz on Twitter