Moving to Microservices at SoundCloud with Lukasz Plotnicki
“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.
- 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?
- BFF @ SoundCloud
- Monolithic application
- How we ended up with microservices
- The Strangler Pattern
- Bounded Context
- Domain-driven design
- Lukasz on Twitter
|Hired.com is the job marketplace for software engineers. Go to hired.com/softwareengineeringdaily to get a $600 bonus upon landing a job through Hired.|
|Codeship is a fast and secure hosted Continuous Delivery platform that scales with your needs. Visit codeship.com to get started today.|