0deps ಚಳುವಳಿ: ಸ್ಥಳೀಯ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಬದಲಾಗದ ಒಪ್ಪಂದಗಳು
ಸಾಫ್ಟ್ವೇರ್ ಡೆವಲಪರ್ಗಳು ಹೆಚ್ಚಾಗಿ ನೂರಾರು ಬಾಹ್ಯ ಲೈಬ್ರರಿಗಳನ್ನು (external libraries) ಇನ್ಸ್ಟಾಲ್ ಮಾಡುತ್ತಾರೆ. ಆಧುನಿಕ ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಸಾವಿರಾರು ಟ್ರಾನ್ಸಿಟಿವ್ ಅವಲಂಬನೆಗಳನ್ನು (transitive dependencies) ಅವಲಂಬಿಸಿವೆ. ಇದರರ್ಥ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅಪರಿಚಿತರ ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ.
ಇದು ಸಾಫ್ಟ್ವೇರ್ ಸಪ್ಲೈ ಚೈನ್ ಅಪಾಯವನ್ನು (software supply chain risk) ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಪ್ರತಿಯೊಂದು ಅವಲಂಬನೆಯು ನಿಮ್ಮ ಅಟ್ಯಾಕ್ ಸರ್ಫೇಸ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಇದು:
- ಭದ್ರತಾ ದೋಷಗಳನ್ನು (security flaws) ಪರಿಚಯಿಸಬಹುದು.
- ಸಪ್ಲೈ ಚೈನ್ ದಾಳಿಗಳಿಗೆ ಗುರಿಯಾಗಬಹುದು.
- ನಿರ್ವಹಕರಿಂದ (maintainers) ಕೈಬಿಡಲ್ಪಡಬಹುದು.
- ತನ್ನ ಪಬ್ಲಿಕ್ API ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು.
- ಬ್ಯಾಕ್ವರ್ಡ್ ಕಾಂಪ್ಯಾಟಿಬಿಲಿಟಿಯನ್ನು (backward compatibility) ಹಾಳುಮಾಡಬಹುದು.
0deps ಚಳುವಳಿಯು ಒಂದು ಸರಳ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತದೆ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೇವಲ ನೀವು ನಿಯಂತ್ರಿಸುವ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ಅವಲಂಬಿಸಿದ್ದರೆ ಏನಾಗಬಹುದು?
0deps ಮಾದರಿಯಲ್ಲಿ, ನೀವು ಅಗತ್ಯವಿರುವ ಅವಲಂಬನೆಗಳನ್ನು ನೇರವಾಗಿ ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ (project repository) ಸೇರಿಸುತ್ತೀರಿ. ಬಿಲ್ಡ್ಗಳ ಸಮಯದಲ್ಲಿ ಅವುಗಳನ್ನು ಡೈನಾಮಿಕ್ ಆಗಿ ಡೌನ್ಲೋಡ್ ಮಾಡುವುದನ್ನು ನೀವು ನಿಲ್ಲಿಸುತ್ತೀರಿ. ಅಪ್ಲಿಕೇಶನ್ ರನ್ ಮಾಡಲು ಬೇಕಾದ ಎಲ್ಲವೂ ಮೊದಲಿನಿಂದම ರೆಪೊದಲ್ಲಿ ಇರುತ್ತದೆ.
ಈ ವಿಧಾನವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ:
- ಪುನರಾವರ್ತಿತ ಬಿಲ್ಡ್ಗಳು (Reproducible builds).
- ಬಾಹ್ಯ ರಿಜಿಸ್ಟರಿಗಳ ಮೇಲಿನ ಅವಲಂಬನೆ ಕಡಿಮೆ ಇರುತ್ತದೆ.
- ಕೇಂದ್ರೀಕೃತ ಭದ್ರತಾ ಆಡಿಟ್ಗಳು (Centralized security audits).
- ಹೆಚ್ಚಿನ ಮುನ್ಸೂಚನೆ ಸಾಮರ್ಥ್ಯ (Higher predictability).
ಕೋಡ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿ (static) ಇರಿಸುವುದು ಇದರ ಮುಖ್ಯ ತತ್ವವಲ್ಲ. ಬಗ್ಗಳನ್ನು ಸರಿಪಡಿಸಲು ಮತ್ತು ಭದ್ರತೆಯನ್ನು ಸುಧಾರಿಸಲು ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ಗಳು ಮತ್ತು ಅಲ್ಗಾರಿದಮ್ಗಳು ವಿಕಸನಗೊಳ್ಳಬೇಕು. ಪಬ್ಲಿಕ್ ಕಾಂಟ್ರಾಕ್ಟ್ (public contract) ಮಾತ್ರ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.
ಪ್ರತಿಯೊಂದು ಲೈಬ್ರರಿಯು ಎಚ್ಚರಿಕೆಯಿಂದ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗಳು:
authenticate()createSession()verifyPasskey()
ಈ ಫಂಕ್ಷನ್ಗಳು ಒಂದು ಒಪ್ಪಂದವನ್ನು (contract) ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ. ಈ ಒಪ್ಪಂದವು ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ. ನೀವು ಅದರ ಹಿಂದಿರುವ ಕೋಡ್ ಅನ್ನು ಮರುಬರೆಯಬಹುದು ಅಥವಾ ಲೈಬ್ರರಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಬಹುದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಉಳಿದ ಭಾಗಗಳಿಗೆ ಈ ಬದಲಾವಣೆ ತಿಳಿಯುವುದಿಲ್ಲ.
ಭದ್ರತಾ ದೋಷ (vulnerability) ಕಂಡುಬಂದಾಗ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತೀರಿ:
- ದೋಷವನ್ನು ಸರಿಪಡಿಸುವುದು.
- ಅಪ್ಡೇಟ್ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹಾಳುಮಾಡುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವುದು.
0deps ಆರ್ಕಿಟೆಕ್ಚರ್ನಲ್ಲಿ, ಎರಡನೇ ಸಮಸ್ಯೆ ಮಾಯವಾಗುತ್ತದೆ. ಪಬ್ಲಿಕ್ API ಹಾಗೆಯೇ ಇರುವಾಗ ನೀವು ಆಂತರಿಕ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಬಹುದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಯಾವುದೇ ಕೋಡ್ ಬದಲಾವಣೆಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ನೀವು ಆಂತರಿಕ ಅಡಾಪ್ಟರ್ (internal adapter) ಬಳಸಿ ಬಾಹ್ಯ ಇಂಟಿಗ್ರೇಷನ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೀರಿ: Application -> Public Interface -> Adapter -> Implementation
ಒಂದು ವೇಳೆ ನಾಳೆ ಯಾವುದಾದರೂ ಲೈಬ್ರರಿ ಮಾಯವಾದರೆ, ನೀವು ಕೇವಲ ಅಡಾಪ್ಟರ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ ಸಾಕು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಬೇರೆ ಯಾವುದೇ ಭಾಗವು ಹಾಳಾಗುವುದಿಲ್ಲ.
0deps ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಪರಿಪೂರ್ಣವಾಗಿಸುವುದಿಲ್ಲ. ಇದು ಸಪ್ಲೈ ಚೈನ್ ಅಪಾಯಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇದು ಮಾಲಿಕಿಯಸ್ ಪ್ಯಾಕೇಜ್ಗಳು (malicious packages), ರಿಜಿಸ್ಟ್ರಿ ಕಾಂಪ್ರೊಮೈಸ್ ಮತ್ತು ಡಿಪೆಂಡೆನ್ಸಿ ಕನ್ಫ್ಯೂಷನ್ನಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
ಪ್ರಾಜೆಕ್ಟ್ಗಳು ದಶಕಗಳ ಕಾಲ ಇರುತ್ತವೆ. ಲೈಬ್ರರಿಗಳು ಮತ್ತು ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಬದಲಾಗುತ್ತವೆ. 0deps ಮೂಲಕ, ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು (ecosystem) ಹೇಗೆ ವಿಕಸನಗೊಂಡರೂ ಸಹ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅದೇ ಸ್ಥಿರವಾದ ಒಪ್ಪಂದಗಳನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.