From idea to production with serverless architecture

JEEConf, 18.05.2018

Transcript

1. 1 From idea to production with serverless architecture Kirill Zotin kzotin@gmail.com
3. Talk is about... 3 • Our case study • Painful areas • Handy practices
4. Serverless is... 4 Serverless architectures refer to applications that significantly depend on third-party services ("BaaS") or on custom code that's run in ephemeral containers ("FaaS") © Martin Fowler
6. Function as a Service 6
7. Serverless is... - Pay for consumption, idle is free No servers to provision or manage ✓ 1 7 Fault tolerance Automatic scaling 2 3 ✓ 4 ✓ ✓ Using serverless.com 6 B2D 5 ✓
8. 8 10+ years in IT: • Engineer • Team leader • Engineering Manager About myself...
9. THE TEAM Highly agile, international, virtual team Skills/experience: mobile apps, gamification, behavioral psychology, Android development, infrastructure, start-ups, scaling, business strategy, marketing, community building, product development, learning/education, international solutions, change management, agile methodologies. A team that shares a purpose, solves problems, gets things done Pedro Mêdas Harald Paul Mathias Daus Iain Thackrah Thomas Kuryura Paula Cassin Kirill Zotin Jurgen Appelo 9
10. THE STACKOVERFLOW OF AGILE PRACTICES People want to find and share answers to problems. People want to find and share guidance to solutions. 10
11. PRODUCT Data (proprietary, our IP) Community (professionals) Gamification (using, rating, sharing) Content (user-owned practices & work guides) Platform Informing, recommending Tracking, measuring Creating, using Playing, socializing 11
12. v 0.1.1 Delivery API UI CMS
13. v 0.1.2 Delivery API UI Firebase Auth RTDB Cloud Functions CMS
14. v 0.1.2 Delivery API UI Firebase Auth RTDB Cloud Functions CMS Spring Boot MongoDB
15. v 0.1.3 Delivery API UI Firebase Auth Firestore CMS Analytics Crashlytics Cloud Functions
16. LET’S RECAP Phase 1 Phase 2 Phase 3 • Mobile App • Content Delivery APIs • Content Management UI • Backend logic • Monitoring & crash reporting • Usage analytics ✓ 16
17. 17 More analytics
18. v 0.2.1 Firebase Mobile Analytics User Data Web Analytics Big Query Data Studio
19. v 0.2.1 Firebase Mobile Analytics User Data Web Analytics Big Query Data Studio Hadoop BI Dashboard
20. 20 Business automation
21. Firebase New user registered Update CRM v 0.2.2
22. Firebase New user registered Update CRM v 0.2.2
23. Firebase New user registered Update CRM Feedback submit Send Message v 0.2.2
24. Firebase New user registered Update CRM Feedback submit Send Message Weekly Send Email v 0.2.2
25. export const weeklySendNewsletter = functions .pubsub.topic('weekly-tick') .onPublish(() => { const data = await fetchData() const report = await renderReport() return Promise.all([ store(report), sendEmail(getEmailConfig(), report), logEvent() ]) }
26. export const weeklySendNewsletter = functions .pubsub.topic('weekly-tick') .onPublish(() => { const data = await fetchData() const report = await renderReport() return Promise.all([ store(report), sendEmail(getEmailConfig(), report), logEvent() ]) } “RabbitMQ”
27. 27 Search indexing
28. v 0.2.3 Firebase Player data Ranking Relevance Analytics Indices Content Cloud Function
29. v 0.2.3 Firebase Player data Ranking Relevance Analytics Indices Content Cloud Function Elastic Search
30. LET’S RECAP Phase 1 Phase 2 Phase 3 • Mobile App • Content Delivery APIs • Content Management UI • Backend logic • Monitoring & crash reporting • Analytics • Data warehouse • BI Dashboards • Search indexing • CRM integration • Emails • Slack messages • Monitoring • Regular E2E tests ✓ 30
32. Function cold start 32
35. 35 → Cloud Functions FaaS → AppEngine Flex PaaS → Digital Ocean IaaS Web App hosting
36. Play by vendor rules 36 • Access DB from frontend • Different security patterns • Service updates
39. 39 Team impact • Lack of best practices • Team scaling is hard
40. 40 Best practices (worked for us)
41. 41 Solve current problems
42. 42 Under-engineered is OK
43. 43 Minimum viable documentation Always up-to date: • Current state ◦ Overview ◦ DB structure doc • Evolution history ◦ ADR
44. 44 Architecture decision records Template • Title • Status • Decision • Context • Consequences 1 page max Not for discussions
45. 45 E2E responsibility
47. 47 Summary No deep specialization needed Toolset not mature Works OOTB Cheaper in most cases Practices are just emerging Expect surprises :)
48. Thank you! 48 Kirill Zotin kzotin@gmail.com