This document discusses replacing the LINE messaging platform's original Weather Bot system with a new system. The Weather Bot was the first bot created for LINE but was becoming difficult to scale and update due to its use of an old programming language and single provider for weather data. The new system aims to be easier to maintain and expand by using microservices and following best practices like source control, documentation, testing and monitoring. It is hoped that the lessons learned from transitioning the Weather Bot can be applied to standardize services for other LINE bot systems as well.

1. REPLACING SYSTEM
LESSONS LEARNT FROM WEATHER BOT
Nguyen Minh Tuan, LINE Corp

2. Agenda
1
LINE
Bot
2
Weather
Bot
3
Replace
Weather
Bot
4
Next
Plan

3. LINE Bot

4. LINE Bot

5. WEATHER
Bot

6. Weather Bot
 Open on April 2012
 First Bot of LINE
 Bot ID: 1

7. Weather Bot List
TAIWAN
SINGAPORE
SPAIN
KOREA
MALAYSIA
COLOMBIA
TURKEY
ARGENTINA
INDIA
VENEZUELA
CHILE
PERU
PHILIPPINES
UK
JAPAN
5,826,046
1,709,716
139,023
1,124,529
65,852
112,248
313,117
199,941
42,035
56,972
120,151
153,379
693,224
1,709,716
90,134
Friend numbers

8. Replace
Weather Bot

9. Replace Weather Bot System
CAUSE
Reason for replace
REQUIREMENT
Of Weather Bot
CONS
Of Weather Bot System
PROS
Of Weather Bot System
SOLUTION
For New System

10. Cause
Difficult
To scale, change, add more Bot
Update API
To new Message API (version 2.0)
Old Language
Using programming language (PERL)
Change Provider
To Weather Forecast Content Provider
Not Enough
Monitor System is not enough
Others
…

11. Requirement
 Project quality must be equal or higher
 Zero down time

12. Cons of System
Swim by yourself
Balance betweenTime and Dream
NO
Perl Developer
Specification
Technical document
MUST
A Complex System

13. Pros of System
 Free to implement every thing (not time)
 Standing on the Kong’s shoulders

14. Solutions
A Complex System
Split to manage
Use Microservices

16. Solutions
NO
Specification
Technical Doc
Specs are the what users
are seeing
Recreate documents from
code and bot’s behavior

17. Solutions
Break
&
Build
 Devs always want to break and build instead of
modification
 Having a balance point between Time and Dream
 Some parts are recreated, some parts are
modified but recreated later

18. Solutions
Project Quality
Use Git Process
Review
Unit Test, Intergration Test (for Developer)
Auto Test (for Tester)
Monitoring System (System and App Logic)
 Flow must be reviewed before coding
 Code must be reviewed before merging

19. UnitTest Effection
Coding Time Testing Time Release Time
~ 0%30% ~ 50%50% ~ 100%
Confidence
200% ~ 300%

20. Next Plan

21. Next Plan
Add
New Bot
Standard
Services
for other systems

22. Q&A

23. Thank You