For the last ten years or so, many companies have focused on migrating from larger, monolithic systems and applications towards a specific style of Service-Oriented Architecture called Microservices. The promise was that these smaller, loosely-coupled, and independently developed components would increase productivity and safety for organizations, as large and complex business challenges can be broken down into smaller and simpler components. However, even before most organizations were able to fully migrate to this new architecture and enjoy its promised benefits, a new iteration of cloud computing has been made available in the shape of Serverless platforms such as AWS Lambda, and Google Cloud and Microsoft Azure Functions. Now lots of companies found themselves conflicted between abandoning their traditional microservices approach towards Serverless, often even before they have fully migrated to it from the legacy systems. After leading successful Microservices adoption at SoundCloud and DigitalOcean, recently at Meetup I have faced the challenge of pivoting from a traditional monolith-to-microservices migration to a cloud-native platform. In this talk, let's discuss the fundamental concepts, technologies, and practices behind Microservices and Serverless, and how a software architect used to distributed systems based on microservices needs to change their mindset and approach when adopting Serverless.

1. The Not-So-Straigh.orward
Road From Microservices
to Serverless
Phil Calçado - @pcalcado - philcalcado.com

2. What are microservices?

3. Microservices seem to be
highly-distributed
applica?on architectures.

4. What is Serverless?

5. Who knows? !

7. e.g.

8. Keep your monolith for as
long as possible

9. Monolith

10. Service B
Monolith

11. Service B
Monolith
Service C

12. But what if you waited so long
microservices aren’t hype
anymore
there are other alterna?ves?

13. “Chaps?ck"

15. This project wasn’t
par?cularly successful

16. Some challenges we
faced

17. Solving a bug means re-
processing all the data

18. “The write path issue”

19. Write path

20. Cold start for JVM
Lambdas

21. DynamoDB Costs

22. Who owns what? What
calls what? Is this
Lambda supposed to be
in produc?on?

23. Some of the challenges
we DID NOT face

24. GeSng new engineers
produc?ve on Lambda/
DynamoDB

25. Cold start for Node.js
Lambdas

26. Opera?ons allergy

27. "Local" development

28. Developer happiness

29. How can we keep the good
and get rid of the bad?

30. User Experience
Database
Back-end
Database
User Experience
Database
Back-end
Point of Sale
Financial Reporting
User ExperienceBack-end
User Manager

31. User Experience
Database
Back-end
Database
User Experience
Database
Back-end
Point of Sale
Financial Reporting
User ExperienceBack-end
User Manager

32. User Experience
Database
Database
Database
Service
Service
Service
User Experience
λ
Admin
Web App

33. User Experience
Database
Database
Database
User Experience
Consumer
Website
Admin
Web App
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda

35. We were suffering from
Pinball machine Architecture

37. User Experience
Database
Database
Database
User Experience
Consumer
Website
Admin
Web App
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda

38. User Experience
Database
Database
Database
User Experience
Consumer
Website
Admin
Web App
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
λLambda
API Gateway
API Gateway
API Gateway

39. Use Serverless as building
blocks for Microservices

40. AWS Accounts are a great
way to define service
boundaries

41. API Gateway is actually
quite expensive
(at the moment)

42. ~1/10 of the
engineering teams was
dedicated to pla.orm

43. But… is this really Serverless?

44. Who cares? !

45. You can’t got from 2/10 to
10/10 in one jump.

46. Serverless looks like the
future, but we’re not
there yet

47. Ques?ons?