ಹಲೋ, ಹಬ್ರ್! ನಾನು ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇನೆ ಲೇಖನದ ಲೇಖಕರ ಅನುವಾದ .
ಐಟಿ ಜಗತ್ತು ಕ್ರಮೇಣ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಂತಹ ಪರಿಕರಗಳತ್ತ ಸಾಗುತ್ತಿರುವ ಸಮಯದಲ್ಲಿ, ಒಂದೇ ಒಂದು ಸಮಸ್ಯೆ ಹೆಚ್ಚು ಹೆಚ್ಚು ಗಮನಕ್ಕೆ ಬರುತ್ತಿದೆ. ಈ ಸಮಸ್ಯೆ - ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆವೃತ್ತಿಗಳು. ಆದರೂ, ಪ್ರಸ್ತುತ ಪರಿಸ್ಥಿತಿ ಅದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ಐಟಿ ಸಮುದಾಯ ನಂಬುತ್ತದೆ ಹಿಂದಿನ ಪೀಳಿಗೆಯ ತಂತ್ರಜ್ಞಾನ. ಆದಾಗ್ಯೂ, ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಆವೃತ್ತಿ ಮಾಡುವುದು ಬಹಳ ಸಂಕೀರ್ಣವಾದ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಇದರ ಒಂದು ಪುರಾವೆಯಂತಹ ಲೇಖನಗಳು ಆಗಿರಬಹುದು .
ಈ ಪಠ್ಯವನ್ನು ಓದುವ ಮೂಲಕ ನಿಮಗೆ ಇನ್ನೂ ಸಮಸ್ಯೆ ಅರ್ಥವಾಗದಿದ್ದರೆ, ನಾನು ವಿವರಿಸುತ್ತೇನೆ. ನಿಮ್ಮ ಉತ್ಪನ್ನವು 10 ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಎಂದು ಹೇಳೋಣ. ಈಗ ಈ ಪ್ರತಿಯೊಂದು ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳಿಗೆ 1 ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ ಎಂದು ಭಾವಿಸೋಣ. ಕೇವಲ 1 ಆವೃತ್ತಿ - ಇದು ಅತ್ಯಂತ ಕ್ಷುಲ್ಲಕ ಮತ್ತು ಅತ್ಯಲ್ಪ ಸತ್ಯ ಎಂದು ನಾವೆಲ್ಲರೂ ಒಪ್ಪಿಕೊಳ್ಳಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಈಗ, ಆದಾಗ್ಯೂ, ನಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಮತ್ತೊಮ್ಮೆ ನೋಡೋಣ. ಪ್ರತಿ ಘಟಕದ ಕೇವಲ ಒಂದು ಹೊಸ ಆವೃತ್ತಿಯೊಂದಿಗೆ, ನಾವು ಈಗ 2^10 - ಅಥವಾ ನಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಹೇಗೆ ಸಂಯೋಜಿಸಬಹುದು ಎಂಬುದರ 1024 ಕ್ರಮಪಲ್ಲಟನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಇನ್ನೂ ಏನಾದರೂ ತಪ್ಪು ತಿಳುವಳಿಕೆ ಇದ್ದರೆ, ನಾನು ಗಣಿತವನ್ನು ಒಡೆಯುತ್ತೇನೆ. ಆದ್ದರಿಂದ ನಾವು 10 ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಪ್ರತಿಯೊಂದೂ ಒಂದು ನವೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಅಂದರೆ, ನಾವು ಪ್ರತಿ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ 2 ಸಂಭವನೀಯ ಆವೃತ್ತಿಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ (ಹಳೆಯ ಅಥವಾ ಹೊಸದು). ಈಗ, ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನ ಘಟಕಗಳಿಗೆ, ನಾವು ಈ ಎರಡು ಆವೃತ್ತಿಗಳಲ್ಲಿ ಒಂದನ್ನು ಬಳಸಬಹುದು. ಗಣಿತದ ಪ್ರಕಾರ, ನಾವು 10 ಅಂಕೆಗಳ ಬೈನರಿ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿದ್ದರೆ ಅದು ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, 1 ಹೊಸ ಆವೃತ್ತಿಯಾಗಿದೆ ಮತ್ತು 0 ಹಳೆಯ ಆವೃತ್ತಿಯಾಗಿದೆ ಎಂದು ಹೇಳೋಣ - ನಂತರ ಒಂದು ಸಂಭವನೀಯ ಕ್ರಮಪಲ್ಲಟನೆಯನ್ನು 1001000000 ಎಂದು ಸೂಚಿಸಬಹುದು - ಅಲ್ಲಿ 1 ನೇ ಮತ್ತು 4 ನೇ ಘಟಕಗಳನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಉಳಿದವುಗಳಲ್ಲ. 10-ಅಂಕಿಯ ಬೈನರಿ ಸಂಖ್ಯೆಯು 2^10 ಅಥವಾ 1024 ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿರಬಹುದು ಎಂದು ಗಣಿತದಿಂದ ನಮಗೆ ತಿಳಿದಿದೆ. ಅಂದರೆ, ನಾವು ವ್ಯವಹರಿಸುತ್ತಿರುವ ಸಂಖ್ಯೆಯ ಪ್ರಮಾಣವನ್ನು ನಾವು ಖಚಿತಪಡಿಸಿದ್ದೇವೆ.
ನಮ್ಮ ತಾರ್ಕಿಕತೆಯನ್ನು ಮತ್ತಷ್ಟು ಮುಂದುವರಿಸೋಣ - ನಾವು 100 ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಪ್ರತಿಯೊಂದೂ 10 ಸಂಭವನೀಯ ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? ಇಡೀ ಪರಿಸ್ಥಿತಿಯು ಸಾಕಷ್ಟು ಅಹಿತಕರವಾಗುತ್ತದೆ - ನಾವು ಈಗ 10^100 ಕ್ರಮಪಲ್ಲಟನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಇದು ದೊಡ್ಡ ಸಂಖ್ಯೆಯಾಗಿದೆ. ಹೇಗಾದರೂ, ನಾನು ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಈ ರೀತಿ ಲೇಬಲ್ ಮಾಡಲು ಬಯಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಈಗ ನಾವು ಇನ್ನು ಮುಂದೆ "ಕುಬರ್ನೆಟ್ಸ್" ನಂತಹ ಪದಗಳ ಹಿಂದೆ ಅಡಗಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಬದಲಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತಿದ್ದೇವೆ.
ಈ ಸಮಸ್ಯೆಯಿಂದ ನಾನು ಏಕೆ ಆಕರ್ಷಿತನಾಗಿದ್ದೇನೆ? ಭಾಗಶಃ ಏಕೆಂದರೆ, ಹಿಂದೆ NLP ಮತ್ತು AI ಜಗತ್ತಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ್ದರಿಂದ, ನಾವು ಸುಮಾರು 5-6 ವರ್ಷಗಳ ಹಿಂದೆ ಸಂಯೋಜಿತ ಸ್ಫೋಟದ ಸಮಸ್ಯೆಯನ್ನು ಚರ್ಚಿಸಿದ್ದೇವೆ. ಆವೃತ್ತಿಗಳ ಬದಲಿಗೆ ನಾವು ಪ್ರತ್ಯೇಕ ಪದಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಉತ್ಪನ್ನಗಳ ಬದಲಿಗೆ ನಾವು ವಾಕ್ಯಗಳು ಮತ್ತು ಪ್ಯಾರಾಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು NLP ಮತ್ತು AI ಯ ಸಮಸ್ಯೆಗಳು ಬಹುಮಟ್ಟಿಗೆ ಬಗೆಹರಿಯದಿದ್ದರೂ, ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಲ್ಲಿ ಗಮನಾರ್ಹ ಪ್ರಗತಿಯನ್ನು ಮಾಡಲಾಗಿದೆ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು. (ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಪ್ರಗತಿ ಸಾಧಿಸಬಹುದುоಉದ್ಯಮದಲ್ಲಿರುವ ಜನರು ಯಂತ್ರ ಕಲಿಕೆಗೆ ಸ್ವಲ್ಪ ಕಡಿಮೆ ಗಮನ ನೀಡಿದರೆ ಮತ್ತು ಇತರ ತಂತ್ರಗಳಿಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಗಮನ ನೀಡಿದರೆ ಅದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ - ಆದರೆ ಇದು ಈಗಾಗಲೇ ವಿಷಯವಲ್ಲ).
DevOps ಮತ್ತು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಜಗತ್ತಿಗೆ ಹಿಂತಿರುಗೋಣ. ಕುಂಸ್ಟ್‌ಕಮೆರಾದಲ್ಲಿ ಆನೆಯ ವೇಷ ಧರಿಸಿ ನಾವು ಒಂದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತಿದ್ದೇವೆ - ಏಕೆಂದರೆ ನಾನು ಆಗಾಗ್ಗೆ ಕೇಳುವುದು "ಕೇವಲ ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಚುಕ್ಕಾಣಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಮತ್ತು ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ!" ಆದರೆ ಇಲ್ಲ, ಎಲ್ಲವನ್ನೂ ಹಾಗೆಯೇ ಬಿಟ್ಟರೆ ಎಲ್ಲವೂ ಸರಿಯಾಗುವುದಿಲ್ಲ. ಇದಲ್ಲದೆ, ಈ ಸಮಸ್ಯೆಗೆ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಪರಿಹಾರವು ಅದರ ಸಂಕೀರ್ಣತೆಯಿಂದಾಗಿ ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ. NLP ಯಲ್ಲಿರುವಂತೆ, ಹುಡುಕಾಟದ ವ್ಯಾಪ್ತಿಯನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುವ ಮೂಲಕ ನಾವು ಮೊದಲು ಈ ಸಮಸ್ಯೆಯನ್ನು ಸಮೀಪಿಸಬೇಕು - ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಹಳೆಯ ಕ್ರಮಪಲ್ಲಟನೆಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ.
ಸಹಾಯ ಮಾಡಬಹುದಾದ ವಿಷಯವೆಂದರೆ ನಾನು ಕಳೆದ ವರ್ಷ ಬರೆದದ್ದು . ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ CI/CD ಪ್ರಕ್ರಿಯೆಯು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಹೆಚ್ಚು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಆದಾಗ್ಯೂ, CI/CD ಯೊಂದಿಗಿನ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯು ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ ಮತ್ತು ಟ್ರ್ಯಾಕಿಂಗ್ ಘಟಕಗಳಿಗೆ ಹೆಚ್ಚುವರಿ ಸಾಧನಗಳಿಲ್ಲದೆ ಕ್ರಮಪಲ್ಲಟನೆಗಳ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಾಕಷ್ಟು ಉತ್ತಮವಾಗಿಲ್ಲ.
ನಮಗೆ ಬೇಕಾಗಿರುವುದು ಏಕೀಕರಣ ಹಂತದಲ್ಲಿ ಪ್ರಯೋಗದ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಅಲ್ಲಿ ನಾವು ಪ್ರತಿ ಘಟಕಕ್ಕೆ ಅಪಾಯಕಾರಿ ಅಂಶವನ್ನು ನಿರ್ಧರಿಸಬಹುದು ಮತ್ತು ವಿವಿಧ ಘಟಕಗಳನ್ನು ನವೀಕರಿಸಲು ಮತ್ತು ಆಪರೇಟರ್ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಪರೀಕ್ಷಿಸಲು ಸ್ವಯಂಚಾಲಿತ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಹ ಹೊಂದಿದ್ದೇವೆ - ಯಾವುದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಏನು ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನೋಡಲು.
ಅಂತಹ ಪ್ರಯೋಗಗಳ ವ್ಯವಸ್ಥೆಯು ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು:
- ಡೆವಲಪರ್‌ಗಳು ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ (ಇದು ನಿರ್ಣಾಯಕ ಹಂತವಾಗಿದೆ - ಇಲ್ಲದಿದ್ದರೆ ನಮಗೆ ಯಾವುದೇ ಮೌಲ್ಯಮಾಪನ ಮಾನದಂಡವಿಲ್ಲ - ಇದು ಯಂತ್ರ ಕಲಿಕೆಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಲೇಬಲ್ ಮಾಡುವಂತಿದೆ).
- ಪ್ರತಿಯೊಂದು ಘಟಕವು (ಪ್ರಾಜೆಕ್ಟ್) ತನ್ನದೇ ಆದ CI ವ್ಯವಸ್ಥೆಯನ್ನು ಪಡೆಯುತ್ತದೆ - ಈ ಪ್ರಕ್ರಿಯೆಯು ಈಗ ಉತ್ತಮವಾಗಿ ಅಭಿವೃದ್ಧಿಗೊಂಡಿದೆ ಮತ್ತು ಒಂದು ಘಟಕಕ್ಕಾಗಿ CI ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಹೆಚ್ಚಾಗಿ ಪರಿಹರಿಸಲಾಗಿದೆ
- "ಸ್ಮಾರ್ಟ್ ಇಂಟಿಗ್ರೇಷನ್ ಸಿಸ್ಟಮ್" ವಿವಿಧ CI ಸಿಸ್ಟಮ್‌ಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಘಟಕ ಯೋಜನೆಗಳನ್ನು ಅಂತಿಮ ಉತ್ಪನ್ನಕ್ಕೆ ಜೋಡಿಸುತ್ತದೆ, ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಘಟಕಗಳು ಮತ್ತು ಅಪಾಯದ ಅಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಅಪೇಕ್ಷಿತ ಉತ್ಪನ್ನ ಕಾರ್ಯವನ್ನು ಪಡೆಯಲು ಕಡಿಮೆ ಮಾರ್ಗವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ನವೀಕರಣವು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಈ ವ್ಯವಸ್ಥೆಯು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಘಟಕಗಳ ಬಗ್ಗೆ ತಿಳಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದು ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಮತ್ತೊಮ್ಮೆ, ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಯು ಇಲ್ಲಿ ನಿರ್ಣಾಯಕ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿದೆ - ಏಕೀಕರಣ ವ್ಯವಸ್ಥೆಯು ಪರೀಕ್ಷೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾನದಂಡವಾಗಿ ಬಳಸುವುದರಿಂದ.
- ಸಿಡಿ ಸಿಸ್ಟಮ್, ಇದು ನಂತರ ಸ್ಮಾರ್ಟ್ ಇಂಟಿಗ್ರೇಷನ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ನೇರವಾಗಿ ನವೀಕರಣವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ಹಂತವು ಚಕ್ರವನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ನನಗೆ ಈಗ ಒಂದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯೆಂದರೆ ಅಂತಹ "ಸ್ಮಾರ್ಟ್ ಇಂಟಿಗ್ರೇಷನ್ ಸಿಸ್ಟಮ್" ಕೊರತೆಯಾಗಿದ್ದು ಅದು ಉತ್ಪನ್ನಕ್ಕೆ ವಿವಿಧ ಘಟಕಗಳನ್ನು ಲಿಂಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ಉತ್ಪನ್ನವನ್ನು ಹೇಗೆ ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಕುರಿತು ಸಮುದಾಯದ ಆಲೋಚನೆಗಳಲ್ಲಿ ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ (ಸ್ಪಾಯ್ಲರ್ - ನಾನು ಪ್ರಸ್ತುತ ಯೋಜನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ , ಇದು ಅಂತಹ ಸ್ಮಾರ್ಟ್ ಏಕೀಕರಣ ವ್ಯವಸ್ಥೆಯಾಗಬಹುದು).
ನಾನು ನಮೂದಿಸಲು ಬಯಸುವ ಕೊನೆಯ ವಿಷಯವೆಂದರೆ, ನನಗೆ, ಮಧ್ಯಮ ಗಾತ್ರದ ಯಾವುದೇ ಯೋಜನೆಗೆ ಏಕಶಿಲೆಯು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ. ನನಗೆ, ಏಕಶಿಲೆಗೆ ಹಿಂದಿರುಗುವ ಮೂಲಕ ಅನುಷ್ಠಾನದ ಸಮಯ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಗುಣಮಟ್ಟವನ್ನು ವೇಗಗೊಳಿಸುವ ಪ್ರಯತ್ನಗಳು ದೊಡ್ಡ ಸಂದೇಹವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಮೊದಲನೆಯದಾಗಿ, ಏಕಶಿಲೆಯು ಘಟಕಗಳನ್ನು ನಿರ್ವಹಿಸುವಲ್ಲಿ ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ - ಅದು ಒಳಗೊಂಡಿರುವ ವಿವಿಧ ಗ್ರಂಥಾಲಯಗಳಲ್ಲಿ, ಆದಾಗ್ಯೂ, ಇದೆಲ್ಲವೂ ಅಷ್ಟೊಂದು ಗಮನಿಸುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರಾಥಮಿಕವಾಗಿ ಡೆವಲಪರ್‌ಗಳು ಕಳೆದ ಸಮಯದಲ್ಲಿ ಸ್ವತಃ ಪ್ರಕಟವಾಗುತ್ತದೆ. ಏಕಶಿಲೆಯ ಸಮಸ್ಯೆಯ ಪರಿಣಾಮವೆಂದರೆ ಕೋಡ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ವಾಸ್ತವ ಅಸಾಧ್ಯತೆ - ಮತ್ತು ಅತ್ಯಂತ ನಿಧಾನಗತಿಯ ಅಭಿವೃದ್ಧಿ ವೇಗ.
ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು ಪರಿಸ್ಥಿತಿಯನ್ನು ಸುಧಾರಿಸುತ್ತವೆ, ಆದರೆ ನಂತರ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಏಕೀಕರಣ ಹಂತದಲ್ಲಿ ಸಂಯೋಜಿತ ಸ್ಫೋಟದ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತದೆ. ಹೌದು, ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಅಭಿವೃದ್ಧಿ ಹಂತದಿಂದ ಏಕೀಕರಣ ಹಂತಕ್ಕೆ ಸ್ಥಳಾಂತರಿಸಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಮೈಕ್ರೊ ಸರ್ವೀಸ್ ವಿಧಾನವು ಇನ್ನೂ ಉತ್ತಮ ಫಲಿತಾಂಶಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ತಂಡಗಳು ಫಲಿತಾಂಶಗಳನ್ನು ವೇಗವಾಗಿ ಸಾಧಿಸುತ್ತವೆ (ಬಹುಶಃ ಮುಖ್ಯವಾಗಿ ಅಭಿವೃದ್ಧಿ ಘಟಕದ ಗಾತ್ರದಲ್ಲಿನ ಕಡಿತದಿಂದಾಗಿ - ಅಥವಾ ಬ್ಯಾಚ್ ಗಾತ್ರ) ಆದಾಗ್ಯೂ, ಏಕಶಿಲೆಯಿಂದ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗೆ ಚಲಿಸುವಿಕೆಯು ಇನ್ನೂ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಾಕಷ್ಟು ಸುಧಾರಿಸಿಲ್ಲ - ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಆವೃತ್ತಿಗಳ ಸಂಯೋಜಿತ ಸ್ಫೋಟವು ಒಂದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿದೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಪರಿಹರಿಸುವಾಗ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸುಧಾರಿಸಲು ನಮಗೆ ಸಾಕಷ್ಟು ಸಾಮರ್ಥ್ಯವಿದೆ.
ಮೂಲ: www.habr.com