Journey of Monolithic to Independent Services
Problem Statement: We were maintaining 4 separate Branch , 3 instances [Version Management, Project RM, Process RM]
-
- Version Management code : Running separate instance , 5081 lines of code in single class
- Project Release Management : Running separate instance , 4731 lines of code in single class
- Process Release Management: Running separate instance , 4684 lines of code in single class
Solution Approach :
- Divide complete functionality in small TASKS.
- Make each task as an INDEPENDENT module (think how we will reuse this component if needed in future)
- Define BOUNDARY and SCOPE of each module ( within Same component , within Lucy, across Enterprise )
- Create UML DIAGRAM of complete functionality with proper flow and see how they are communicating with each other.
TASKS – 1. Serialize the object 2. Commit Serialized object to Stash 3. Deserialize the Object 4. Link all the Entity ( Project ← Process ← Rule) 5. Correct Entity Version Id
INDEPENDENT – 1. Serde Service 2. StashCommitService 3. KeyCorrector
BOUNDARY 1. SerdeService – Will do only serialization and deserialization of object project and process. Scope – [With in Project ] Current Uses – {VM, Cloning, Release Management}
2. StashCommitService – Will take input as object, userName, password, location of stash, fileName. Scope – [Across Enterprise] Current Uses – [Release Management]
3. KeyCorrector – will take input as project or process will update old version id to new one. Scope – [with in Project] Current Uses – [ VM , Cloning , RM, Application Teams]
UML DIAGRAM – Reference Release management UML diagram.
Best Practices
| S.N | what we had | What we have | Reference and Improvement | |
|---|---|---|---|---|
| 1 | Smart end point URL | project_import/loadProjectV2
project_import/save_projectV2 project_import/copy_project A long list of end point |
migrates/project/
migrates/process/ clones/project/ clones/process/ |
endpoint should not have verb get, set, create, save, update, delete,add,
Reference – https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9 |
| 2 | Max LOC in a Class | 5081 | 500 (Migration Controller , services) | Including imports , Autowired classes, excluding Java doc |
| 3 | Max LOC in a Method | 300 | 50 | Include variable declaration |
| 4 | Code writing style | None | Write similar thought in chunks
(Demo – Serde Service) |
Single pattern for Indentation, number of lines gap, space |
| 5 | Package name convention | We can define single base package for all the modules | ||
| 6 | Class and Variable Name | None |
|
|
| 7 | DRY Principal | None | Don’t repeat yourself | |
| 8 | SOLID Principal | None | Single responsibility | A class should have one and only reason to change , meaning that a class should have only Job.
Demo Serde classes (Job specific classes) |
| 9 | Error Handling | None | Partially Done | https://dzone.com/articles/9-best-practices-to-handle-exceptions-in-java |
| 10 | HTTP response status code | 200 Ok –
400 Bad Request 404 Not found 502 Service unavailable |
||
| 11 | Test cases | None | In Progress | |
| 12 | Abstraction | None | Only required end points are visible to user | Less end point less confusion |
| 13 | Java Doc | None | In Progress | |
| 14 | Minimum Input from User | None | Demo – Project , process | |
User Experience : Demo
Outcome :
- Independent service for each functionality
- Single code base – easy to maintain
- Easy to on board new Engineer with minimum effort
- Easy to enhance any feature
- Easy to add new functionality (process versioning)
- Easy to debug the code with SOLID principal
- User friendly Swagger UI Page
Platform Stability :
- RM, VM, Cloning total time to implement (3, 8, 3)M | New Implementation time (3,8,3)D
- Only 2 defect till now in new code
rk_sehara 