Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/2hZTo6r. Matt Ranney talks about the limits that some companies have encountered in their large microservices deployments and some non-microservices approaches to those same problems. He also talks about the non-microservices systems that Uber is building to maintain developer productivity with a large and growing engineering team. Filmed at qconsf.com. Matt Ranney is Chief Systems Architect at Uber, where he's helping build and scale everything he can. Previously, Ranney was a founder and CTO of Voxer, probably the largest and busiest deployment of Node.js.

1. WHATCOMESAFTER
MICROSERVICES?
MATT RANNEY

2. InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
https://www.infoq.com/presentations/
microservices-future

3. Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide
Presented at QCon San Francisco
www.qconsf.com

4. WHATCOMESAFTER
MICROSERVICES?
MATT RANNEY

5. We hired lots of engineers.

6. They wrote lots of software.

9. This causes lots of problems.

10. Why use microservices at all?

11. Easier releases?

12. Efficiency somehow?

13. Scaling the organization?

14. Coupling

15. APRIL 2016
MAY 2016
OCTOBER 2016

16. New problems

17. Sharded database
RPC
Service discovery
Rate limiting
Circuit breaking
Tracing
Release management

18. New problems

19. Composability

28. Composability

29. Services want their own storage.

31. Developing against this system is hard.

32. Evolving schemas is hard.

34. Having 1M services should be as easy as 1K or 10.
Provisioning storage should be easy as checking in code.
Devs should be able to safely test with real production data.
Fancy types are useful.

35. DOSA

41. Composability

44. RPC

46. Asynchronous message passing FTW

47. “Does developer convenience really trump correctness,
scalability, performance, separation of concerns, extensibility,
and accidental complexity?” [Vinoski (2008)]

51. Composable event processors

52. Workflow? Serverless?

53. Why are we here?

54. Let’s make the tools for building big be
better than the tools for starting small.

55. “Does developer convenience really trump correctness,
scalability, performance, separation of concerns, extensibility,
and accidental complexity?” [Vinoski (2008)]

56. Composability

57. THANKS

58. Watch the video with slide
synchronization on InfoQ.com!
https://www.infoq.com/presentations/
microservices-future