ನಿರೀಕ್ಷೆಯಲ್ಲಿ ವಿಟಾಲಿ ಖಬರೋವ್ ಸಂದರ್ಶಿಸಿದರು ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್ (), ತಾಂತ್ರಿಕ ನಿರ್ದೇಶಕ ಮತ್ತು ಫ್ಲಾಂಟ್ ಕಂಪನಿಯ ಸಹ-ಸಂಸ್ಥಾಪಕ. ಫ್ಲಾಂಟ್ ಏನು ಮಾಡುತ್ತಾನೆ, ಕುಬರ್ನೆಟ್ಸ್, ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿ, ಬೆಂಬಲದ ಬಗ್ಗೆ ವಿಟಾಲಿ ಡಿಮಿಟ್ರಿಯನ್ನು ಕೇಳಿದರು. ಕುಬರ್ನೆಟ್ಸ್ ಏಕೆ ಬೇಕು ಮತ್ತು ಅದು ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ನಾವು ಚರ್ಚಿಸಿದ್ದೇವೆ. ಮತ್ತು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಬಗ್ಗೆ, Amazon AWS, DevOps ಗೆ “ನಾನು ಅದೃಷ್ಟಶಾಲಿಯಾಗುತ್ತೇನೆ” ವಿಧಾನ, ಕುಬರ್ನೆಟ್ಸ್ನ ಭವಿಷ್ಯ, ಏಕೆ, ಯಾವಾಗ ಮತ್ತು ಹೇಗೆ ಅದು ಜಗತ್ತನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, DevOps ನ ನಿರೀಕ್ಷೆಗಳು ಮತ್ತು ಎಂಜಿನಿಯರ್‌ಗಳು ಏನನ್ನು ಸಿದ್ಧಪಡಿಸಬೇಕು ಸರಳೀಕರಣ ಮತ್ತು ನರ ಜಾಲಗಳೊಂದಿಗೆ ಪ್ರಕಾಶಮಾನವಾದ ಮತ್ತು ಮುಂದಿನ ಭವಿಷ್ಯ.
DevOps Deflop ನಲ್ಲಿ ಪಾಡ್‌ಕ್ಯಾಸ್ಟ್ ಆಗಿ ಆಲಿಸಿ - DevOps ಕುರಿತು ರಷ್ಯನ್ ಭಾಷೆಯ ಪಾಡ್‌ಕ್ಯಾಸ್ಟ್, ಮತ್ತು ಕೆಳಗೆ ಪಠ್ಯ ಆವೃತ್ತಿಯಾಗಿದೆ.
ಇಲ್ಲಿ ಮತ್ತು ಕೆಳಗೆ ಅವರು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಾರೆ ಎಕ್ಸ್‌ಪ್ರೆಸ್ 42 ಇಂಜಿನಿಯರ್.
"ಫ್ಲಾಂಟ್" ಬಗ್ಗೆ
- ಹಲೋ ಡಿಮಾ. ನೀವು ತಾಂತ್ರಿಕ ನಿರ್ದೇಶಕರು""ಮತ್ತು ಅದರ ಸ್ಥಾಪಕ ಕೂಡ. ದಯವಿಟ್ಟು ಕಂಪನಿಯು ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದರಲ್ಲಿ ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ನಮಗೆ ತಿಳಿಸಿ?
ಡಿಮಿಟ್ರಿ: ಹೊರಗಿನಿಂದ ನೋಡಿದರೆ ನಾವು ಎಲ್ಲರಿಗೂ ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ಮತ್ತು ಅದರೊಂದಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡುವ ಹುಡುಗರಂತೆ ತೋರುತ್ತದೆ. ಆದರೆ ಅದು ನಿಜವಲ್ಲ. ನಾವು ಲಿನಕ್ಸ್‌ನೊಂದಿಗೆ ವ್ಯವಹರಿಸುವ ಕಂಪನಿಯಾಗಿ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಆದರೆ ಬಹಳ ಸಮಯದಿಂದ ನಮ್ಮ ಮುಖ್ಯ ಚಟುವಟಿಕೆಯು ಉತ್ಪಾದನೆ ಮತ್ತು ಹೆಚ್ಚಿನ-ಲೋಡ್ ಟರ್ನ್ಕೀ ಯೋಜನೆಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ ನಾವು ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯವನ್ನು ಮೊದಲಿನಿಂದ ನಿರ್ಮಿಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ದೀರ್ಘ, ದೀರ್ಘಕಾಲದವರೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತೇವೆ. ಆದ್ದರಿಂದ, "ಫ್ಲಾಂಟ್" ಮಾಡುವ ಮುಖ್ಯ ಕೆಲಸ, ಅದಕ್ಕಾಗಿ ಅದು ಹಣವನ್ನು ಪಡೆಯುತ್ತದೆ ಜವಾಬ್ದಾರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಮತ್ತು ಟರ್ನ್ಕೀ ಉತ್ಪಾದನೆಯನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು.
ನಾನು, ತಾಂತ್ರಿಕ ನಿರ್ದೇಶಕ ಮತ್ತು ಕಂಪನಿಯ ಸಂಸ್ಥಾಪಕರಲ್ಲಿ ಒಬ್ಬನಾಗಿ, ಉತ್ಪಾದನೆಯ ಪ್ರವೇಶವನ್ನು ಹೇಗೆ ಹೆಚ್ಚಿಸುವುದು, ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸರಳಗೊಳಿಸುವುದು, ನಿರ್ವಾಹಕರ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸುವುದು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳ ಜೀವನವನ್ನು ಹೆಚ್ಚು ಆಹ್ಲಾದಕರಗೊಳಿಸುವುದು ಹೇಗೆ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಹಗಲು ರಾತ್ರಿ ಕಳೆಯುತ್ತೇನೆ. .
ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ
- ಇತ್ತೀಚೆಗೆ ನಾನು ಫ್ಲಾಂಟ್‌ನಿಂದ ಸಾಕಷ್ಟು ವರದಿಗಳನ್ನು ನೋಡುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ. ನೀವು ಅದಕ್ಕೆ ಹೇಗೆ ಬಂದಿದ್ದೀರಿ?
ಡಿಮಿಟ್ರಿ: ನಾನು ಈಗಾಗಲೇ ಈ ಬಗ್ಗೆ ಹಲವು ಬಾರಿ ಮಾತನಾಡಿದ್ದೇನೆ, ಆದರೆ ಅದನ್ನು ಪುನರಾವರ್ತಿಸಲು ನನಗೆ ಮನಸ್ಸಿಲ್ಲ. ಕಾರಣ ಮತ್ತು ಪರಿಣಾಮದ ನಡುವೆ ಗೊಂದಲ ಇರುವುದರಿಂದ ಈ ವಿಷಯವನ್ನು ಪುನರಾವರ್ತಿಸುವುದು ಸರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ನಮಗೆ ನಿಜವಾಗಿಯೂ ಒಂದು ಉಪಕರಣ ಬೇಕಿತ್ತು. ನಾವು ಸಾಕಷ್ಟು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ, ಹೋರಾಡಿದ್ದೇವೆ, ಅವುಗಳನ್ನು ವಿವಿಧ ಊರುಗೋಲುಗಳಿಂದ ನಿವಾರಿಸಿದ್ದೇವೆ ಮತ್ತು ಸಾಧನದ ಅಗತ್ಯವಿದೆ ಎಂದು ಭಾವಿಸಿದ್ದೇವೆ. ನಾವು ಹಲವಾರು ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳ ಮೂಲಕ ಹೋದೆವು, ನಮ್ಮ ಸ್ವಂತ ಬೈಕುಗಳನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ ಮತ್ತು ಅನುಭವವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಕ್ರಮೇಣ ನಾವು ಡಾಕರ್ ಕಾಣಿಸಿಕೊಂಡ ತಕ್ಷಣ ಅದನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುವ ಹಂತಕ್ಕೆ ಬಂದೆವು - 2013 ರ ಸುಮಾರಿಗೆ. ಅದರ ಗೋಚರಿಸುವಿಕೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು ಈಗಾಗಲೇ ಕಂಟೇನರ್‌ಗಳೊಂದಿಗೆ ಸಾಕಷ್ಟು ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಈಗಾಗಲೇ “ಡಾಕರ್” ನ ಅನಲಾಗ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ - ಪೈಥಾನ್‌ನಲ್ಲಿ ನಮ್ಮದೇ ಆದ ಕೆಲವು ಊರುಗೋಲುಗಳು. ಡಾಕರ್ ಆಗಮನದೊಂದಿಗೆ, ಊರುಗೋಲನ್ನು ಹೊರಹಾಕಲು ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸಮುದಾಯ-ಬೆಂಬಲಿತ ಪರಿಹಾರವನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಯಿತು.
ಕುಬರ್ನೆಟ್ಸ್ ಕಥೆಯು ಹೋಲುತ್ತದೆ. ಇದು ವೇಗವನ್ನು ಪಡೆಯಲು ಪ್ರಾರಂಭಿಸುವ ಹೊತ್ತಿಗೆ - ನಮಗೆ ಇದು ಆವೃತ್ತಿ 1.2 - ನಾವು ಈಗಾಗಲೇ ಶೆಲ್ ಮತ್ತು ಚೆಫ್ ಎರಡರಲ್ಲೂ ಊರುಗೋಲುಗಳ ಗುಂಪನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಹೇಗಾದರೂ ಡಾಕರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ನಾವು ರಾಂಚರ್ ಮತ್ತು ಇತರ ಹಲವಾರು ಪರಿಹಾರಗಳ ಕಡೆಗೆ ಗಂಭೀರವಾಗಿ ನೋಡುತ್ತಿದ್ದೆವು, ಆದರೆ ನಂತರ ಕುಬರ್ನೆಟ್ಸ್ ಕಾಣಿಸಿಕೊಂಡರು, ಇದರಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ನಾವು ಮಾಡಿದಂತೆಯೇ ಅಥವಾ ಇನ್ನೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ದೂರು ನೀಡಲು ಏನೂ ಇಲ್ಲ.
ಹೌದು, ಇಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಅಪೂರ್ಣತೆ ಇದೆ, ಅಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಅಪೂರ್ಣತೆ ಇದೆ - ಬಹಳಷ್ಟು ಅಪೂರ್ಣತೆಗಳಿವೆ, ಮತ್ತು 1.2 ಸಾಮಾನ್ಯವಾಗಿ ಭಯಾನಕವಾಗಿದೆ, ಆದರೆ... ಕುಬರ್ನೆಟ್ಸ್ ನಿರ್ಮಾಣ ಹಂತದಲ್ಲಿರುವ ಕಟ್ಟಡದಂತಿದೆ - ನೀವು ಯೋಜನೆಯನ್ನು ನೋಡಿ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ ಅದು ತಂಪಾಗಿರುತ್ತದೆ ಎಂದು. ಕಟ್ಟಡವು ಈಗ ಅಡಿಪಾಯ ಮತ್ತು ಎರಡು ಮಹಡಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಇನ್ನೂ ಚಲಿಸದಿರುವುದು ಉತ್ತಮ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ, ಆದರೆ ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ ಅಂತಹ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ - ನೀವು ಈಗಾಗಲೇ ಅದನ್ನು ಬಳಸಬಹುದು.
ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸುತ್ತೇವೋ ಇಲ್ಲವೋ ಎಂದು ಯೋಚಿಸುವ ಕ್ಷಣವೂ ನಮಗೆ ಇರಲಿಲ್ಲ. ಅದು ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ನಾವು ಅದನ್ನು ಕಾಯುತ್ತಿದ್ದೆವು ಮತ್ತು ಸಾದೃಶ್ಯಗಳನ್ನು ನಾವೇ ರಚಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ
- ನೀವು ನೇರವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದೀರಾ?
ಡಿಮಿಟ್ರಿ: ಸಾಧಾರಣ. ಬದಲಿಗೆ, ನಾವು ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಭಾಗವಹಿಸುತ್ತೇವೆ. ನಾವು ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಪುಲ್ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ: ಪ್ರಮೀತಿಯಸ್ಗೆ, ವಿವಿಧ ನಿರ್ವಾಹಕರಿಗೆ, ಹೆಲ್ಮ್ಗೆ - ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ. ದುರದೃಷ್ಟವಶಾತ್, ನಾವು ಮಾಡುವ ಎಲ್ಲದರ ಬಗ್ಗೆ ನಿಗಾ ಇಡಲು ನನಗೆ ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ ಮತ್ತು ನಾನು ತಪ್ಪಾಗಿರಬಹುದು, ಆದರೆ ನಮ್ಮಿಂದ ಒಂದೇ ಒಂದು ಪೂಲ್ ಇಲ್ಲ.
— ಅದೇ ಸಮಯದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಸುತ್ತಲೂ ನಿಮ್ಮ ಅನೇಕ ಸಾಧನಗಳನ್ನು ನೀವು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೀರಾ?
ಡಿಮಿಟ್ರಿ: ತಂತ್ರ ಇದು: ನಾವು ಹೋಗಿ ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲದಕ್ಕೂ ವಿನಂತಿಗಳನ್ನು ಎಳೆಯಿರಿ. ಪುಲ್ ವಿನಂತಿಗಳನ್ನು ಅಲ್ಲಿ ಸ್ವೀಕರಿಸದಿದ್ದರೆ, ನಾವು ಅವುಗಳನ್ನು ನಾವೇ ಫೋರ್ಕ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ನಿರ್ಮಾಣಗಳೊಂದಿಗೆ ಅವುಗಳನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ ಬದುಕುತ್ತೇವೆ. ನಂತರ, ಅದು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಅನ್ನು ತಲುಪಿದಾಗ, ನಾವು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ.
ಉದಾಹರಣೆಗೆ, ನಾವು ಪ್ರೊಮೆಥಿಯಸ್ ಆಪರೇಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದರೊಂದಿಗೆ ನಾವು ನಮ್ಮ ಅಸೆಂಬ್ಲಿಯ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ಬಹುಶಃ 5 ಬಾರಿ ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ನಮಗೆ ಕೆಲವು ರೀತಿಯ ವೈಶಿಷ್ಟ್ಯದ ಅಗತ್ಯವಿದೆ, ನಾವು ಪುಲ್ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದ್ದೇವೆ, ನಾವು ಅದನ್ನು ನಾಳೆ ರೋಲ್ ಮಾಡಬೇಕಾಗಿದೆ, ಆದರೆ ಅದನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಲು ನಾವು ಕಾಯಲು ಬಯಸುವುದಿಲ್ಲ. ಅಂತೆಯೇ, ನಾವು ನಮಗಾಗಿ ಜೋಡಿಸುತ್ತೇವೆ, ನಮ್ಮ ವೈಶಿಷ್ಟ್ಯದೊಂದಿಗೆ ನಮ್ಮ ಅಸೆಂಬ್ಲಿಯನ್ನು ಸುತ್ತಿಕೊಳ್ಳುತ್ತೇವೆ, ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ. ನಂತರ, ಉದಾಹರಣೆಗೆ, ಅವರು ಅದನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಈ ಪದಗಳೊಂದಿಗೆ ನಮಗೆ ತಿರುಗಿಸುತ್ತಾರೆ: “ಗೈಸ್, ಇದನ್ನು ಹೆಚ್ಚು ಸಾಮಾನ್ಯ ಪ್ರಕರಣಕ್ಕಾಗಿ ಮಾಡೋಣ,” ನಾವು ಅಥವಾ ಬೇರೊಬ್ಬರು ಅದನ್ನು ಮುಗಿಸಿ, ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ಅದು ಮತ್ತೆ ವಿಲೀನಗೊಳ್ಳುತ್ತದೆ.
ನಾವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲವನ್ನೂ ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಇನ್ನೂ ಆವಿಷ್ಕರಿಸಲಾಗಿಲ್ಲ, ಅಥವಾ ಆವಿಷ್ಕರಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಮಯವಿಲ್ಲ - ನಾವು ಅದನ್ನು ಮಾಡುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಬೈಸಿಕಲ್ ನಿರ್ಮಾಣವನ್ನು ಉದ್ಯಮವಾಗಿ ಇಷ್ಟಪಡುವ ಕಾರಣದಿಂದಲ್ಲ, ಆದರೆ ನಮಗೆ ಈ ಉಪಕರಣದ ಅಗತ್ಯವಿರುವುದರಿಂದ. ನಾವು ಇದನ್ನು ಅಥವಾ ಆ ಕೆಲಸವನ್ನು ಏಕೆ ಮಾಡಿದ್ದೇವೆ ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ಹೆಚ್ಚಾಗಿ ಕೇಳಲಾಗುತ್ತದೆ. ಉತ್ತರ ಸರಳವಾಗಿದೆ - ಹೌದು, ಏಕೆಂದರೆ ನಾವು ಮುಂದೆ ಹೋಗಬೇಕಾಗಿತ್ತು, ಕೆಲವು ಪ್ರಾಯೋಗಿಕ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬೇಕು ಮತ್ತು ನಾವು ಅದನ್ನು ಈ ತುಲಾದೊಂದಿಗೆ ಪರಿಹರಿಸಿದ್ದೇವೆ.
ಮಾರ್ಗವು ಯಾವಾಗಲೂ ಹೀಗಿರುತ್ತದೆ: ನಾವು ಬಹಳ ಎಚ್ಚರಿಕೆಯಿಂದ ಹುಡುಕುತ್ತೇವೆ ಮತ್ತು ಬ್ರೆಡ್ ತುಂಡುಗಳಿಂದ ಟ್ರಾಲಿಬಸ್ ಅನ್ನು ಹೇಗೆ ತಯಾರಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ನಾವು ಯಾವುದೇ ಪರಿಹಾರವನ್ನು ಕಂಡುಹಿಡಿಯದಿದ್ದರೆ, ನಾವು ನಮ್ಮ ಸ್ವಂತ ಲೋಫ್ ಮತ್ತು ನಮ್ಮ ಸ್ವಂತ ಟ್ರಾಲಿಬಸ್ ಅನ್ನು ತಯಾರಿಸುತ್ತೇವೆ.
ಫ್ಲಾಂಟಾ ಉಪಕರಣಗಳು
— Flant ಈಗ addon ಆಪರೇಟರ್‌ಗಳು, ಶೆಲ್ ಆಪರೇಟರ್‌ಗಳು ಮತ್ತು dapp/werf ಟೂಲ್‌ಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ. ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಇದು ವಿಭಿನ್ನ ಅವತಾರಗಳಲ್ಲಿ ಒಂದೇ ಸಾಧನವಾಗಿದೆ. ಫ್ಲೌಂಟ್‌ನಲ್ಲಿ ಇನ್ನೂ ಹಲವು ವಿಭಿನ್ನ ಸಾಧನಗಳಿವೆ ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಇದು ಸತ್ಯ?
ಡಿಮಿಟ್ರಿ: ನಾವು GitHub ನಲ್ಲಿ ಹೆಚ್ಚಿನದನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನನಗೆ ಈಗ ನೆನಪಿರುವಂತೆ, ನಮ್ಮ ಬಳಿ ಸ್ಟೇಟಸ್‌ಮ್ಯಾಪ್ ಇದೆ - ಪ್ರತಿಯೊಬ್ಬರೂ ಇಷ್ಟಪಟ್ಟಿರುವ ಗ್ರಾಫನಾ ಫಲಕ. ಕುಬರ್ನೆಟ್ಸ್ ಮಾನಿಟರಿಂಗ್ ಮಾಧ್ಯಮದ ಬಗ್ಗೆ ಪ್ರತಿ ಎರಡನೇ ಲೇಖನದಲ್ಲಿ ಇದನ್ನು ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ. ಸ್ಥಿತಿ ನಕ್ಷೆ ಎಂದರೇನು ಎಂಬುದನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸುವುದು ಅಸಾಧ್ಯ - ಇದಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಲೇಖನದ ಅಗತ್ಯವಿದೆ, ಆದರೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಇದು ತುಂಬಾ ಉಪಯುಕ್ತ ವಿಷಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಾವು ಆಗಾಗ್ಗೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸಬೇಕಾಗುತ್ತದೆ. ನಮ್ಮಲ್ಲಿ ಲಾಗ್‌ಹೌಸ್ ಕೂಡ ಇದೆ - ಇದು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಕ್ಲಿಕ್‌ಹೌಸ್ ಮತ್ತು ಬ್ಲ್ಯಾಕ್ ಮ್ಯಾಜಿಕ್ ಅನ್ನು ಆಧರಿಸಿದ ವಿಷಯವಾಗಿದೆ.
ಬಹಳಷ್ಟು ಉಪಯುಕ್ತತೆಗಳು! ಮತ್ತು ಇನ್ನೂ ಹೆಚ್ಚಿನವು ಇರುತ್ತದೆ, ಏಕೆಂದರೆ ಈ ವರ್ಷ ಹಲವಾರು ಆಂತರಿಕ ಪರಿಹಾರಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗುವುದು. ಆಡ್ಆನ್ ಆಪರೇಟರ್ ಅನ್ನು ಆಧರಿಸಿದ ದೊಡ್ಡದಾದವುಗಳಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಹಲವಾರು ಆಡ್ಆನ್‌ಗಳಿವೆ, ಸೆರ್ಟ್ ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಸರಿಯಾಗಿ ಸ್ಥಾಪಿಸುವುದು ಹೇಗೆ - ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಾಧನ, ಪರಿಕರಗಳ ಗುಂಪಿನೊಂದಿಗೆ ಪ್ರಮೀತಿಯಸ್ ಅನ್ನು ಸರಿಯಾಗಿ ಸ್ಥಾಪಿಸುವುದು ಹೇಗೆ - ಇವು ಸುಮಾರು ಇಪ್ಪತ್ತು ವಿಭಿನ್ನವಾಗಿವೆ. ಡೇಟಾವನ್ನು ರಫ್ತು ಮಾಡುವ ಮತ್ತು ಏನನ್ನಾದರೂ ಸಂಗ್ರಹಿಸುವ ಬೈನರಿಗಳು, ಈ ಪ್ರಮೀತಿಯಸ್ಗೆ ಅತ್ಯಂತ ಅದ್ಭುತವಾದ ಗ್ರಾಫಿಕ್ಸ್ ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹೊಂದಿದೆ. ಇದೆಲ್ಲವೂ ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಆಡ್ಆನ್‌ಗಳ ಗುಂಪಾಗಿದೆ, ಇವುಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಮತ್ತು ಇದು ಸರಳದಿಂದ ತಂಪಾಗಿರುವ, ಅತ್ಯಾಧುನಿಕ, ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತಿರುಗುತ್ತದೆ, ಇದರಲ್ಲಿ ಈಗಾಗಲೇ ಅನೇಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ. ಹೌದು, ನಾವು ಬಹಳಷ್ಟು ಮಾಡುತ್ತೇವೆ.
ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿ
"ಈ ಉಪಕರಣದ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಅದರ ಬಳಕೆಯ ವಿಧಾನಗಳಿಗೆ ಇದು ಬಹಳ ದೊಡ್ಡ ಕೊಡುಗೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ." ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿಗೆ ಅದೇ ಕೊಡುಗೆಯನ್ನು ಬೇರೆ ಯಾರು ನೀಡುತ್ತಾರೆ ಎಂದು ನೀವು ಅಂದಾಜು ಮಾಡಬಹುದೇ?
ಡಿಮಿಟ್ರಿ: ರಷ್ಯಾದಲ್ಲಿ, ನಮ್ಮ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕಂಪನಿಗಳಲ್ಲಿ, ಯಾರೂ ಸಹ ಹತ್ತಿರದಲ್ಲಿಲ್ಲ. ಸಹಜವಾಗಿ, ಇದು ದೊಡ್ಡ ಹೇಳಿಕೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಮೇಲ್ ಮತ್ತು ಯಾಂಡೆಕ್ಸ್‌ನಂತಹ ಪ್ರಮುಖ ಆಟಗಾರರು ಇದ್ದಾರೆ - ಅವರು ಕುಬರ್ನೆಟ್‌ಗಳೊಂದಿಗೆ ಏನಾದರೂ ಮಾಡುತ್ತಿದ್ದಾರೆ, ಆದರೆ ಅವರು ನಮಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಮಾಡುವ ಇಡೀ ವಿಶ್ವದ ಕಂಪನಿಗಳ ಕೊಡುಗೆಗೆ ಹತ್ತಿರವಾಗುವುದಿಲ್ಲ. 80 ಜನರ ಸಿಬ್ಬಂದಿಯನ್ನು ಹೊಂದಿರುವ ಫ್ಲಾಂಟ್ ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ 300 ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ರೆಡ್ ಹ್ಯಾಟ್ ಅನ್ನು ಹೋಲಿಸುವುದು ಕಷ್ಟ, ನಾನು ತಪ್ಪಾಗಿ ಭಾವಿಸದಿದ್ದರೆ. ಹೋಲಿಸುವುದು ಕಷ್ಟ. ನಾನು ಸೇರಿದಂತೆ RnD ಇಲಾಖೆಯಲ್ಲಿ 6 ಜನರಿದ್ದೇವೆ, ಅವರು ನಮ್ಮ ಎಲ್ಲಾ ಉಪಕರಣಗಳನ್ನು ಕತ್ತರಿಸಿದ್ದಾರೆ. 6 ಜನರು ವಿರುದ್ಧ 300 Red Hat ಇಂಜಿನಿಯರ್‌ಗಳು - ಹೋಲಿಸುವುದು ಹೇಗಾದರೂ ಕಷ್ಟ.
- ಆದಾಗ್ಯೂ, ಈ 6 ಜನರು ಸಹ ನಿಜವಾಗಿಯೂ ಉಪಯುಕ್ತವಾದ ಮತ್ತು ದೂರವಾಗುವಂತಹದ್ದನ್ನು ಮಾಡಬಹುದಾದಾಗ, ಅವರು ಪ್ರಾಯೋಗಿಕ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದಾಗ ಮತ್ತು ಸಮುದಾಯಕ್ಕೆ ಪರಿಹಾರವನ್ನು ನೀಡಿದಾಗ - ಆಸಕ್ತಿದಾಯಕ ಪ್ರಕರಣ. ದೊಡ್ಡ ತಂತ್ರಜ್ಞಾನ ಕಂಪನಿಗಳಲ್ಲಿ, ಅವರು ತಮ್ಮದೇ ಆದ ಕುಬರ್ನೆಟ್ಸ್ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಬೆಂಬಲ ತಂಡವನ್ನು ಹೊಂದಿರುವಲ್ಲಿ, ತಾತ್ವಿಕವಾಗಿ, ಅದೇ ಸಾಧನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸುವ ಇಡೀ ಸಮುದಾಯಕ್ಕೆ ಪ್ರಚೋದನೆಯನ್ನು ನೀಡುವ ಮೂಲಕ ಸಮುದಾಯಕ್ಕೆ ಏನನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು ಮತ್ತು ನೀಡಬಹುದು ಎಂಬುದಕ್ಕೆ ಇದು ಅವರಿಗೆ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ.
ಡಿಮಿಟ್ರಿ: ಇದು ಬಹುಶಃ ಇಂಟಿಗ್ರೇಟರ್ನ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ, ಅದರ ವಿಶಿಷ್ಟತೆ. ನಾವು ಅನೇಕ ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಹಲವಾರು ವಿಭಿನ್ನ ಸಂದರ್ಭಗಳನ್ನು ನೋಡುತ್ತೇವೆ. ನಮಗೆ, ಹೆಚ್ಚುವರಿ ಮೌಲ್ಯವನ್ನು ರಚಿಸುವ ಮುಖ್ಯ ಮಾರ್ಗವೆಂದರೆ ಈ ಪ್ರಕರಣಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವುದು, ಸಾಮಾನ್ಯತೆಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ನಮಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಅಗ್ಗವಾಗಿಸುವುದು. ನಾವು ಈ ನಿಟ್ಟಿನಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ. ರಷ್ಯಾ ಮತ್ತು ಪ್ರಪಂಚದ ಬಗ್ಗೆ ಮಾತನಾಡುವುದು ನನಗೆ ಕಷ್ಟ, ಆದರೆ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಕಂಪನಿಯಲ್ಲಿ ಸುಮಾರು 40 DevOps ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ತುಲನಾತ್ಮಕ ಸಂಖ್ಯೆಯ ತಜ್ಞರೊಂದಿಗೆ ರಷ್ಯಾದಲ್ಲಿ ಅನೇಕ ಕಂಪನಿಗಳಿವೆ ಎಂದು ನಾನು ಭಾವಿಸುವುದಿಲ್ಲ.
ನಾನು DevOps ಇಂಜಿನಿಯರ್ ಹುದ್ದೆಯ ಬಗ್ಗೆ ಎಲ್ಲವನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಎಲ್ಲವನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು DevOps ಇಂಜಿನಿಯರ್‌ಗಳನ್ನು DevOps ಇಂಜಿನಿಯರ್‌ಗಳು ಎಂದು ಕರೆಯಲು ಬಳಸಲಾಗುತ್ತದೆ, ನಾವು ಇದನ್ನು ಚರ್ಚಿಸುವುದಿಲ್ಲ. ಈ ಎಲ್ಲಾ 40 ಅದ್ಭುತ DevOps ಎಂಜಿನಿಯರ್‌ಗಳು ಪ್ರತಿದಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಾರೆ ಮತ್ತು ಪರಿಹರಿಸುತ್ತಾರೆ, ನಾವು ಈ ಅನುಭವವನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ ಮತ್ತು ಸಾಮಾನ್ಯೀಕರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಅದು ನಮ್ಮೊಳಗೆ ಉಳಿದಿದ್ದರೆ, ಒಂದು ಅಥವಾ ಎರಡು ವರ್ಷಗಳಲ್ಲಿ ಉಪಕರಣವು ನಿಷ್ಪ್ರಯೋಜಕವಾಗುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಸಮುದಾಯದಲ್ಲಿ ಎಲ್ಲೋ ಸಿದ್ಧವಾದ ತುಲಾ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಈ ಅನುಭವವನ್ನು ಆಂತರಿಕವಾಗಿ ಸಂಗ್ರಹಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ - ಇದು ಕೇವಲ ಶಕ್ತಿ ಮತ್ತು ಸಮಯವನ್ನು dev/null ಆಗಿ ಹರಿಸುತ್ತಿದೆ. ಮತ್ತು ನಾವು ಅದರ ಬಗ್ಗೆ ವಿಷಾದಿಸುವುದಿಲ್ಲ. ನಾವು ಎಲ್ಲವನ್ನೂ ಬಹಳ ಸಂತೋಷದಿಂದ ಪ್ರಕಟಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಪ್ರಕಟಿಸಬೇಕು, ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕು, ಪ್ರಚಾರ ಮಾಡಬೇಕು, ಪ್ರಚಾರ ಮಾಡಬೇಕು ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ, ಇದರಿಂದ ಜನರು ಅದನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಅವರ ಅನುಭವವನ್ನು ಸೇರಿಸುತ್ತಾರೆ - ನಂತರ ಎಲ್ಲವೂ ಬೆಳೆಯುತ್ತದೆ ಮತ್ತು ಜೀವಿಸುತ್ತದೆ. ನಂತರ ಎರಡು ವರ್ಷಗಳ ನಂತರ ಉಪಕರಣವು ಕಸದ ಬುಟ್ಟಿಗೆ ಹೋಗುವುದಿಲ್ಲ. ಶಕ್ತಿಯನ್ನು ಸುರಿಯುವುದನ್ನು ಮುಂದುವರಿಸಲು ಇದು ಕರುಣೆ ಅಲ್ಲ, ಏಕೆಂದರೆ ಯಾರಾದರೂ ನಿಮ್ಮ ಉಪಕರಣವನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ಎರಡು ವರ್ಷಗಳ ನಂತರ ಪ್ರತಿಯೊಬ್ಬರೂ ಅದನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ.
ಇದು dapp/werf ನೊಂದಿಗೆ ನಮ್ಮ ದೊಡ್ಡ ಕಾರ್ಯತಂತ್ರದ ಭಾಗವಾಗಿದೆ. ನಾವು ಅದನ್ನು ತಯಾರಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ನನಗೆ ನೆನಪಿಲ್ಲ, ಅದು 3 ವರ್ಷಗಳ ಹಿಂದೆ ತೋರುತ್ತದೆ. ಆರಂಭದಲ್ಲಿ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಶೆಲ್ನಲ್ಲಿತ್ತು. ಇದು ಪರಿಕಲ್ಪನೆಯ ಸೂಪರ್ ಪುರಾವೆಯಾಗಿದೆ, ನಮ್ಮ ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗಳನ್ನು ನಾವು ಪರಿಹರಿಸಿದ್ದೇವೆ - ಅದು ಕೆಲಸ ಮಾಡಿದೆ! ಆದರೆ ಶೆಲ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆ, ಅದನ್ನು ಮತ್ತಷ್ಟು ವಿಸ್ತರಿಸುವುದು ಅಸಾಧ್ಯ, ಶೆಲ್‌ನಲ್ಲಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾಡುವುದು ಮತ್ತೊಂದು ಕಾರ್ಯವಾಗಿದೆ. ನಮಗೆ ಮಾಣಿಕ್ಯದಲ್ಲಿ ಬರೆಯುವ ಅಭ್ಯಾಸವಿತ್ತು, ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ, ನಾವು ರೂಬಿಯಲ್ಲಿ ಏನನ್ನಾದರೂ ರೀಮೇಕ್ ಮಾಡುತ್ತೇವೆ, ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ, ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ, ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು “ನಮಗೆ ಅದು ಬೇಕು ಅಥವಾ ನಮಗೆ ಅದು ಬೇಡ” ಎಂದು ಹೇಳದ ಸಮುದಾಯ, ಜನಸಮೂಹ. ” ಮಾಣಿಕ್ಯದ ಕಡೆಗೆ ಮೂಗು ತಿರುಗಿಸಿ, ಇದು ಹೇಗೆ ತಮಾಷೆಯಾಗಿಲ್ಲ? ಪರಿಶೀಲನಾಪಟ್ಟಿಯಲ್ಲಿನ ಮೊದಲ ಬಿಂದುವನ್ನು ಪೂರೈಸಲು ನಾವು ಈ ಎಲ್ಲಾ ವಿಷಯವನ್ನು Go ನಲ್ಲಿ ಬರೆಯಬೇಕು ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ: DevOps ಉಪಕರಣವು ಸ್ಥಿರ ಬೈನರಿ ಆಗಿರಬೇಕು. ಗೋ ಆಗಿರಬೇಕೋ ಇಲ್ಲವೋ ಎಂಬುದು ಅಷ್ಟು ಮುಖ್ಯವಲ್ಲ, ಆದರೆ ಗೋದಲ್ಲಿ ಬರೆಯಲಾದ ಸ್ಥಿರ ಬೈನರಿ ಉತ್ತಮವಾಗಿದೆ.
ನಾವು ನಮ್ಮ ಶಕ್ತಿಯನ್ನು ವ್ಯಯಿಸಿದ್ದೇವೆ, ಗೋದಲ್ಲಿ ಡಪ್ ಅನ್ನು ಪುನಃ ಬರೆದಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ವರ್ಫ್ ಎಂದು ಕರೆದಿದ್ದೇವೆ. Dapp ಇನ್ನು ಮುಂದೆ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿಲ್ಲ, ಕೆಲವು ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ, ಆದರೆ ಮೇಲ್ಭಾಗಕ್ಕೆ ಸಂಪೂರ್ಣ ಅಪ್‌ಗ್ರೇಡ್ ಮಾರ್ಗವಿದೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಅನುಸರಿಸಬಹುದು.
ಡಪ್ ಅನ್ನು ಏಕೆ ರಚಿಸಲಾಗಿದೆ?
— ಡಪ್ ಅನ್ನು ಏಕೆ ರಚಿಸಲಾಗಿದೆ, ಅದು ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ನಮಗೆ ಹೇಳಬಲ್ಲಿರಾ?
ಡಿಮಿಟ್ರಿ: ಮೊದಲ ಕಾರಣ ವಿಧಾನಸಭೆಯಲ್ಲಿ. ಆರಂಭದಲ್ಲಿ, ಡಾಕರ್ ಬಹು-ಹಂತದ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದಾಗ ನಾವು ನಿರ್ಮಾಣದಲ್ಲಿ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನಾವು ನಮ್ಮದೇ ಆದ ಬಹು-ಹಂತವನ್ನು ಮಾಡಿದ್ದೇವೆ. ನಂತರ ನಾವು ಚಿತ್ರವನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. CI/CD ಮಾಡುವ ಪ್ರತಿಯೊಬ್ಬರೂ, ಶೀಘ್ರದಲ್ಲೇ, ಸಂಗ್ರಹಿಸಿದ ಚಿತ್ರಗಳ ಗುಂಪನ್ನು ಹೊಂದಿರುವ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತಾರೆ, ನೀವು ಹೇಗಾದರೂ ಅಗತ್ಯವಿಲ್ಲದ್ದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಬೇಕು ಮತ್ತು ಅಗತ್ಯವಿರುವದನ್ನು ಬಿಡಬೇಕು.
ಎರಡನೆಯ ಕಾರಣವೆಂದರೆ ನಿಯೋಜನೆ. ಹೌದು, ಹೆಲ್ಮ್ ಇದೆ, ಆದರೆ ಇದು ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಮಾತ್ರ ಪರಿಹರಿಸುತ್ತದೆ. ತಮಾಷೆಯೆಂದರೆ, "ಹೆಲ್ಮ್ ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್" ಎಂದು ಬರೆಯಲಾಗಿದೆ. ನಿಖರವಾಗಿ ಏನು "ದಿ". "ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್" ಎಂಬ ಪದಗಳೂ ಇವೆ - ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ನಿಂದ ಸಾಮಾನ್ಯ ನಿರೀಕ್ಷೆ ಏನು? ನಾವು ಹೇಳುತ್ತೇವೆ: "ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ - ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ!" ಮತ್ತು ಅವನು ನಮಗೆ ಹೇಳಬೇಕೆಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ: "ಪ್ಯಾಕೇಜ್ ಅನ್ನು ತಲುಪಿಸಲಾಗಿದೆ."
"ಹೆಲ್ಮ್, ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ" ಎಂದು ನಾವು ಹೇಳುವುದು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಮತ್ತು ಅವರು ಅದನ್ನು ಸ್ಥಾಪಿಸಿದ್ದಾರೆ ಎಂದು ಉತ್ತರಿಸಿದಾಗ, ಅವರು ಕೇವಲ ಅನುಸ್ಥಾಪನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದಾರೆ ಎಂದು ತಿರುಗುತ್ತದೆ - ಅವರು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಸೂಚಿಸಿದರು: "ಈ ವಿಷಯವನ್ನು ಪ್ರಾರಂಭಿಸಿ!", ಮತ್ತು ಅದು ಪ್ರಾರಂಭವೋ ಇಲ್ಲವೋ. , ಅದು ಕೆಲಸ ಮಾಡಲಿ ಅಥವಾ ಇಲ್ಲದಿರಲಿ, ಹೆಲ್ಮ್ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ.
ಹೆಲ್ಮ್ ಕೇವಲ ಪಠ್ಯ ಪ್ರಿಪ್ರೊಸೆಸರ್ ಆಗಿದ್ದು ಅದು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ.
ಆದರೆ ಯಾವುದೇ ನಿಯೋಜನೆಯ ಭಾಗವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಉತ್ಪಾದನೆಗೆ ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ತಿಳಿಯಲು ನಾವು ಬಯಸುತ್ತೇವೆ? ರೋಲ್ ಔಟ್ ಟು ಪ್ರೊಡ್ ಎಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಅಲ್ಲಿಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದೆ, ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಕನಿಷ್ಠ ಅದು ಅಲ್ಲಿ ಕ್ರ್ಯಾಶ್ ಆಗುವುದಿಲ್ಲ ಮತ್ತು ಸರಿಯಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಹೆಲ್ಮ್ ಈ ಸಮಸ್ಯೆಯನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸುವುದಿಲ್ಲ. ಅದನ್ನು ಪರಿಹರಿಸಲು, ನೀವು ಸಾಕಷ್ಟು ಶ್ರಮವನ್ನು ವ್ಯಯಿಸಬೇಕಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ರೋಲ್ ಔಟ್ ಮಾಡಲು ಮತ್ತು ಅಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಆಜ್ಞೆಯನ್ನು ನೀಡಬೇಕಾಗುತ್ತದೆ - ಅದು ನಿಯೋಜಿಸಿದ್ದರೂ ಅಥವಾ ಹೊರತಂದಿದೆಯೇ. ಮತ್ತು ನಿಯೋಜನೆ, ಶುಚಿಗೊಳಿಸುವಿಕೆ ಮತ್ತು ಜೋಡಣೆಗೆ ಸಂಬಂಧಿಸಿದ ಬಹಳಷ್ಟು ಕಾರ್ಯಗಳು ಸಹ ಇವೆ.
ಯೋಜನೆಗಳು
ಈ ವರ್ಷ ನಾವು ಸ್ಥಳೀಯ ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ವ್ಯಾಗ್ರಾಂಟ್‌ನಲ್ಲಿ ಹಿಂದೆ ಇದ್ದದ್ದನ್ನು ನಾವು ಸಾಧಿಸಲು ಬಯಸುತ್ತೇವೆ - ನಾವು "ವ್ಯಾಗ್ರಾಂಟ್ ಅಪ್" ಎಂದು ಟೈಪ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ. Git ನಲ್ಲಿ ಪ್ರಾಜೆಕ್ಟ್ ಇರುವ ಹಂತಕ್ಕೆ ಹೋಗಲು ನಾವು ಬಯಸುತ್ತೇವೆ, ನಾವು ಅಲ್ಲಿ "ವರ್ಫ್ ಅಪ್" ಎಂದು ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ಇದು ಈ ಯೋಜನೆಯ ಸ್ಥಳೀಯ ನಕಲನ್ನು ತರುತ್ತದೆ, ಸ್ಥಳೀಯ ಮಿನಿ-ಕುಬ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ, ಅಭಿವೃದ್ಧಿಗೆ ಅನುಕೂಲಕರವಾದ ಎಲ್ಲಾ ಡೈರೆಕ್ಟರಿಗಳೊಂದಿಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದೆ. . ಅಭಿವೃದ್ಧಿ ಭಾಷೆಯನ್ನು ಅವಲಂಬಿಸಿ, ಇದನ್ನು ವಿಭಿನ್ನವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ಆರೋಹಿತವಾದ ಫೈಲ್‌ಗಳ ಅಡಿಯಲ್ಲಿ ಸ್ಥಳೀಯ ಅಭಿವೃದ್ಧಿಯನ್ನು ಅನುಕೂಲಕರವಾಗಿ ಕೈಗೊಳ್ಳಬಹುದು.
ನಮಗೆ ಮುಂದಿನ ಹಂತ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅನುಕೂಲವಾಗುವಂತೆ ಹೂಡಿಕೆ ಮಾಡಿ. ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಒಂದು ಸಾಧನದೊಂದಿಗೆ ತ್ವರಿತವಾಗಿ ನಿಯೋಜಿಸಲು, ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿ, ಅದನ್ನು Git ಗೆ ತಳ್ಳಿರಿ ಮತ್ತು ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿ ಅದು ಹಂತ ಅಥವಾ ಪರೀಕ್ಷೆಗಳಿಗೆ ಹೊರಹೊಮ್ಮುತ್ತದೆ ಮತ್ತು ನಂತರ ಉತ್ಪಾದನೆಗೆ ಹೋಗಲು ಅದೇ ಸಾಧನವನ್ನು ಬಳಸಿ. ಈ ಏಕತೆ, ಏಕೀಕರಣ, ಸ್ಥಳೀಯ ಪರಿಸರದಿಂದ ಮಾರಾಟಕ್ಕೆ ಮೂಲಸೌಕರ್ಯಗಳ ಪುನರುತ್ಪಾದನೆ ನಮಗೆ ಬಹಳ ಮುಖ್ಯವಾದ ಅಂಶವಾಗಿದೆ. ಆದರೆ ಇದು ಇನ್ನೂ ವರ್ಫ್‌ನಲ್ಲಿಲ್ಲ - ನಾವು ಅದನ್ನು ಮಾಡಲು ಯೋಜಿಸುತ್ತಿದ್ದೇವೆ.
ಆದರೆ dapp/werf ಮಾರ್ಗವು ಯಾವಾಗಲೂ ಆರಂಭದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್‌ನಂತೆಯೇ ಇರುತ್ತದೆ. ನಾವು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ, ಪರಿಹಾರೋಪಾಯಗಳೊಂದಿಗೆ ಅವುಗಳನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ - ಶೆಲ್‌ನಲ್ಲಿ, ಯಾವುದನ್ನಾದರೂ ನಾವು ಕೆಲವು ಪರಿಹಾರಗಳೊಂದಿಗೆ ಬಂದಿದ್ದೇವೆ. ನಂತರ ಅವರು ಹೇಗಾದರೂ ಈ ಪರಿಹಾರಗಳನ್ನು ನೇರಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಿದರು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳನ್ನು ಬೈನರಿಗಳಾಗಿ ಸಾಮಾನ್ಯೀಕರಿಸಲು ಮತ್ತು ಕ್ರೋಢೀಕರಿಸಲು ಪ್ರಯತ್ನಿಸಿದರು, ಅದನ್ನು ನಾವು ಸರಳವಾಗಿ ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ.
ಈ ಇಡೀ ಕಥೆಯನ್ನು ಸಾದೃಶ್ಯಗಳೊಂದಿಗೆ ನೋಡಲು ಇನ್ನೊಂದು ಮಾರ್ಗವಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಎಂಜಿನ್ ಹೊಂದಿರುವ ಕಾರ್ ಫ್ರೇಮ್ ಆಗಿದೆ. ಬಾಗಿಲುಗಳು, ಗಾಜು, ರೇಡಿಯೋ, ಕ್ರಿಸ್ಮಸ್ ಮರ - ಏನೂ ಇಲ್ಲ. ಕೇವಲ ಫ್ರೇಮ್ ಮತ್ತು ಎಂಜಿನ್. ಮತ್ತು ಹೆಲ್ಮ್ ಇದೆ - ಇದು ಸ್ಟೀರಿಂಗ್ ಚಕ್ರ. ಕೂಲ್ - ಸ್ಟೀರಿಂಗ್ ವೀಲ್ ಇದೆ, ಆದರೆ ನಿಮಗೆ ಸ್ಟೀರಿಂಗ್ ಪಿನ್, ಸ್ಟೀರಿಂಗ್ ರ್ಯಾಕ್, ಗೇರ್ ಬಾಕ್ಸ್ ಮತ್ತು ಚಕ್ರಗಳು ಸಹ ಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಿಲ್ಲದೆ ನೀವು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ವರ್ಫ್ ವಿಷಯದಲ್ಲಿ, ಇದು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಮತ್ತೊಂದು ಅಂಶವಾಗಿದೆ. ಈಗ ವರ್ಫ್‌ನ ಆಲ್ಫಾ ಆವೃತ್ತಿಯಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಹೆಲ್ಮ್ ಅನ್ನು ವರ್ಫ್‌ನೊಳಗೆ ಸಂಕಲಿಸಲಾಗಿದೆ, ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ನಾವೇ ಮಾಡಲು ಆಯಾಸಗೊಂಡಿದ್ದೇವೆ. ಇದನ್ನು ಮಾಡಲು ಹಲವು ಕಾರಣಗಳಿವೆ, ನಾವು ಸಂಪೂರ್ಣ ಚುಕ್ಕಾಣಿಯನ್ನು ವರ್ಫ್ ಒಳಗಿನ ಟಿಲ್ಲರ್‌ನೊಂದಿಗೆ ಏಕೆ ಸಂಕಲಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ನಿಮಗೆ ವಿವರವಾಗಿ ಹೇಳುತ್ತೇನೆ .
ಈಗ ವರ್ಫ್ ಹೆಚ್ಚು ಸಂಯೋಜಿತ ಘಟಕವಾಗಿದೆ. ನಾವು ಸಿದ್ಧಪಡಿಸಿದ ಸ್ಟೀರಿಂಗ್ ವೀಲ್, ಸ್ಟೀರಿಂಗ್ ಪಿನ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ - ನಾನು ಕಾರುಗಳಲ್ಲಿ ತುಂಬಾ ಒಳ್ಳೆಯವನಲ್ಲ, ಆದರೆ ಇದು ದೊಡ್ಡ ಬ್ಲಾಕ್ ಆಗಿದ್ದು ಅದು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ವ್ಯಾಪಕವಾದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ನಾವು ಕ್ಯಾಟಲಾಗ್ ಮೂಲಕ ಹೋಗಬೇಕಾಗಿಲ್ಲ, ಇನ್ನೊಂದಕ್ಕೆ ಒಂದು ಭಾಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಅವುಗಳನ್ನು ಹೇಗೆ ಒಟ್ಟಿಗೆ ತಿರುಗಿಸುವುದು ಎಂದು ಯೋಚಿಸಿ. ಏಕಕಾಲದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ರೆಡಿಮೇಡ್ ಸಂಯೋಜನೆಯನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ. ಆದರೆ ಅದರ ಒಳಗೆ ಅದೇ ತೆರೆದ ಮೂಲ ಘಟಕಗಳಿಂದ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಇದು ಇನ್ನೂ ಜೋಡಣೆಗಾಗಿ ಡಾಕರ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಕೆಲವು ಕಾರ್ಯಗಳಿಗಾಗಿ ಹೆಲ್ಮ್ ಮತ್ತು ಹಲವಾರು ಇತರ ಗ್ರಂಥಾಲಯಗಳಿವೆ. ತಂಪಾದ CI/CD ಅನ್ನು ಬಾಕ್ಸ್‌ನಿಂದ ತ್ವರಿತವಾಗಿ ಮತ್ತು ಅನುಕೂಲಕರವಾಗಿ ಪಡೆಯಲು ಇದು ಒಂದು ಸಂಯೋಜಿತ ಸಾಧನವಾಗಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಕಷ್ಟವೇ?
- ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ ಅನುಭವದ ಬಗ್ಗೆ ನೀವು ಮಾತನಾಡುತ್ತೀರಿ, ಇದು ನಿಮಗಾಗಿ ಒಂದು ಫ್ರೇಮ್, ಎಂಜಿನ್, ಮತ್ತು ನೀವು ಅದರ ಮೇಲೆ ಹಲವಾರು ವಿಭಿನ್ನ ವಸ್ತುಗಳನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು: ಒಂದು ದೇಹ, ಸ್ಟೀರಿಂಗ್ ಚಕ್ರ, ಪೆಡಲ್ಗಳ ಮೇಲೆ ಸ್ಕ್ರೂ, ಆಸನಗಳು. ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ - ಕುಬರ್ನೆಟ್ಸ್ ನಿಮಗೆ ಬೆಂಬಲ ಎಷ್ಟು ಕಷ್ಟ? ನೀವು ಸಾಕಷ್ಟು ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಎಲ್ಲದರಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸಲು ನೀವು ಎಷ್ಟು ಸಮಯ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯಯಿಸುತ್ತೀರಿ?
ಡಿಮಿಟ್ರಿ: ಇದು ತುಂಬಾ ಕಷ್ಟಕರವಾದ ಪ್ರಶ್ನೆಯಾಗಿದೆ ಮತ್ತು ಉತ್ತರಿಸಲು, ನಾವು ಕುಬರ್ನೆಟ್ಸ್ನಿಂದ ಬೆಂಬಲ ಮತ್ತು ನಾವು ಏನನ್ನು ಬಯಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಬಹುಶಃ ನೀವು ಬಹಿರಂಗಪಡಿಸಬಹುದೇ?
- ನನಗೆ ತಿಳಿದಿರುವಂತೆ ಮತ್ತು ನಾನು ನೋಡಿದಂತೆ, ಈಗ ಅನೇಕ ತಂಡಗಳು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸಲು ಬಯಸುತ್ತವೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಅದಕ್ಕೆ ತಮ್ಮನ್ನು ತಾವು ತೊಡಗಿಸಿಕೊಳ್ಳುತ್ತಾರೆ, ಅದನ್ನು ತಮ್ಮ ಮೊಣಕಾಲುಗಳ ಮೇಲೆ ಇಡುತ್ತಾರೆ. ಈ ವ್ಯವಸ್ಥೆಯ ಸಂಕೀರ್ಣತೆಯನ್ನು ಜನರು ಯಾವಾಗಲೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂಬ ಭಾವನೆ ನನ್ನಲ್ಲಿದೆ.
ಡಿಮಿಟ್ರಿ: ಅದು ಹಾಗೆ.
- ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಮೊದಲಿನಿಂದ ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಸ್ಥಾಪಿಸುವುದು ಎಷ್ಟು ಕಷ್ಟ, ಇದರಿಂದ ಅದು ಉತ್ಪಾದನೆಗೆ ಸಿದ್ಧವಾಗಿದೆ?
ಡಿಮಿಟ್ರಿ: ಹೃದಯವನ್ನು ಕಸಿ ಮಾಡುವುದು ಎಷ್ಟು ಕಷ್ಟ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ? ಇದು ರಾಜಿ ಮಾಡಿಕೊಳ್ಳುವ ಪ್ರಶ್ನೆ ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಸ್ಕಾಲ್ಪೆಲ್ ಅನ್ನು ಬಳಸುವುದು ಮತ್ತು ತಪ್ಪು ಮಾಡದಿರುವುದು ಕಷ್ಟವೇನಲ್ಲ. ಎಲ್ಲಿ ಕತ್ತರಿಸಬೇಕು ಮತ್ತು ಎಲ್ಲಿ ಹೊಲಿಯಬೇಕು ಎಂದು ಅವರು ನಿಮಗೆ ಹೇಳಿದರೆ, ಕಾರ್ಯವಿಧಾನವು ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ. ಕಾಲಾನಂತರದಲ್ಲಿ ಎಲ್ಲವೂ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸುವುದು ಕಷ್ಟ.
ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಕೆಲಸ ಮಾಡುವುದು ಸುಲಭ: ಮರಿಯನ್ನು! — ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಸಾಕಷ್ಟು ಅನುಸ್ಥಾಪನಾ ವಿಧಾನಗಳಿವೆ. ಆದರೆ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದಾಗ ಏನಾಗುತ್ತದೆ?
ಪ್ರಶ್ನೆಗಳು ಯಾವಾಗಲೂ ಉದ್ಭವಿಸುತ್ತವೆ - ನಾವು ಇನ್ನೂ ಏನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡಿಲ್ಲ? ನಾವು ಇನ್ನೂ ಏನು ಮಾಡಿಲ್ಲ? ಯಾವ Linux ಕರ್ನಲ್ ನಿಯತಾಂಕಗಳನ್ನು ತಪ್ಪಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ? ಕರ್ತನೇ, ನಾವು ಅವರನ್ನು ಉಲ್ಲೇಖಿಸಿದ್ದೇವೆಯೇ?! ನಾವು ಯಾವ ಕುಬರ್ನೆಟ್ಸ್ ಘಟಕಗಳನ್ನು ವಿತರಿಸಿದ್ದೇವೆ ಮತ್ತು ಯಾವುದನ್ನು ನಾವು ವಿತರಿಸಿಲ್ಲ? ಸಾವಿರಾರು ಪ್ರಶ್ನೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳಿಗೆ ಉತ್ತರಿಸಲು, ನೀವು ಈ ಉದ್ಯಮದಲ್ಲಿ 15-20 ವರ್ಷಗಳನ್ನು ಕಳೆಯಬೇಕಾಗಿದೆ.
ಈ ವಿಷಯದ ಕುರಿತು ನಾನು ಇತ್ತೀಚಿನ ಉದಾಹರಣೆಯನ್ನು ಹೊಂದಿದ್ದೇನೆ ಅದು ಸಮಸ್ಯೆಯ ಅರ್ಥವನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು "ಕುಬರ್ನೆಟ್ಸ್ ನಿರ್ವಹಿಸಲು ಕಷ್ಟವೇ?" ಕೆಲವು ಸಮಯದ ಹಿಂದೆ ನಾವು Cilium ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಆಗಿ ಅಳವಡಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಕೇ ಎಂದು ನಾವು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸಿದ್ದೇವೆ.
ಸಿಲಿಯಮ್ ಎಂದರೇನು ಎಂದು ನಾನು ವಿವರಿಸುತ್ತೇನೆ. ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಉಪವ್ಯವಸ್ಥೆಯ ವಿವಿಧ ಅಳವಡಿಕೆಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ತುಂಬಾ ತಂಪಾಗಿದೆ - ಸಿಲಿಯಮ್. ಅದರ ಅರ್ಥವೇನು? ಕರ್ನಲ್‌ನಲ್ಲಿ, ಸ್ವಲ್ಪ ಸಮಯದ ಹಿಂದೆ ಕರ್ನಲ್‌ಗಾಗಿ ಕೊಕ್ಕೆಗಳನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಾಯಿತು, ಇದು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯನ್ನು ಮತ್ತು ಹಲವಾರು ಇತರ ಉಪವ್ಯವಸ್ಥೆಗಳನ್ನು ಆಕ್ರಮಿಸುತ್ತದೆ ಮತ್ತು ಕರ್ನಲ್‌ನಲ್ಲಿನ ದೊಡ್ಡ ಭಾಗಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಐತಿಹಾಸಿಕವಾಗಿ ಐಪಿ ರೂಟ್, ಓವರ್‌ಫಿಲ್ಟರ್, ಸೇತುವೆಗಳು ಮತ್ತು 15, 20, 30 ವರ್ಷಗಳಷ್ಟು ಹಳೆಯದಾದ ಹಲವು ಹಳೆಯ ಘಟಕಗಳನ್ನು ಹೊಂದಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಅವರು ಕೆಲಸ ಮಾಡುತ್ತಾರೆ, ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ, ಆದರೆ ಈಗ ಅವರು ಧಾರಕಗಳನ್ನು ರಾಶಿ ಹಾಕಿದ್ದಾರೆ, ಮತ್ತು ಅದು ಒಂದರ ಮೇಲೊಂದು 15 ಇಟ್ಟಿಗೆಗಳ ಗೋಪುರದಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ನೀವು ಅದರ ಮೇಲೆ ಒಂದು ಕಾಲಿನ ಮೇಲೆ ನಿಲ್ಲುತ್ತೀರಿ - ವಿಚಿತ್ರ ಭಾವನೆ. ಈ ವ್ಯವಸ್ಥೆಯು ಐತಿಹಾಸಿಕವಾಗಿ ದೇಹದಲ್ಲಿನ ಅನುಬಂಧದಂತೆ ಅನೇಕ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳೊಂದಿಗೆ ಅಭಿವೃದ್ಧಿಗೊಂಡಿದೆ. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿವೆ, ಉದಾಹರಣೆಗೆ.
ಅದ್ಭುತವಾದ ಬಿಪಿಎಫ್ ಮತ್ತು ಕರ್ನಲ್‌ಗಾಗಿ ಕೊಕ್ಕೆಗಳನ್ನು ಬರೆಯುವ ಸಾಮರ್ಥ್ಯವಿದೆ - ಹುಡುಗರು ಕರ್ನಲ್‌ಗಾಗಿ ತಮ್ಮದೇ ಆದ ಕೊಕ್ಕೆಗಳನ್ನು ಬರೆದಿದ್ದಾರೆ. ಪ್ಯಾಕೇಜ್ ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ಗೆ ಬರುತ್ತದೆ, ಅವರು ಅದನ್ನು ಇನ್‌ಪುಟ್‌ನಲ್ಲಿಯೇ ಹೊರತೆಗೆಯುತ್ತಾರೆ, ಸೇತುವೆಗಳಿಲ್ಲದೆ, ಟಿಸಿಪಿ ಇಲ್ಲದೆ, ಐಪಿ ಸ್ಟಾಕ್ ಇಲ್ಲದೆಯೇ ಅದನ್ನು ಸ್ವತಃ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಾರೆ - ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನಲ್ಲಿ ಬರೆದ ಎಲ್ಲವನ್ನೂ ಬೈಪಾಸ್ ಮಾಡಿ ಮತ್ತು ನಂತರ ಉಗುಳುತ್ತಾರೆ. ಅದನ್ನು ಕಂಟೇನರ್‌ಗೆ ಹೊರತೆಗೆಯಿರಿ.
ಏನಾಯಿತು? ತುಂಬಾ ತಂಪಾದ ಕಾರ್ಯಕ್ಷಮತೆ, ತಂಪಾದ ವೈಶಿಷ್ಟ್ಯಗಳು - ಕೇವಲ ತಂಪಾಗಿದೆ! ಆದರೆ ನಾವು ಇದನ್ನು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಪ್ರತಿ ಗಣಕದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ API ಗೆ ಸಂಪರ್ಕಿಸುವ ಪ್ರೋಗ್ರಾಂ ಇದೆ ಮತ್ತು ಈ API ನಿಂದ ಸ್ವೀಕರಿಸುವ ಡೇಟಾದ ಆಧಾರದ ಮೇಲೆ C ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಬೈನರಿಗಳನ್ನು ಕರ್ನಲ್‌ಗೆ ಲೋಡ್ ಮಾಡುತ್ತದೆ ಇದರಿಂದ ಈ ಕೊಕ್ಕೆಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಕರ್ನಲ್ ಜಾಗದಲ್ಲಿ.
ಏನಾದರೂ ತಪ್ಪಾದಲ್ಲಿ ಏನಾಗುತ್ತದೆ? ನಮಗೆ ಗೊತ್ತಿಲ್ಲ. ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನೀವು ಈ ಎಲ್ಲಾ ಕೋಡ್ ಅನ್ನು ಓದಬೇಕು, ಎಲ್ಲಾ ತರ್ಕವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಅದು ಎಷ್ಟು ಕಷ್ಟಕರವಾಗಿದೆ ಎಂಬುದು ಆಶ್ಚರ್ಯಕರವಾಗಿದೆ. ಆದರೆ, ಮತ್ತೊಂದೆಡೆ, ಈ ಸೇತುವೆಗಳು, ನೆಟ್ ಫಿಲ್ಟರ್‌ಗಳು, ಐಪಿ ರೂಟ್ ಇವೆ - ನಾನು ಅವರ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಓದಿಲ್ಲ ಮತ್ತು ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ 40 ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಬಹುಶಃ ಕೆಲವರು ಮಾತ್ರ ಕೆಲವು ಭಾಗಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ.
ಮತ್ತು ವ್ಯತ್ಯಾಸವೇನು? ಐಪಿ ರೂಟ್, ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಮತ್ತು ಹೊಸ ಸಾಧನವಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ - ಇದು ಯಾವ ವ್ಯತ್ಯಾಸವನ್ನು ಮಾಡುತ್ತದೆ, ನಮಗೆ ಒಂದು ಅಥವಾ ಇನ್ನೊಂದನ್ನು ಅರ್ಥವಾಗುವುದಿಲ್ಲ. ಆದರೆ ಹೊಸದನ್ನು ಬಳಸಲು ನಾವು ಹೆದರುತ್ತೇವೆ - ಏಕೆ? ಏಕೆಂದರೆ ಉಪಕರಣವು 30 ವರ್ಷ ಹಳೆಯದಾಗಿದ್ದರೆ, 30 ವರ್ಷಗಳಲ್ಲಿ ಎಲ್ಲಾ ದೋಷಗಳು ಕಂಡುಬಂದಿವೆ, ಎಲ್ಲಾ ತಪ್ಪುಗಳನ್ನು ಮಾಡಲಾಗಿದೆ ಮತ್ತು ನೀವು ಎಲ್ಲದರ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ - ಇದು ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಯಾವಾಗಲೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಯಾವ ಡಯಾಗ್ನೋಸ್ಟಿಕ್ ಸ್ಕ್ರೂಡ್ರೈವರ್ ಅನ್ನು ಯಾವ ಸ್ಥಳದಲ್ಲಿ ಅಂಟಿಸಬೇಕು, ಯಾವ ಕ್ಷಣದಲ್ಲಿ ಯಾವ ಟಿಸಿಪಿಡಂಪ್ ಅನ್ನು ಚಲಾಯಿಸಬೇಕು ಎಂಬುದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ರೋಗನಿರ್ಣಯದ ಉಪಯುಕ್ತತೆಗಳನ್ನು ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದಾರೆ ಮತ್ತು ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನಲ್ಲಿ ಈ ಘಟಕಗಳ ಸೆಟ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ - ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಅದನ್ನು ಹೇಗೆ ಬಳಸುವುದು.
ಮತ್ತು ಅದ್ಭುತವಾದ ತಂಪಾದ ಸಿಲಿಯಮ್ 30 ವರ್ಷ ವಯಸ್ಸಾಗಿಲ್ಲ, ಅದು ಇನ್ನೂ ವಯಸ್ಸಾಗಿಲ್ಲ. ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಅದೇ ಸಮಸ್ಯೆ ಇದೆ, ನಕಲಿಸಿ. ಸಿಲಿಯಮ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಆದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಾದಾಗ, ನಿರ್ಣಾಯಕ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಏನು ತಪ್ಪಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವೇ?
ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಕಷ್ಟವೇ ಎಂದು ನಾವು ಹೇಳಿದಾಗ - ಇಲ್ಲ, ಇದು ತುಂಬಾ ಸುಲಭ, ಮತ್ತು ಹೌದು, ಇದು ನಂಬಲಾಗದಷ್ಟು ಕಷ್ಟ. ಕುಬರ್ನೆಟ್ಸ್ ತನ್ನದೇ ಆದ ಮೇಲೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಶತಕೋಟಿ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳೊಂದಿಗೆ.
"ನಾನು ಅದೃಷ್ಟಶಾಲಿಯಾಗುತ್ತೇನೆ" ವಿಧಾನದ ಬಗ್ಗೆ
— ಈ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಲು ಬಹುತೇಕ ಖಾತರಿಪಡಿಸುವ ಕಂಪನಿಗಳಿವೆಯೇ? Yandex ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು Kubernetes ಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ, ಅಲ್ಲಿ ದೊಡ್ಡ ಹೊರೆ ಇರುತ್ತದೆ.
ಡಿಮಿಟ್ರಿ: ಇಲ್ಲ, ಇದು ಲೋಡ್ ಬಗ್ಗೆ ಸಂಭಾಷಣೆ ಅಲ್ಲ, ಆದರೆ ಸರಳವಾದ ವಿಷಯಗಳ ಬಗ್ಗೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಅಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ. ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ನಿಮಗೆ ಹೇಗೆ ಗೊತ್ತು? ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಯಾವುದೇ ಸಿದ್ಧ ಸಾಧನವಿಲ್ಲ. ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕಳುಹಿಸುವ ಯಾವುದೇ ಸಿದ್ಧ ವ್ಯವಸ್ಥೆ ಇಲ್ಲ; ನೀವು ಈ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಮತ್ತು ಪ್ರತಿ ವೇಳಾಪಟ್ಟಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತಿದ್ದೇವೆ.
ನನ್ನ ಬಳಿ ಉಬುಂಟು 16.04 ಇದೆ. ಇದು ಹಳೆಯ ಆವೃತ್ತಿ ಎಂದು ನೀವು ಹೇಳಬಹುದು, ಆದರೆ ಇದು LTS ಆಗಿರುವುದರಿಂದ ನಾವು ಇನ್ನೂ ಅದರಲ್ಲಿದ್ದೇವೆ. ಸಿಸ್ಟಮ್ಡ್ ಇದೆ, ಅದರ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಅದು ಸಿ-ಗುಂಪುಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದಿಲ್ಲ. ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ, ಸಿ-ಗುಂಪುಗಳನ್ನು ರಚಿಸುತ್ತಾನೆ, ನಂತರ ಪಾಡ್‌ಗಳನ್ನು ಅಳಿಸುತ್ತಾನೆ ಮತ್ತು ಹೇಗಾದರೂ ಅದು ಹೊರಹೊಮ್ಮುತ್ತದೆ - ನನಗೆ ವಿವರಗಳು ನೆನಪಿಲ್ಲ, ಕ್ಷಮಿಸಿ - ಸಿಸ್ಟಮ್ಡ್ ಸ್ಲೈಸ್‌ಗಳು ಉಳಿದಿವೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, ಯಾವುದೇ ಕಾರು ಬಲವಾಗಿ ನಿಧಾನಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಇದು ಕಾರಣವಾಗುತ್ತದೆ. ಇದು ಹೈಲೋಡ್ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಯೂ ಅಲ್ಲ. ಶಾಶ್ವತ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ, ಉದಾಹರಣೆಗೆ, ನಿರಂತರವಾಗಿ ಪಾಡ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಕ್ರಾನ್ ಜಾಬ್ ಇದ್ದರೆ, ನಂತರ ಉಬುಂಟು 16.04 ನೊಂದಿಗೆ ಯಂತ್ರವು ಒಂದು ವಾರದ ನಂತರ ನಿಧಾನಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಸಿ-ಗುಂಪುಗಳ ಗುಂಪನ್ನು ರಚಿಸಲಾಗಿದೆ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ ನಿರಂತರವಾಗಿ ಹೆಚ್ಚಿನ ಲೋಡ್ ಸರಾಸರಿ ಇರುತ್ತದೆ. Ubuntu 16 ಮತ್ತು Kubernetes ಅನ್ನು ಸರಳವಾಗಿ ಸ್ಥಾಪಿಸುವ ಯಾವುದೇ ವ್ಯಕ್ತಿಯು ಎದುರಿಸುವ ಸಮಸ್ಯೆ ಇದು.
ಅವರು ಹೇಗಾದರೂ systemd ಅಥವಾ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ನವೀಕರಿಸುತ್ತಾರೆ ಎಂದು ಹೇಳೋಣ, ಆದರೆ 4.16 ವರೆಗಿನ Linux ಕರ್ನಲ್‌ನಲ್ಲಿ ಇದು ಇನ್ನಷ್ಟು ತಮಾಷೆಯಾಗಿದೆ - ನೀವು C- ಗುಂಪುಗಳನ್ನು ಅಳಿಸಿದಾಗ, ಅವು ಕರ್ನಲ್‌ನಲ್ಲಿ ಸೋರಿಕೆಯಾಗುತ್ತವೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಅಳಿಸಲಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಈ ಯಂತ್ರದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ಒಂದು ತಿಂಗಳ ನಂತರ, ಒಲೆಗಳಿಗೆ ಮೆಮೊರಿ ಅಂಕಿಅಂಶಗಳನ್ನು ನೋಡುವುದು ಅಸಾಧ್ಯ. ನಾವು ಫೈಲ್ ಅನ್ನು ಹೊರತೆಗೆಯುತ್ತೇವೆ, ಪ್ರೋಗ್ರಾಂನಲ್ಲಿ ರೋಲ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಒಂದು ಫೈಲ್ 15 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಉರುಳುತ್ತದೆ, ಏಕೆಂದರೆ ಕರ್ನಲ್ ತನ್ನೊಳಗೆ ಮಿಲಿಯನ್ ಸಿ-ಗುಂಪುಗಳನ್ನು ಎಣಿಸಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅದು ಅಳಿಸಿದಂತೆ ತೋರುತ್ತದೆ, ಆದರೆ ಇಲ್ಲ - ಅವು ಸೋರಿಕೆಯಾಗುತ್ತಿವೆ. .
ಅಲ್ಲೊಂದು ಇಲ್ಲೊಂದು ಇಂಥ ಚಿಕ್ಕಪುಟ್ಟ ಸಂಗತಿಗಳು ಇನ್ನೂ ಸಾಕಷ್ಟಿವೆ. ಇದು ದೈತ್ಯ ಕಂಪನಿಗಳು ಕೆಲವೊಮ್ಮೆ ಭಾರೀ ಹೊರೆಗಳನ್ನು ಎದುರಿಸಬಹುದಾದ ಸಮಸ್ಯೆಯಲ್ಲ - ಇಲ್ಲ, ಇದು ದೈನಂದಿನ ವಿಷಯಗಳ ವಿಷಯವಾಗಿದೆ. ಜನರು ಈ ರೀತಿ ತಿಂಗಳುಗಟ್ಟಲೆ ಬದುಕಬಹುದು - ಅವರು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದರು, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಿದರು - ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ಅನೇಕ ಜನರಿಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಈ ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಎಂದು ಅವರಿಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ, ಅವರು ಎಚ್ಚರಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅವರಿಗೆ ಇದು ರೂಢಿಯಾಗಿದೆ. ಹಿಂದೆ, ನಾವು ಮಾನಿಟರಿಂಗ್ ಇಲ್ಲದೆ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದೆವು, ಈಗ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ತೆರಳಿದ್ದೇವೆ, ಮೇಲ್ವಿಚಾರಣೆಯಿಲ್ಲದೆ - ವ್ಯತ್ಯಾಸವೇನು?
ಪ್ರಶ್ನೆಯೆಂದರೆ ನಾವು ಮಂಜುಗಡ್ಡೆಯ ಮೇಲೆ ನಡೆಯುವಾಗ, ನಾವು ಅದನ್ನು ಮುಂಚಿತವಾಗಿ ಅಳೆಯದಿದ್ದರೆ ಅದರ ದಪ್ಪವನ್ನು ನಾವು ಎಂದಿಗೂ ತಿಳಿದಿರುವುದಿಲ್ಲ. ಅನೇಕ ಜನರು ನಡೆಯುತ್ತಾರೆ ಮತ್ತು ಚಿಂತಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಅವರು ಹಿಂದೆ ನಡೆದಿದ್ದಾರೆ.
ನನ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸ ಮತ್ತು ಸಂಕೀರ್ಣತೆಯು ನಮ್ಮ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಮಂಜುಗಡ್ಡೆಯ ದಪ್ಪವು ನಿಖರವಾಗಿ ಸಾಕಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು. ಇದನ್ನೇ ನಾವು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ.
ಐಟಿಯಲ್ಲಿ, ಹಲವಾರು "ನಾನು ಅದೃಷ್ಟಶಾಲಿ" ವಿಧಾನಗಳಿವೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಅನೇಕ ಜನರು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತಾರೆ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸುತ್ತಾರೆ, ಅವರು ಅದೃಷ್ಟವನ್ನು ಪಡೆಯುತ್ತಾರೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಅನೇಕ ಜನರು ಅದೃಷ್ಟವಂತರು. ಬಹುಶಃ ಅದಕ್ಕಾಗಿಯೇ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
- ನನ್ನ ನಿರಾಶಾವಾದಿ ಮೌಲ್ಯಮಾಪನದಿಂದ, ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ಅಪಾಯಗಳು ಹೆಚ್ಚಾದಾಗ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡಬೇಕು, ನಂತರ ಫ್ಲೌಂಟ್‌ನಿಂದ ಬೆಂಬಲ ಬೇಕಾಗುತ್ತದೆ, ಬಹುಶಃ Red Hat ನಿಂದ, ಅಥವಾ ನಿಮಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಮೀಸಲಾಗಿರುವ ನಿಮ್ಮ ಸ್ವಂತ ಆಂತರಿಕ ತಂಡ ಬೇಕಾಗುತ್ತದೆ, ಅದು ಸಿದ್ಧವಾಗಿದೆ ಅದನ್ನು ಎಳೆಯಲು.
ಡಿಮಿಟ್ರಿ: ವಸ್ತುನಿಷ್ಠವಾಗಿ, ಇದು ಹಾಗೆ. ನಿಮ್ಮದೇ ಆದ ಸಣ್ಣ ತಂಡಕ್ಕಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಕಥೆಯನ್ನು ಪ್ರವೇಶಿಸುವುದು ಹಲವಾರು ಅಪಾಯಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
ನಮಗೆ ಪಾತ್ರೆಗಳು ಬೇಕೇ?
- ರಷ್ಯಾದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಎಷ್ಟು ವ್ಯಾಪಕವಾಗಿದೆ ಎಂದು ನೀವು ನಮಗೆ ಹೇಳಬಲ್ಲಿರಾ?
ಡಿಮಿಟ್ರಿ: ನನ್ನ ಬಳಿ ಈ ಡೇಟಾ ಇಲ್ಲ, ಮತ್ತು ಬೇರೆಯವರು ಅದನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ನನಗೆ ಖಚಿತವಿಲ್ಲ. ನಾವು ಹೇಳುತ್ತೇವೆ: "ಕುಬರ್ನೆಟ್ಸ್, ಕುಬರ್ನೆಟ್ಸ್," ಆದರೆ ಈ ಸಮಸ್ಯೆಯನ್ನು ನೋಡುವ ಇನ್ನೊಂದು ಮಾರ್ಗವಿದೆ. ಕಂಟೈನರ್‌ಗಳು ಎಷ್ಟು ವ್ಯಾಪಕವಾಗಿವೆ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿನ ವರದಿಗಳಿಂದ 70% ಕಂಟೇನರ್‌ಗಳು ಕುಬರ್ನೆಟ್ಸ್ನಿಂದ ಆಯೋಜಿಸಲ್ಪಟ್ಟಿವೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ. ಪ್ರಪಂಚದಾದ್ಯಂತ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಮಾದರಿಗೆ ಇದು ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲವಾಗಿತ್ತು.
ನಂತರ ಮತ್ತೊಂದು ಪ್ರಶ್ನೆ - ನಮಗೆ ಪಾತ್ರೆಗಳು ಬೇಕೇ? ನನ್ನ ವೈಯಕ್ತಿಕ ಭಾವನೆ ಮತ್ತು ಫ್ಲಾಂಟ್ ಕಂಪನಿಯ ಒಟ್ಟಾರೆ ಸ್ಥಾನವೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ವಾಸ್ತವಿಕ ಮಾನದಂಡವಾಗಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಹೊರತುಪಡಿಸಿ ಬೇರೇನೂ ಇರುವುದಿಲ್ಲ.
ಇದು ಮೂಲಸೌಕರ್ಯ ನಿರ್ವಹಣೆಯ ಕ್ಷೇತ್ರದಲ್ಲಿ ಸಂಪೂರ್ಣ ಆಟದ ಬದಲಾವಣೆಯಾಗಿದೆ. ಕೇವಲ ಸಂಪೂರ್ಣ - ಅಷ್ಟೇ, ಇನ್ನು ಮುಂದೆ ಅನ್ಸಿಬಲ್, ಬಾಣಸಿಗ, ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು, ಟೆರಾಫಾರ್ಮ್ ಇಲ್ಲ. ನಾನು ಹಳೆಯ ಸಾಮೂಹಿಕ ಕೃಷಿ ವಿಧಾನಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ. ಕುಬರ್ನೆಟ್ಸ್ ಒಂದು ಸಂಪೂರ್ಣ ಬದಲಾವಣೆ, ಮತ್ತು ಈಗ ಅದು ಈ ರೀತಿ ಇರುತ್ತದೆ.
ಇದನ್ನು ಅರಿತುಕೊಳ್ಳಲು ಕೆಲವರಿಗೆ ಒಂದೆರಡು ವರ್ಷಗಳು, ಇನ್ನು ಕೆಲವರಿಗೆ ಒಂದೆರಡು ದಶಕಗಳೇ ಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟ. ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಈ ಹೊಸ ನೋಟವನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೇನೂ ಇರುವುದಿಲ್ಲ ಎಂದು ನನಗೆ ಸಂದೇಹವಿಲ್ಲ: ನಾವು ಇನ್ನು ಮುಂದೆ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹಾನಿಗೊಳಿಸುವುದಿಲ್ಲ, ಆದರೆ ಬಳಸುತ್ತೇವೆ. ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ, ಕೋಡ್‌ನೊಂದಿಗೆ ಮಾತ್ರವಲ್ಲ, ಆದರೆ yml ನೊಂದಿಗೆ - ಘೋಷಣಾತ್ಮಕವಾಗಿ ವಿವರಿಸಿದ ಮೂಲಸೌಕರ್ಯ. ಸದಾ ಹೀಗೇ ಇರುತ್ತದೆ ಎಂಬ ಭಾವನೆ ನನ್ನದು.
— ಅಂದರೆ, ಇನ್ನೂ ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಬದಲಾಯಿಸದ ಕಂಪನಿಗಳು ಖಂಡಿತವಾಗಿಯೂ ಅದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತವೆ ಅಥವಾ ಮರೆವುಗಳಲ್ಲಿ ಉಳಿಯುತ್ತವೆ. ನಾನು ನಿನ್ನನ್ನು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆಯೇ?
ಡಿಮಿಟ್ರಿ: ಇದು ಕೂಡ ಸಂಪೂರ್ಣ ಸತ್ಯವಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನಾವು DNS ಸರ್ವರ್ ಅನ್ನು ಚಲಾಯಿಸುವ ಕೆಲಸವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಅದನ್ನು FreeBSD 4.10 ನಲ್ಲಿ ರನ್ ಮಾಡಬಹುದು ಮತ್ತು ಇದು 20 ವರ್ಷಗಳವರೆಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು. ಕೇವಲ ಕೆಲಸ ಮತ್ತು ಅಷ್ಟೆ. ಬಹುಶಃ 20 ವರ್ಷಗಳಲ್ಲಿ ಏನನ್ನಾದರೂ ಒಮ್ಮೆ ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ. ನಾವು ಪ್ರಾರಂಭಿಸಿದ ಸ್ವರೂಪದಲ್ಲಿ ನಾವು ಸಾಫ್ಟ್‌ವೇರ್ ಕುರಿತು ಮಾತನಾಡುತ್ತಿದ್ದರೆ ಮತ್ತು ಅದು ಯಾವುದೇ ನವೀಕರಣಗಳಿಲ್ಲದೆ, ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡದೆಯೇ ಹಲವು ವರ್ಷಗಳವರೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಸಹಜವಾಗಿ, ಯಾವುದೇ ಕುಬರ್ನೆಟ್‌ಗಳು ಇರುವುದಿಲ್ಲ. ಅಲ್ಲಿ ಅವನ ಅಗತ್ಯವಿಲ್ಲ.
CI/CD ಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವೂ - ಎಲ್ಲೆಲ್ಲಿ ನಿರಂತರ ವಿತರಣೆ ಅಗತ್ಯವಿದೆಯೋ, ಅಲ್ಲಿ ನೀವು ಆವೃತ್ತಿಗಳನ್ನು ನವೀಕರಿಸಬೇಕು, ಸಕ್ರಿಯ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಎಲ್ಲಿ ನೀವು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ನಿರ್ಮಿಸಬೇಕು - ಕುಬರ್ನೆಟ್ಸ್ ಮಾತ್ರ.
ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳ ಬಗ್ಗೆ
- ಇಲ್ಲಿ ನನಗೆ ಸ್ವಲ್ಪ ಅಪಶ್ರುತಿ ಇದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆ ಕೆಲಸ ಮಾಡಲು, ನಿಮಗೆ ಬಾಹ್ಯ ಅಥವಾ ಆಂತರಿಕ ಬೆಂಬಲ ಬೇಕು - ಇದು ಮೊದಲ ಅಂಶವಾಗಿದೆ. ಎರಡನೆಯದಾಗಿ, ನಾವು ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಿರುವಾಗ, ನಾವು ಒಂದು ಸಣ್ಣ ಪ್ರಾರಂಭಿಕರಾಗಿದ್ದೇವೆ, ನಾವು ಇನ್ನೂ ಏನನ್ನೂ ಹೊಂದಿಲ್ಲ, ಸಾಮಾನ್ಯವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಅಥವಾ ಮೈಕ್ರೋಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅಭಿವೃದ್ಧಿಯು ಸಂಕೀರ್ಣವಾಗಬಹುದು ಮತ್ತು ಯಾವಾಗಲೂ ಆರ್ಥಿಕವಾಗಿ ಸಮರ್ಥಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ - ಪ್ರಾರಂಭಗಳು ತಕ್ಷಣವೇ ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಮೊದಲಿನಿಂದಲೂ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಬೇಕೇ ಅಥವಾ ಅವರು ಇನ್ನೂ ಏಕಶಿಲೆಯನ್ನು ಬರೆಯಬಹುದೇ ಮತ್ತು ನಂತರ ಮಾತ್ರ ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಬರಬಹುದೇ?
ಡಿಮಿಟ್ರಿ: ಕೂಲ್ ಪ್ರಶ್ನೆ. ಮೈಕ್ರೊ ಸರ್ವೀಸಸ್ ಬಗ್ಗೆ ನನ್ನ ಬಳಿ ಮಾತನಾಡಿದೆ ಸೂಕ್ಷ್ಮದರ್ಶಕದಿಂದ ಉಗುರುಗಳನ್ನು ಹೊಡೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಜನರನ್ನು ನಾನು ಅನೇಕ ಬಾರಿ ಎದುರಿಸಿದ್ದೇನೆ. ವಿಧಾನವು ಸರಿಯಾಗಿದೆ; ನಾವು ನಮ್ಮ ಆಂತರಿಕ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತೇವೆ. ಆದರೆ ನೀವು ಇದನ್ನು ಮಾಡುವಾಗ, ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಬಗ್ಗೆ ನಾನು ಹೆಚ್ಚು ದ್ವೇಷಿಸುವ ಪದ "ಮೈಕ್ರೋ". ಐತಿಹಾಸಿಕವಾಗಿ, ಈ ಪದವು ಅಲ್ಲಿ ಹುಟ್ಟಿಕೊಂಡಿತು, ಮತ್ತು ಕೆಲವು ಕಾರಣಗಳಿಂದ ಜನರು ಮೈಕ್ರೋ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಮೈಕ್ರೋಮೀಟರ್ನಂತೆ ಮಿಲಿಮೀಟರ್ಗಿಂತ ಕಡಿಮೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಇದು ತಪ್ಪು.
ಉದಾಹರಣೆಗೆ, 300 ಜನರು ಬರೆದ ಏಕಶಿಲೆ ಇದೆ, ಮತ್ತು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಭಾಗವಹಿಸಿದ ಪ್ರತಿಯೊಬ್ಬರೂ ಅಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಸೂಕ್ಷ್ಮ ತುಂಡುಗಳಾಗಿ ವಿಭಜಿಸಬೇಕು - ಸುಮಾರು 10 ತುಣುಕುಗಳು, ಪ್ರತಿಯೊಂದೂ 30 ಜನರು ಬರೆದಿದ್ದಾರೆ. ಕನಿಷ್ಠ ಆವೃತ್ತಿಯಲ್ಲಿ. ಇದು ಮುಖ್ಯ, ಅಗತ್ಯ ಮತ್ತು ತಂಪಾಗಿದೆ. ಆದರೆ ಪ್ರಾರಂಭವು ನಮ್ಮ ಬಳಿಗೆ ಬಂದಾಗ, ಅಲ್ಲಿ 3 ಅತ್ಯಂತ ತಂಪಾದ ಮತ್ತು ಪ್ರತಿಭಾವಂತ ವ್ಯಕ್ತಿಗಳು ತಮ್ಮ ಮೊಣಕಾಲುಗಳ ಮೇಲೆ 60 ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳನ್ನು ಬರೆದಿದ್ದಾರೆ, ಪ್ರತಿ ಬಾರಿ ನಾನು ಕೊರ್ವಾಲೋಲ್ ಅನ್ನು ಹುಡುಕುತ್ತೇನೆ.
ಇದನ್ನು ಈಗಾಗಲೇ ಸಾವಿರಾರು ಬಾರಿ ಮಾತನಾಡಲಾಗಿದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ - ನಾವು ಒಂದು ರೂಪದಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದರಲ್ಲಿ ವಿತರಿಸಿದ ಏಕಶಿಲೆಯನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಇದು ಆರ್ಥಿಕವಾಗಿ ಸಮರ್ಥಿಸಲ್ಪಟ್ಟಿಲ್ಲ, ಎಲ್ಲದರಲ್ಲೂ ಸಾಮಾನ್ಯವಾಗಿ ತುಂಬಾ ಕಷ್ಟ. ನಾನು ಇದನ್ನು ಹಲವು ಬಾರಿ ನೋಡಿದ್ದೇನೆ ಅದು ನನಗೆ ನಿಜವಾಗಿಯೂ ನೋವುಂಟುಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾನು ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇನೆ.
ಆರಂಭಿಕ ಪ್ರಶ್ನೆಗೆ, ಒಂದು ಕಡೆ, ಕುಬರ್ನೆಟ್ಸ್ ಬಳಸಲು ಹೆದರಿಕೆಯೆ ಎಂಬ ಅಂಶದ ನಡುವೆ ಸಂಘರ್ಷವಿದೆ, ಏಕೆಂದರೆ ಅಲ್ಲಿ ಏನು ಮುರಿಯಬಹುದು ಅಥವಾ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಮತ್ತೊಂದೆಡೆ, ಎಲ್ಲವೂ ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಹೊರತುಪಡಿಸಿ ಬೇರೇನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಉತ್ತರ - ಬರುವ ಪ್ರಯೋಜನದ ಪ್ರಮಾಣವನ್ನು, ನೀವು ಪರಿಹರಿಸಬಹುದಾದ ಕಾರ್ಯಗಳ ಪ್ರಮಾಣವನ್ನು ಅಳೆಯಿರಿ. ಇದು ಪ್ರಮಾಣದ ಒಂದು ಬದಿಯಲ್ಲಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಅಲಭ್ಯತೆ ಅಥವಾ ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ ಇಳಿಕೆ, ಲಭ್ಯತೆಯ ಮಟ್ಟ - ಕಾರ್ಯಕ್ಷಮತೆಯ ಸೂಚಕಗಳಲ್ಲಿನ ಇಳಿಕೆಗೆ ಸಂಬಂಧಿಸಿದ ಅಪಾಯಗಳಿವೆ.
ಇದು ಇಲ್ಲಿದೆ - ಒಂದೋ ನಾವು ತ್ವರಿತವಾಗಿ ಚಲಿಸುತ್ತೇವೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ನಮಗೆ ಅನೇಕ ಕೆಲಸಗಳನ್ನು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಮತ್ತು ಉತ್ತಮವಾಗಿ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಅಥವಾ ನಾವು ವಿಶ್ವಾಸಾರ್ಹ, ಸಮಯ-ಪರೀಕ್ಷಿತ ಪರಿಹಾರಗಳನ್ನು ಬಳಸುತ್ತೇವೆ, ಆದರೆ ಹೆಚ್ಚು ನಿಧಾನವಾಗಿ ಚಲಿಸುತ್ತೇವೆ. ಇದು ಪ್ರತಿ ಕಂಪನಿಯು ಮಾಡಬೇಕಾದ ಆಯ್ಕೆಯಾಗಿದೆ. ನೀವು ಇದನ್ನು ಕಾಡಿನಲ್ಲಿ ಒಂದು ಮಾರ್ಗವೆಂದು ಭಾವಿಸಬಹುದು - ನೀವು ಮೊದಲ ಬಾರಿಗೆ ನಡೆದಾಗ, ನೀವು ಹಾವು, ಹುಲಿ ಅಥವಾ ಹುಚ್ಚು ಬ್ಯಾಡ್ಜರ್ ಅನ್ನು ಭೇಟಿ ಮಾಡಬಹುದು, ಮತ್ತು ನೀವು 10 ಬಾರಿ ನಡೆದಾಗ, ನೀವು ಹಾದಿಯನ್ನು ತುಳಿದು ತೆಗೆದುಹಾಕಿದ್ದೀರಿ. ಶಾಖೆಗಳು ಮತ್ತು ಸುಲಭವಾಗಿ ನಡೆಯಿರಿ. ಪ್ರತಿ ಬಾರಿಯೂ ದಾರಿ ವಿಸ್ತಾರವಾಗುತ್ತದೆ. ನಂತರ ಅದು ಡಾಂಬರು ರಸ್ತೆ, ಮತ್ತು ನಂತರ ಸುಂದರವಾದ ಬುಲೆವಾರ್ಡ್.
ಕುಬರ್ನೆಟ್ಸ್ ಇನ್ನೂ ನಿಲ್ಲುವುದಿಲ್ಲ. ಮತ್ತೊಮ್ಮೆ ಪ್ರಶ್ನೆ: ಕುಬರ್ನೆಟ್ಸ್, ಒಂದು ಕಡೆ, 4-5 ಬೈನರಿಗಳು, ಮತ್ತೊಂದೆಡೆ, ಇದು ಸಂಪೂರ್ಣ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಇದು ನಮ್ಮ ಯಂತ್ರಗಳಲ್ಲಿ ನಾವು ಹೊಂದಿರುವ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಆಗಿದೆ. ಇದು ಏನು? ಉಬುಂಟು ಅಥವಾ ಕ್ಯೂರಿಯೋಸ್? ಇದು ಲಿನಕ್ಸ್ ಕರ್ನಲ್, ಹೆಚ್ಚುವರಿ ಘಟಕಗಳ ಗುಂಪಾಗಿದೆ. ಈ ಎಲ್ಲಾ ವಸ್ತುಗಳು ಇಲ್ಲಿ, ಒಂದು ವಿಷಕಾರಿ ಹಾವನ್ನು ರಸ್ತೆಯಿಂದ ಹೊರಹಾಕಲಾಯಿತು, ಅಲ್ಲಿ ಬೇಲಿಯನ್ನು ನಿರ್ಮಿಸಲಾಯಿತು. ಕುಬರ್ನೆಟ್ಸ್ ಬಹಳ ವೇಗವಾಗಿ ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ, ಮತ್ತು ಅಪಾಯಗಳ ಪ್ರಮಾಣ, ಅಜ್ಞಾತ ಪ್ರಮಾಣವು ಪ್ರತಿ ತಿಂಗಳು ಕಡಿಮೆಯಾಗುತ್ತಿದೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಈ ಮಾಪಕಗಳು ಮರುಸಮತೋಲನಗೊಳ್ಳುತ್ತಿವೆ.
ಸ್ಟಾರ್ಟ್ಅಪ್ ಏನು ಮಾಡಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತಾ, ನಾನು ಹೇಳುತ್ತೇನೆ - ಫ್ಲೌಂಟ್ಗೆ ಬನ್ನಿ, 150 ಸಾವಿರ ರೂಬಲ್ಸ್ಗಳನ್ನು ಪಾವತಿಸಿ ಮತ್ತು ಟರ್ನ್ಕೀ ಡೆವೊಪ್ಸ್ ಸುಲಭ ಸೇವೆಯನ್ನು ಪಡೆಯಿರಿ. ನೀವು ಕೆಲವು ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಸಣ್ಣ ಪ್ರಾರಂಭದವರಾಗಿದ್ದರೆ, ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಿಮ್ಮ ಸ್ವಂತ DevOps ಅನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುವ ಬದಲು, ನಿಮ್ಮ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಸಂಬಳವನ್ನು ಪಾವತಿಸುವುದು ಹೇಗೆ ಎಂಬುದನ್ನು ಕಲಿಯುವ ಅಗತ್ಯವಿದೆ, ನೀವು ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳಿಗೆ ಟರ್ನ್ಕೀ ಪರಿಹಾರವನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಹೌದು, ಕೆಲವು ಅನಾನುಕೂಲತೆಗಳಿವೆ. ನಾವು, ಹೊರಗುತ್ತಿಗೆದಾರರಾಗಿ, ಆದ್ದರಿಂದ ತೊಡಗಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ಬದಲಾವಣೆಗಳಿಗೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆದರೆ ನಮ್ಮಲ್ಲಿ ಸಾಕಷ್ಟು ಪರಿಣತಿ ಮತ್ತು ಸಿದ್ಧ ಅಭ್ಯಾಸಗಳಿವೆ. ಯಾವುದೇ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಯಾವುದೇ ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಸತ್ತವರಿಂದ ಎಬ್ಬಿಸುತ್ತೇವೆ ಎಂದು ನಾವು ಖಾತರಿಪಡಿಸುತ್ತೇವೆ.
ನೀವು 10 ಜನರ ತಂಡವನ್ನು ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಮೀಸಲಿಡಬಹುದಾದ ಗಾತ್ರದವರೆಗೆ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳು ಮತ್ತು ಸ್ಥಾಪಿತ ವ್ಯವಹಾರಗಳಿಗೆ ಹೊರಗುತ್ತಿಗೆಯನ್ನು ನಾನು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ಇಲ್ಲದಿದ್ದರೆ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ಇದನ್ನು ಹೊರಗುತ್ತಿಗೆ ಮಾಡುವುದು ಖಂಡಿತವಾಗಿಯೂ ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ.
Amazon ಮತ್ತು Google ಕುರಿತು
— Amazon ಅಥವಾ Google ನಿಂದ ಪರಿಹಾರದಿಂದ ಹೋಸ್ಟ್ ಅನ್ನು ಹೊರಗುತ್ತಿಗೆ ಎಂದು ಪರಿಗಣಿಸಬಹುದೇ?
ಡಿಮಿಟ್ರಿ: ಹೌದು, ಸಹಜವಾಗಿ, ಇದು ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಆದರೆ ಮತ್ತೆ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ. ಅದನ್ನು ಹೇಗೆ ಬಳಸಬೇಕೆಂದು ನೀವು ಇನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಉದಾಹರಣೆಗೆ, ಅಮೆಜಾನ್ ಎಡಬ್ಲ್ಯೂಎಸ್‌ನ ಕೆಲಸದಲ್ಲಿ ಸಾವಿರ ಸಣ್ಣ ವಿಷಯಗಳಿವೆ: ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಬೆಚ್ಚಗಾಗಿಸಬೇಕು ಅಥವಾ "ಹುಡುಗರೇ, ನಾವು ದಟ್ಟಣೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ, ನಮಗಾಗಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಬೆಚ್ಚಗಾಗಿಸಿ!" ಎಂದು ವಿನಂತಿಯನ್ನು ಮುಂಚಿತವಾಗಿ ಬರೆಯಬೇಕು. ಈ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು.
ಇದರಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿರುವ ಜನರ ಕಡೆಗೆ ನೀವು ತಿರುಗಿದಾಗ, ನೀವು ಬಹುತೇಕ ಎಲ್ಲಾ ವಿಶಿಷ್ಟ ವಿಷಯಗಳನ್ನು ಮುಚ್ಚುತ್ತೀರಿ. ನಾವು ಈಗ 40 ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ವರ್ಷದ ಅಂತ್ಯದ ವೇಳೆಗೆ ಬಹುಶಃ 60 ಮಂದಿ ಇರುತ್ತಾರೆ - ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಈ ಎಲ್ಲಾ ವಿಷಯಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. ಕೆಲವು ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಮತ್ತೆ ಎದುರಿಸಿದರೂ, ನಾವು ತ್ವರಿತವಾಗಿ ಪರಸ್ಪರ ಕೇಳುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಬೇಕೆಂದು ತಿಳಿಯುತ್ತೇವೆ.
ಬಹುಶಃ ಉತ್ತರ - ಸಹಜವಾಗಿ, ಹೋಸ್ಟ್ ಮಾಡಿದ ಕಥೆಯು ಕೆಲವು ಭಾಗವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. ಈ ಹೋಸ್ಟರ್‌ಗಳನ್ನು ನಂಬಲು ನೀವು ಸಿದ್ಧರಿದ್ದೀರಾ ಮತ್ತು ಅವರು ನಿಮ್ಮ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆಯೇ ಎಂಬುದು ಪ್ರಶ್ನೆ. ಅಮೆಜಾನ್ ಮತ್ತು ಗೂಗಲ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿವೆ. ನಮ್ಮ ಎಲ್ಲಾ ಪ್ರಕರಣಗಳಿಗೆ - ನಿಖರವಾಗಿ. ನಮಗೆ ಯಾವುದೇ ಸಕಾರಾತ್ಮಕ ಅನುಭವಗಳಿಲ್ಲ. ನಾವು ಕೆಲಸ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದ ಎಲ್ಲಾ ಇತರ ಮೋಡಗಳು ಬಹಳಷ್ಟು ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ - Ager, ಮತ್ತು ರಷ್ಯಾದಲ್ಲಿ ಇರುವ ಎಲ್ಲವೂ, ಮತ್ತು ವಿವಿಧ ಅಳವಡಿಕೆಗಳಲ್ಲಿ ಎಲ್ಲಾ ರೀತಿಯ OpenStack: ಹೆಡ್ಸ್ಟರ್, ಓವರ್ಜ್ - ನಿಮಗೆ ಬೇಕಾದುದನ್ನು. ಅವರೆಲ್ಲರೂ ನೀವು ಪರಿಹರಿಸಲು ಬಯಸದ ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತಾರೆ.
ಆದ್ದರಿಂದ, ಉತ್ತರ ಹೌದು, ಆದರೆ, ವಾಸ್ತವವಾಗಿ, ಹೆಚ್ಚು ಪ್ರಬುದ್ಧ ಹೋಸ್ಟ್ ಮಾಡಿದ ಪರಿಹಾರಗಳಿಲ್ಲ.
ಕುಬರ್ನೆಟ್ಸ್ ಯಾರಿಗೆ ಬೇಕು?
- ಮತ್ತು ಇನ್ನೂ, ಕುಬರ್ನೆಟ್ಸ್ ಯಾರಿಗೆ ಬೇಕು? ಕುಬರ್ನೆಟ್ಸ್ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಬರುವ ವಿಶಿಷ್ಟವಾದ ಫ್ಲೌಂಟ್ ಕ್ಲೈಂಟ್ ಯಾರು ಈಗಾಗಲೇ ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಬದಲಾಯಿಸಬೇಕು?
ಡಿಮಿಟ್ರಿ: ಇದು ಆಸಕ್ತಿದಾಯಕ ಪ್ರಶ್ನೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಇದೀಗ, ಕುಬರ್ನೆಟ್ಸ್ನ ಹಿನ್ನೆಲೆಯಲ್ಲಿ, ಅನೇಕ ಜನರು ನಮ್ಮ ಬಳಿಗೆ ಬರುತ್ತಾರೆ: "ಗೈಸ್, ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ, ನಮಗಾಗಿ ಮಾಡಿ!" ನಾವು ಅವರಿಗೆ ಉತ್ತರಿಸುತ್ತೇವೆ: "ಮಹನೀಯರೇ, ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಮಾಡುವುದಿಲ್ಲ, ನಾವು ಪ್ರಾಡ್ ಮತ್ತು ಅದರೊಂದಿಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದ ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತೇವೆ." ಏಕೆಂದರೆ ಎಲ್ಲಾ CI/CD ಮತ್ತು ಈ ಸಂಪೂರ್ಣ ಕಥೆಯನ್ನು ಮಾಡದೆಯೇ ಉತ್ಪನ್ನವನ್ನು ಮಾಡಲು ಪ್ರಸ್ತುತ ಸರಳವಾಗಿ ಅಸಾಧ್ಯವಾಗಿದೆ. ಅಭಿವೃದ್ಧಿಯಿಂದ ಅಭಿವೃದ್ಧಿ, ನಂತರ ಶೋಷಣೆಯಿಂದ ಶೋಷಣೆ ಎಂಬ ವಿಭಜನೆಯಿಂದ ಎಲ್ಲರೂ ದೂರ ಸರಿದಿದ್ದಾರೆ.
ನಮ್ಮ ಗ್ರಾಹಕರು ವಿಭಿನ್ನ ವಿಷಯಗಳನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ, ಆದರೆ ಪ್ರತಿಯೊಬ್ಬರೂ ಅವರು ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರುವ ಕೆಲವು ಉತ್ತಮ ಪವಾಡಕ್ಕಾಗಿ ಕಾಯುತ್ತಿದ್ದಾರೆ, ಮತ್ತು ಈಗ - ಹಾಪ್! - ಕುಬರ್ನೆಟ್ಸ್ ಅವುಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆ. ಜನರು ಪವಾಡಗಳನ್ನು ನಂಬುತ್ತಾರೆ. ಅವರ ಮನಸ್ಸಿನಲ್ಲಿ ಯಾವುದೇ ಪವಾಡವಿಲ್ಲ ಎಂದು ಅವರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ, ಆದರೆ ಅವರ ಆತ್ಮದಲ್ಲಿ ಅವರು ಆಶಿಸುತ್ತಾರೆ - ಈ ಕುಬರ್ನೆಟ್ಸ್ ಈಗ ನಮಗೆ ಎಲ್ಲವನ್ನೂ ಪರಿಹರಿಸಿದರೆ, ಅವರು ಅದರ ಬಗ್ಗೆ ತುಂಬಾ ಮಾತನಾಡುತ್ತಾರೆ! ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅವನು ಈಗ - ಸೀನು! - ಮತ್ತು ಬೆಳ್ಳಿಯ ಗುಂಡು, ಸೀನು! - ಮತ್ತು ನಾವು 100% ಸಮಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳು ಉತ್ಪಾದನೆಗೆ 50 ಬಾರಿ ಬಿಡುಗಡೆ ಮಾಡಬಹುದು ಮತ್ತು ಅದು ಕ್ರ್ಯಾಶ್ ಆಗುವುದಿಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ, ಒಂದು ಪವಾಡ!
ಅಂತಹ ಜನರು ನಮ್ಮ ಬಳಿಗೆ ಬಂದಾಗ, ನಾವು ಹೇಳುತ್ತೇವೆ: "ಕ್ಷಮಿಸಿ, ಆದರೆ ಅಂತಹ ಪವಾಡವಿಲ್ಲ." ಆರೋಗ್ಯವಾಗಿರಲು, ನೀವು ಚೆನ್ನಾಗಿ ತಿನ್ನಬೇಕು ಮತ್ತು ವ್ಯಾಯಾಮ ಮಾಡಬೇಕು. ವಿಶ್ವಾಸಾರ್ಹ ಉತ್ಪನ್ನವನ್ನು ಹೊಂದಲು, ಅದನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಮಾಡಬೇಕಾಗಿದೆ. ಅನುಕೂಲಕರ CI/CD ಹೊಂದಲು, ನೀವು ಇದನ್ನು ಈ ರೀತಿ ಮಾಡಬೇಕಾಗಿದೆ. ಮಾಡಬೇಕಾದ ಕೆಲಸ ಬಹಳಷ್ಟಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಯಾರಿಗೆ ಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತಾ - ಯಾರಿಗೂ ಕುಬರ್ನೆಟ್ಸ್ ಅಗತ್ಯವಿಲ್ಲ.
ಕೆಲವರಿಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಬೇಕು ಎಂಬ ತಪ್ಪು ಕಲ್ಪನೆ ಇದೆ. ಜನರಿಗೆ ಅಗತ್ಯವಿದೆ, ಮೂಲಭೂತ ಸೌಕರ್ಯಗಳ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಅವರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಯೋಚಿಸುವುದು, ಅಧ್ಯಯನ ಮಾಡುವುದು ಮತ್ತು ಆಸಕ್ತಿಯನ್ನು ನಿಲ್ಲಿಸುವ ಆಳವಾದ ಅಗತ್ಯವನ್ನು ಅವರು ಹೊಂದಿರುತ್ತಾರೆ. ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಮತ್ತು ನಿಯೋಜಿಸಲು ಅವರು ಬಯಸುತ್ತಾರೆ. ಅವರಿಗೆ, ಕುಬರ್ನೆಟ್ಸ್ ಅವರು "ನಾವು ಅಲ್ಲಿ ಮಲಗಿದ್ದೇವೆ" ಅಥವಾ "ನಾವು ಹೊರಹೋಗಲು ಸಾಧ್ಯವಿಲ್ಲ" ಅಥವಾ ಇನ್ನೇನಾದರೂ ಕಥೆಯನ್ನು ಕೇಳುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ ಎಂಬ ಭರವಸೆಯಾಗಿದೆ.
ತಾಂತ್ರಿಕ ನಿರ್ದೇಶಕರು ಸಾಮಾನ್ಯವಾಗಿ ನಮ್ಮ ಬಳಿಗೆ ಬರುತ್ತಾರೆ. ಅವರು ಅವನಿಗೆ ಎರಡು ವಿಷಯಗಳನ್ನು ಕೇಳುತ್ತಾರೆ: ಒಂದೆಡೆ, ನಮಗೆ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನೀಡಿ, ಮತ್ತೊಂದೆಡೆ, ಸ್ಥಿರತೆ. ಅದನ್ನು ನೀವೇ ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಮಾಡಲು ನಾವು ಸಲಹೆ ನೀಡುತ್ತೇವೆ. ಬೆಳ್ಳಿಯ ಬುಲೆಟ್, ಅಥವಾ ಬದಲಿಗೆ ಬೆಳ್ಳಿ ಲೇಪಿತ, ನೀವು ಈ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಯೋಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ ಮತ್ತು ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತೀರಿ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಮುಚ್ಚುವ ವಿಶೇಷ ವ್ಯಕ್ತಿಗಳನ್ನು ನೀವು ಹೊಂದಿರುತ್ತೀರಿ.
ನಮಗೆ ಅಥವಾ ಯಾರಿಗಾದರೂ ಕುಬರ್ನೆಟ್ಸ್ ಅಗತ್ಯವಿದೆ ಎಂಬ ಮಾತುಗಳು ತಪ್ಪಾಗಿದೆ.
ನಿರ್ವಾಹಕರಿಗೆ ನಿಜವಾಗಿಯೂ ಕುಬರ್ನೆಟ್ಸ್ ಅಗತ್ಯವಿದೆ, ಏಕೆಂದರೆ ಇದು ನೀವು ಆಡಬಹುದಾದ ಮತ್ತು ಟಿಂಕರ್ ಮಾಡುವ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಆಟಿಕೆಯಾಗಿದೆ. ಪ್ರಾಮಾಣಿಕವಾಗಿರಲಿ - ಪ್ರತಿಯೊಬ್ಬರೂ ಆಟಿಕೆಗಳನ್ನು ಪ್ರೀತಿಸುತ್ತಾರೆ. ನಾವೆಲ್ಲರೂ ಎಲ್ಲೋ ಮಕ್ಕಳು, ಮತ್ತು ನಾವು ಹೊಸದನ್ನು ನೋಡಿದಾಗ, ನಾವು ಅದನ್ನು ಆಡಲು ಬಯಸುತ್ತೇವೆ. ಕೆಲವರಿಗೆ, ಇದನ್ನು ನಿರುತ್ಸಾಹಗೊಳಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಆಡಳಿತದಲ್ಲಿ, ಏಕೆಂದರೆ ಅವರು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಆಡಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಸರಳವಾಗಿ ಬಯಸದ ಹಂತಕ್ಕೆ ಈಗಾಗಲೇ ದಣಿದಿದ್ದಾರೆ. ಆದರೆ ಇದು ಯಾರಿಗೂ ಸಂಪೂರ್ಣವಾಗಿ ಕಳೆದುಹೋಗಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನಾನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಸಿಸ್ಟಮ್ ಆಡಳಿತ ಮತ್ತು DevOps ಕ್ಷೇತ್ರದಲ್ಲಿ ಆಟಿಕೆಗಳಿಂದ ಬೇಸತ್ತಿದ್ದರೆ, ನಾನು ಇನ್ನೂ ಆಟಿಕೆಗಳನ್ನು ಪ್ರೀತಿಸುತ್ತೇನೆ, ನಾನು ಇನ್ನೂ ಕೆಲವು ಹೊಸದನ್ನು ಖರೀದಿಸುತ್ತೇನೆ. ಎಲ್ಲಾ ಜನರು, ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು, ಇನ್ನೂ ಕೆಲವು ರೀತಿಯ ಆಟಿಕೆಗಳನ್ನು ಬಯಸುತ್ತಾರೆ.
ಉತ್ಪಾದನೆಯೊಂದಿಗೆ ಆಡುವ ಅಗತ್ಯವಿಲ್ಲ. ನಾನು ಏನು ಮಾಡಬಾರದು ಎಂದು ನಿರ್ದಿಷ್ಟವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಈಗ ನಾನು ಸಾಮೂಹಿಕವಾಗಿ ನೋಡುತ್ತೇನೆ: "ಓಹ್, ಹೊಸ ಆಟಿಕೆ!" - ಅವರು ಅದನ್ನು ಖರೀದಿಸಲು ಓಡಿ, ಅದನ್ನು ಖರೀದಿಸಿದರು ಮತ್ತು: "ನಾವು ಈಗ ಅದನ್ನು ಶಾಲೆಗೆ ತೆಗೆದುಕೊಂಡು ಹೋಗೋಣ ಮತ್ತು ನಮ್ಮ ಎಲ್ಲಾ ಸ್ನೇಹಿತರಿಗೆ ತೋರಿಸೋಣ." ಹಾಗೆ ಮಾಡಬೇಡ. ನಾನು ಕ್ಷಮೆಯಾಚಿಸುತ್ತೇನೆ, ನನ್ನ ಮಕ್ಕಳು ಈಗಷ್ಟೇ ಬೆಳೆಯುತ್ತಿದ್ದಾರೆ, ನಾನು ನಿರಂತರವಾಗಿ ಮಕ್ಕಳಲ್ಲಿ ಏನನ್ನಾದರೂ ನೋಡುತ್ತೇನೆ, ಅದನ್ನು ನನ್ನಲ್ಲಿ ಗಮನಿಸುತ್ತೇನೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಇತರರಿಗೆ ಸಾಮಾನ್ಯೀಕರಿಸುತ್ತೇನೆ.
ಅಂತಿಮ ಉತ್ತರ: ನಿಮಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಅಗತ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ಸಮಸ್ಯೆಗಳನ್ನು ನೀವು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ.
ನೀವು ಏನು ಸಾಧಿಸಬಹುದು:
- ಪ್ರಾಡ್ ಬೀಳುವುದಿಲ್ಲ;
- ಅವನು ಬೀಳಲು ಪ್ರಯತ್ನಿಸಿದರೂ, ಅದರ ಬಗ್ಗೆ ನಮಗೆ ಮೊದಲೇ ತಿಳಿದಿದೆ ಮತ್ತು ನಾವು ಅದರಲ್ಲಿ ಏನನ್ನಾದರೂ ಹಾಕಬಹುದು;
- ನಮ್ಮ ವ್ಯವಹಾರಕ್ಕೆ ಅಗತ್ಯವಿರುವ ವೇಗದಲ್ಲಿ ನಾವು ಅದನ್ನು ಬದಲಾಯಿಸಬಹುದು ಮತ್ತು ನಾವು ಅದನ್ನು ಅನುಕೂಲಕರವಾಗಿ ಮಾಡಬಹುದು; ಇದು ನಮಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ.
ಎರಡು ನೈಜ ಅಗತ್ಯತೆಗಳಿವೆ: ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಚೈತನ್ಯ/ ರೋಲ್‌ಔಟ್‌ನ ನಮ್ಯತೆ. ಪ್ರಸ್ತುತ ಕೆಲವು ರೀತಿಯ ಐಟಿ ಯೋಜನೆಗಳನ್ನು ಮಾಡುತ್ತಿರುವ ಪ್ರತಿಯೊಬ್ಬರೂ, ಯಾವುದೇ ರೀತಿಯ ವ್ಯವಹಾರದಲ್ಲಿ - ಜಗತ್ತನ್ನು ಸರಾಗಗೊಳಿಸುವ ಮೃದುವಾದ ಮತ್ತು ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಪ್ರತಿಯೊಬ್ಬರೂ ಈ ಅಗತ್ಯಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ. ಸರಿಯಾದ ವಿಧಾನವನ್ನು ಹೊಂದಿರುವ ಕುಬರ್ನೆಟ್ಸ್, ಸರಿಯಾದ ತಿಳುವಳಿಕೆ ಮತ್ತು ಸಾಕಷ್ಟು ಅನುಭವದೊಂದಿಗೆ ಅವುಗಳನ್ನು ಪರಿಹರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಸರ್ವರ್‌ಲೆಸ್ ಬಗ್ಗೆ
— ನೀವು ಭವಿಷ್ಯದಲ್ಲಿ ಸ್ವಲ್ಪ ಮುಂದೆ ನೋಡಿದರೆ, ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ತಲೆನೋವಿನ ಅನುಪಸ್ಥಿತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಾಗ, ರೋಲ್ಔಟ್ ವೇಗ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬದಲಾವಣೆಗಳ ವೇಗದೊಂದಿಗೆ, ಹೊಸ ಪರಿಹಾರಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಉದಾಹರಣೆಗೆ, ಸರ್ವರ್‌ಲೆಸ್. ಈ ದಿಕ್ಕಿನಲ್ಲಿ ನೀವು ಯಾವುದೇ ಸಂಭಾವ್ಯತೆಯನ್ನು ಅನುಭವಿಸುತ್ತೀರಾ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಅಂತಹುದೇ ಪರಿಹಾರಗಳಿಗೆ ಅಪಾಯವನ್ನು ಹೇಳೋಣ?
ಡಿಮಿಟ್ರಿ: ಇಲ್ಲಿ ನಾವು ಮತ್ತೆ ಒಂದು ಟೀಕೆ ಮಾಡಬೇಕಾಗಿದೆ, ನಾನು ಮುಂದೆ ನೋಡುವ ಮತ್ತು ಹೇಳುವ ನೋಡುವವನಲ್ಲ - ಅದು ಹೀಗಿರುತ್ತದೆ! ನಾನು ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡಿದರೂ. ನಾನು ನನ್ನ ಪಾದಗಳನ್ನು ನೋಡುತ್ತೇನೆ ಮತ್ತು ಅಲ್ಲಿ ಸಮಸ್ಯೆಗಳ ಗುಂಪನ್ನು ನೋಡುತ್ತೇನೆ, ಉದಾಹರಣೆಗೆ, ಕಂಪ್ಯೂಟರ್ನಲ್ಲಿ ಟ್ರಾನ್ಸಿಸ್ಟರ್ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಇದು ತಮಾಷೆಯಾಗಿದೆ, ಸರಿ? ನಾವು CPU ನಲ್ಲಿ ಕೆಲವು ದೋಷಗಳನ್ನು ಎದುರಿಸುತ್ತಿದ್ದೇವೆ.
ಸರ್ವರ್‌ಲೆಸ್ ಅನ್ನು ಸಾಕಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹ, ಅಗ್ಗದ, ಪರಿಣಾಮಕಾರಿ ಮತ್ತು ಅನುಕೂಲಕರವಾಗಿಸಿ, ಎಲ್ಲಾ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿ. ಇಲ್ಲಿ ನಾನು ಎಲೋನ್ ಮಸ್ಕ್ ಜೊತೆ ಒಪ್ಪುತ್ತೇನೆ, ಮಾನವೀಯತೆಯ ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯನ್ನು ಸೃಷ್ಟಿಸಲು ಎರಡನೇ ಗ್ರಹದ ಅಗತ್ಯವಿದೆ. ಅವನು ಏನು ಹೇಳುತ್ತಿದ್ದಾನೆಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲವಾದರೂ, ನಾನು ಮಂಗಳ ಗ್ರಹಕ್ಕೆ ಹಾರಲು ಸಿದ್ಧವಾಗಿಲ್ಲ ಮತ್ತು ನಾಳೆ ಅದು ಸಂಭವಿಸುವುದಿಲ್ಲ ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ.
ಸರ್ವರ್‌ಲೆಸ್‌ನೊಂದಿಗೆ ಇದು ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಸರಿಯಾದ ವಿಷಯ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ, ಮಾನವೀಯತೆಯ ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯಂತೆ - ಎರಡು ಗ್ರಹಗಳನ್ನು ಹೊಂದಿರುವುದು ಒಂದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ. ಆದರೆ ಈಗ ಅದನ್ನು ಹೇಗೆ ಮಾಡುವುದು? ನಿಮ್ಮ ಪ್ರಯತ್ನಗಳನ್ನು ನೀವು ಕೇಂದ್ರೀಕರಿಸಿದರೆ ಒಂದು ದಂಡಯಾತ್ರೆಯನ್ನು ಕಳುಹಿಸುವುದು ಸಮಸ್ಯೆಯಲ್ಲ. ಹಲವಾರು ದಂಡಯಾತ್ರೆಗಳನ್ನು ಕಳುಹಿಸುವುದು ಮತ್ತು ಹಲವಾರು ಸಾವಿರ ಜನರನ್ನು ಅಲ್ಲಿ ನೆಲೆಗೊಳಿಸುವುದು ಸಹ ವಾಸ್ತವಿಕವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಆದರೆ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ದೋಷ-ಸಹಿಷ್ಣುಗೊಳಿಸುವಂತೆ ಮಾಡಲು, ಅರ್ಧದಷ್ಟು ಮಾನವೀಯತೆಯು ಅಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಅದು ಈಗ ನನಗೆ ಅಸಾಧ್ಯವೆಂದು ತೋರುತ್ತದೆ, ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ.
ಸರ್ವರ್‌ಲೆಸ್ ಒಂದರ ಮೇಲೆ: ವಿಷಯ ತಂಪಾಗಿದೆ, ಆದರೆ ಇದು 2019 ರ ಸಮಸ್ಯೆಗಳಿಂದ ದೂರವಿದೆ. 2030 ಕ್ಕೆ ಹತ್ತಿರದಲ್ಲಿದೆ - ಅದನ್ನು ನೋಡಲು ನಾವು ಬದುಕೋಣ. ನಾವು ಬದುಕುತ್ತೇವೆ ಎಂಬುದರಲ್ಲಿ ನನಗೆ ಸಂದೇಹವಿಲ್ಲ, ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಬದುಕುತ್ತೇವೆ (ಮಲಗುವ ಮೊದಲು ಪುನರಾವರ್ತಿಸಿ), ಆದರೆ ಈಗ ನಾವು ಇತರ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ. ಇದು ಕಾಲ್ಪನಿಕ ಕಥೆಯ ಕುದುರೆ ರೈನ್ಬೋ ಅನ್ನು ನಂಬುವಂತಿದೆ. ಹೌದು, ಒಂದೆರಡು ಪ್ರತಿಶತ ಪ್ರಕರಣಗಳನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ವ್ಯಕ್ತಿನಿಷ್ಠವಾಗಿ, ಸರ್ವರ್‌ಲೆಸ್ ಒಂದು ಮಳೆಬಿಲ್ಲು ... ನನಗೆ, ಈ ವಿಷಯವು ತುಂಬಾ ದೂರದಲ್ಲಿದೆ ಮತ್ತು ತುಂಬಾ ಅಗ್ರಾಹ್ಯವಾಗಿದೆ. ನಾನು ಮಾತನಾಡಲು ಸಿದ್ಧನಿಲ್ಲ. 2019 ರಲ್ಲಿ, ನೀವು ಸರ್ವರ್‌ಲೆಸ್‌ನೊಂದಿಗೆ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಕುಬರ್ನೆಟ್ಸ್ ಹೇಗೆ ವಿಕಸನಗೊಳ್ಳುತ್ತಾನೆ
— ನಾವು ಈ ಸಂಭಾವ್ಯ ಅದ್ಭುತ ದೂರದ ಭವಿಷ್ಯದತ್ತ ಸಾಗುತ್ತಿರುವಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಅದರ ಸುತ್ತಲಿನ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ಹೇಗೆ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತದೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ?
ಡಿಮಿಟ್ರಿ: ನಾನು ಈ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಯೋಚಿಸಿದೆ ಮತ್ತು ನನ್ನ ಬಳಿ ಸ್ಪಷ್ಟ ಉತ್ತರವಿದೆ. ಮೊದಲನೆಯದು ಸ್ಟೇಟ್‌ಫುಲ್ - ಎಲ್ಲಾ ನಂತರ, ಸ್ಟೇಟ್‌ಲೆಸ್ ಮಾಡುವುದು ಸುಲಭ. ಕುಬರ್ನೆಟ್ಸ್ ಆರಂಭದಲ್ಲಿ ಇದರಲ್ಲಿ ಹೆಚ್ಚು ಹೂಡಿಕೆ ಮಾಡಿದರು, ಅದು ಪ್ರಾರಂಭವಾಯಿತು. ಸ್ಥಿತಿಯಿಲ್ಲದ ಕೆಲಸಗಳು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ದೂರು ನೀಡಲು ಏನೂ ಇಲ್ಲ. ಇನ್ನೂ ಬಹಳಷ್ಟು ಸಮಸ್ಯೆಗಳಿವೆ, ಅಥವಾ ಬದಲಿಗೆ, ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು. ಅಲ್ಲಿ ಎಲ್ಲವೂ ಈಗಾಗಲೇ ನಮಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಅದು ನಮಗೆ. ಇದು ಎಲ್ಲರಿಗೂ ಕೆಲಸ ಮಾಡಲು ಇನ್ನೂ ಒಂದೆರಡು ವರ್ಷಗಳಾದರೂ ಬೇಕು. ಇದು ಲೆಕ್ಕಾಚಾರದ ಸೂಚಕವಲ್ಲ, ಆದರೆ ನನ್ನ ತಲೆಯಿಂದ ನನ್ನ ಭಾವನೆ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಸ್ಟೇಟ್‌ಫುಲ್ ಆಗಿರಬೇಕು - ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತದೆ - ಏಕೆಂದರೆ ನಮ್ಮ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತವೆ; ಯಾವುದೇ ಸ್ಥಿತಿಯಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಲ್ಲ. ಇದು ಭ್ರಮೆ; ನಿಮಗೆ ಯಾವಾಗಲೂ ಕೆಲವು ರೀತಿಯ ಡೇಟಾಬೇಸ್ ಮತ್ತು ಇನ್ನೇನಾದರೂ ಅಗತ್ಯವಿರುತ್ತದೆ. ಸ್ಟೇಟ್‌ಫುಲ್ ಎಂದರೆ ಸಾಧ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ನೇರಗೊಳಿಸುವುದು, ಎಲ್ಲಾ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವುದು, ಪ್ರಸ್ತುತ ಎದುರಿಸುತ್ತಿರುವ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಸುಧಾರಿಸುವುದು - ಅದನ್ನು ದತ್ತು ಎಂದು ಕರೆಯೋಣ.
ಅಜ್ಞಾತ ಮಟ್ಟ, ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಗಳ ಮಟ್ಟ, ಏನನ್ನಾದರೂ ಎದುರಿಸುವ ಸಂಭವನೀಯತೆಯ ಮಟ್ಟವು ಗಮನಾರ್ಹವಾಗಿ ಇಳಿಯುತ್ತದೆ. ಇದೊಂದು ಮಹತ್ವದ ಕಥೆ. ಮತ್ತು ನಿರ್ವಾಹಕರು - ಆಡಳಿತ ತರ್ಕದ ಕ್ರೋಡೀಕರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವೂ, ಸುಲಭವಾದ ಸೇವೆಯನ್ನು ಪಡೆಯಲು ತರ್ಕವನ್ನು ನಿಯಂತ್ರಿಸಿ: MySQL ಸುಲಭ ಸೇವೆ, RabbitMQ ಸುಲಭ ಸೇವೆ, Memcache ಸುಲಭ ಸೇವೆ - ಸಾಮಾನ್ಯವಾಗಿ, ಈ ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು ನಾವು ಕೆಲಸ ಮಾಡಲು ಖಾತರಿ ನೀಡಬೇಕಾಗಿದೆ. ಪೆಟ್ಟಿಗೆ. ಇದು ನಮಗೆ ಡೇಟಾಬೇಸ್ ಅಗತ್ಯವಿರುವ ನೋವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಆದರೆ ನಾವು ಅದನ್ನು ನಿರ್ವಹಿಸಲು ಬಯಸುವುದಿಲ್ಲ, ಅಥವಾ ನಮಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಬೇಕು, ಆದರೆ ನಾವು ಅದನ್ನು ನಿರ್ವಹಿಸಲು ಬಯಸುವುದಿಲ್ಲ.
ಒಂದಲ್ಲ ಒಂದು ರೂಪದಲ್ಲಿ ಆಪರೇಟರ್ ಅಭಿವೃದ್ಧಿಯ ಈ ಕಥೆಯು ಮುಂದಿನ ಒಂದೆರಡು ವರ್ಷಗಳಲ್ಲಿ ಮುಖ್ಯವಾಗುತ್ತದೆ.
ಬಳಕೆಯ ಸುಲಭತೆಯು ಹೆಚ್ಚು ಹೆಚ್ಚಾಗಬೇಕು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ - ಬಾಕ್ಸ್ ಹೆಚ್ಚು ಹೆಚ್ಚು ಕಪ್ಪು, ಹೆಚ್ಚು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ, ಹೆಚ್ಚು ಹೆಚ್ಚು ಸರಳವಾದ ಗುಬ್ಬಿಗಳೊಂದಿಗೆ ಆಗುತ್ತದೆ.
ಶನಿವಾರ ರಾತ್ರಿ ಲೈವ್‌ನಲ್ಲಿ YouTube ನಲ್ಲಿ 80 ರ ದಶಕದ ಐಸಾಕ್ ಅಸಿಮೊವ್ ಅವರ ಹಳೆಯ ಸಂದರ್ಶನವನ್ನು ನಾನು ಒಮ್ಮೆ ಕೇಳಿದೆ - ಅರ್ಜೆಂಟ್‌ನಂತಹ ಕಾರ್ಯಕ್ರಮ, ಕೇವಲ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಅವರು ಕಂಪ್ಯೂಟರ್‌ಗಳ ಭವಿಷ್ಯದ ಬಗ್ಗೆ ಕೇಳಿದರು. ಆಕಾಶವಾಣಿಯಂತೆ ಸರಳತೆಯಲ್ಲಿ ಭವಿಷ್ಯವಿದೆ ಎಂದರು. ರೇಡಿಯೋ ರಿಸೀವರ್ ಮೂಲತಃ ಸಂಕೀರ್ಣ ವಿಷಯವಾಗಿತ್ತು. ತರಂಗವನ್ನು ಹಿಡಿಯಲು, ನೀವು 15 ನಿಮಿಷಗಳ ಕಾಲ ಗುಬ್ಬಿಗಳನ್ನು ತಿರುಗಿಸಬೇಕು, ಓರೆಗಳನ್ನು ತಿರುಗಿಸಬೇಕು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲವೂ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ, ರೇಡಿಯೋ ತರಂಗ ಪ್ರಸರಣದ ಭೌತಶಾಸ್ತ್ರವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ಪರಿಣಾಮವಾಗಿ, ರೇಡಿಯೊದಲ್ಲಿ ಒಂದೇ ಒಂದು ಗುಬ್ಬಿ ಉಳಿದಿತ್ತು.
ಈಗ 2019 ರಲ್ಲಿ ಯಾವ ರೇಡಿಯೋ? ಕಾರಿನಲ್ಲಿ, ರೇಡಿಯೋ ರಿಸೀವರ್ ಎಲ್ಲಾ ಅಲೆಗಳು ಮತ್ತು ಕೇಂದ್ರಗಳ ಹೆಸರುಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ. ಪ್ರಕ್ರಿಯೆಯ ಭೌತಶಾಸ್ತ್ರವು 100 ವರ್ಷಗಳಲ್ಲಿ ಬದಲಾಗಿಲ್ಲ, ಆದರೆ ಬಳಕೆಯ ಸುಲಭತೆ ಹೊಂದಿದೆ. ಈಗ, ಮತ್ತು ಈಗ ಮಾತ್ರವಲ್ಲ, ಈಗಾಗಲೇ 1980 ರಲ್ಲಿ, ಅಜಿಮೊವ್ ಅವರೊಂದಿಗೆ ಸಂದರ್ಶನ ನಡೆದಾಗ, ಎಲ್ಲರೂ ರೇಡಿಯೊವನ್ನು ಬಳಸಿದರು ಮತ್ತು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಯಾರೂ ಯೋಚಿಸಲಿಲ್ಲ. ಇದು ಯಾವಾಗಲೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ - ಅದು ನೀಡಲಾಗಿದೆ.
ಅಜಿಮೊವ್ ನಂತರ ಇದು ಕಂಪ್ಯೂಟರ್‌ಗಳಂತೆಯೇ ಇರುತ್ತದೆ ಎಂದು ಹೇಳಿದರು - ಬಳಕೆಯ ಸುಲಭತೆ ಹೆಚ್ಚಾಗುತ್ತದೆ. 1980 ರಲ್ಲಿ ನೀವು ಕಂಪ್ಯೂಟರ್ನಲ್ಲಿ ಬಟನ್‌ಗಳನ್ನು ಒತ್ತಲು ತರಬೇತಿ ಪಡೆಯಬೇಕಾಗಿದ್ದರೂ, ಭವಿಷ್ಯದಲ್ಲಿ ಅದು ಆಗುವುದಿಲ್ಲ.
ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ಬಳಕೆಯ ಸುಲಭತೆಯಲ್ಲಿ ಭಾರಿ ಹೆಚ್ಚಳವಾಗಲಿದೆ ಎಂಬ ಭಾವನೆ ನನ್ನಲ್ಲಿದೆ. ಇದು ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿದೆ - ಇದು ಮೇಲ್ಮೈಯಲ್ಲಿದೆ.
ಎಂಜಿನಿಯರ್‌ಗಳೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು?
- ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬೆಂಬಲಿಸುವ ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರಿಗೆ ಏನಾಗುತ್ತದೆ?
ಡಿಮಿಟ್ರಿ: 1C ಬಂದ ನಂತರ ಅಕೌಂಟೆಂಟ್ ಏನಾಯಿತು? ಅದೇ ಬಗ್ಗೆ. ಇದಕ್ಕೂ ಮೊದಲು, ಅವರು ಕಾಗದದ ಮೇಲೆ ಎಣಿಸಿದರು - ಈಗ ಕಾರ್ಯಕ್ರಮದಲ್ಲಿ. ಕಾರ್ಮಿಕ ಉತ್ಪಾದಕತೆಯು ಪರಿಮಾಣದ ಆದೇಶಗಳಿಂದ ಹೆಚ್ಚಾಗಿದೆ, ಆದರೆ ಕಾರ್ಮಿಕ ಸ್ವತಃ ಕಣ್ಮರೆಯಾಗಿಲ್ಲ. ಈ ಹಿಂದೆ 10 ಎಂಜಿನಿಯರ್‌ಗಳು ಬಲ್ಬ್‌ನಲ್ಲಿ ಸ್ಕ್ರೂ ಮಾಡಲು ತೆಗೆದುಕೊಂಡಿದ್ದರೆ, ಈಗ ಒಬ್ಬರು ಸಾಕು.
ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಪ್ರಮಾಣ ಮತ್ತು ಕಾರ್ಯಗಳ ಸಂಖ್ಯೆಯು ಈಗ ಹೊಸ DevOps ಕಾಣಿಸಿಕೊಳ್ಳುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ ಮತ್ತು ದಕ್ಷತೆ ಹೆಚ್ಚುತ್ತಿದೆ. ಇದೀಗ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಕೊರತೆಯಿದೆ ಮತ್ತು ಇದು ದೀರ್ಘಕಾಲದವರೆಗೆ ಇರುತ್ತದೆ. ನಂತರ, ಎಲ್ಲವೂ ಕೆಲವು ರೀತಿಯ ಸಾಮಾನ್ಯತೆಗೆ ಮರಳುತ್ತದೆ, ಇದರಲ್ಲಿ ಕೆಲಸದ ದಕ್ಷತೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ, ಹೆಚ್ಚು ಹೆಚ್ಚು ಸರ್ವರ್‌ಲೆಸ್ ಇರುತ್ತದೆ, ಕುಬರ್ನೆಟ್ಸ್ಗೆ ನ್ಯೂರಾನ್ ಅನ್ನು ಜೋಡಿಸಲಾಗುತ್ತದೆ, ಅದು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಖರವಾಗಿ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲವನ್ನೂ ಸ್ವತಃ ಮಾಡಿ - ವ್ಯಕ್ತಿಯು ದೂರ ಸರಿಯುತ್ತಾನೆ ಮತ್ತು ಮಧ್ಯಪ್ರವೇಶಿಸಬೇಡ.
ಆದರೆ ಯಾರಾದರೂ ಇನ್ನೂ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಈ ವ್ಯಕ್ತಿಯ ಅರ್ಹತೆಗಳು ಮತ್ತು ವಿಶೇಷತೆಯ ಮಟ್ಟವು ಹೆಚ್ಚಾಗಿರುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ಲೆಕ್ಕಪತ್ರ ವಿಭಾಗದಲ್ಲಿ 10 ಉದ್ಯೋಗಿಗಳು ಕೈಗೆ ಸುಸ್ತಾಗದಂತೆ ಪುಸ್ತಕಗಳನ್ನು ಇಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ಸರಳವಾಗಿ ಅಗತ್ಯವಿಲ್ಲ. ಎಲೆಕ್ಟ್ರಾನಿಕ್ ಡಾಕ್ಯುಮೆಂಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್ನಿಂದ ಅನೇಕ ದಾಖಲೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಗುರುತಿಸಲಾಗುತ್ತದೆ. ಒಬ್ಬ ಸ್ಮಾರ್ಟ್ ಮುಖ್ಯ ಅಕೌಂಟೆಂಟ್ ಸಾಕು, ಈಗಾಗಲೇ ಹೆಚ್ಚಿನ ಕೌಶಲ್ಯಗಳನ್ನು ಹೊಂದಿರುವ, ಉತ್ತಮ ತಿಳುವಳಿಕೆಯೊಂದಿಗೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ಎಲ್ಲಾ ಉದ್ಯಮಗಳಲ್ಲಿ ಹೋಗಬೇಕಾದ ಮಾರ್ಗವಾಗಿದೆ. ಇದು ಕಾರುಗಳೊಂದಿಗೆ ಒಂದೇ ಆಗಿರುತ್ತದೆ: ಹಿಂದೆ, ಒಂದು ಕಾರು ಮೆಕ್ಯಾನಿಕ್ ಮತ್ತು ಮೂರು ಚಾಲಕರೊಂದಿಗೆ ಬಂದಿತು. ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ಕಾರನ್ನು ಚಾಲನೆ ಮಾಡುವುದು ಸರಳವಾದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು, ಇದರಲ್ಲಿ ನಾವೆಲ್ಲರೂ ಪ್ರತಿದಿನ ಭಾಗವಹಿಸುತ್ತೇವೆ. ಕಾರು ಯಾವುದೋ ಸಂಕೀರ್ಣವಾಗಿದೆ ಎಂದು ಯಾರೂ ಭಾವಿಸುವುದಿಲ್ಲ.
DevOps ಅಥವಾ ಸಿಸ್ಟಮ್ಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ದೂರವಾಗುವುದಿಲ್ಲ - ಉನ್ನತ ಮಟ್ಟದ ಕೆಲಸ ಮತ್ತು ದಕ್ಷತೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ.
- ಕೆಲಸವು ನಿಜವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ ಎಂಬ ಆಸಕ್ತಿದಾಯಕ ವಿಚಾರವನ್ನು ನಾನು ಕೇಳಿದೆ.
ಡಿಮಿಟ್ರಿ: ಖಂಡಿತ, ನೂರು ಪ್ರತಿಶತ! ಏಕೆಂದರೆ ನಾವು ಬರೆಯುವ ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ರಮಾಣವು ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ. ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ ನಾವು ಪರಿಹರಿಸುವ ಸಮಸ್ಯೆಗಳ ಸಂಖ್ಯೆ ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ. ಕೆಲಸದ ಪ್ರಮಾಣ ಬೆಳೆಯುತ್ತಿದೆ. ಈಗ DevOps ಮಾರುಕಟ್ಟೆಯು ತುಂಬಾ ಬಿಸಿಯಾಗಿದೆ. ಸಂಬಳದ ನಿರೀಕ್ಷೆಗಳಲ್ಲಿ ಇದನ್ನು ಕಾಣಬಹುದು. ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ, ವಿವರಗಳಿಗೆ ಹೋಗದೆ, X ಬಯಸುವ ಜೂನಿಯರ್‌ಗಳು, 1,5X ಬಯಸುವ ಮಧ್ಯಮರು ಮತ್ತು 2X ಬಯಸುವ ಹಿರಿಯರು ಇರಬೇಕು. ಮತ್ತು ಈಗ, ನೀವು ಮಾಸ್ಕೋ DevOps ಸಂಬಳ ಮಾರುಕಟ್ಟೆಯನ್ನು ನೋಡಿದರೆ, ಜೂನಿಯರ್ X ನಿಂದ 3X ವರೆಗೆ ಮತ್ತು ಹಿರಿಯರು X ನಿಂದ 3X ವರೆಗೆ ಬಯಸುತ್ತಾರೆ.
ಇದರ ಬೆಲೆ ಎಷ್ಟು ಎಂಬುದು ಯಾರಿಗೂ ತಿಳಿದಿಲ್ಲ. ಸಂಬಳದ ಮಟ್ಟವನ್ನು ನಿಮ್ಮ ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಅಳೆಯಲಾಗುತ್ತದೆ - ಸಂಪೂರ್ಣ ಹುಚ್ಚುಮನೆ, ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಭಯಂಕರವಾಗಿ ಬಿಸಿಯಾದ ಮಾರುಕಟ್ಟೆ.
ಸಹಜವಾಗಿ, ಈ ಪರಿಸ್ಥಿತಿಯು ಶೀಘ್ರದಲ್ಲೇ ಬದಲಾಗುತ್ತದೆ - ಕೆಲವು ಶುದ್ಧತ್ವವು ಸಂಭವಿಸಬೇಕು. ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಇದು ಹಾಗಲ್ಲ - ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಡೆವಲಪರ್‌ಗಳು ಬೇಕಾಗಿದ್ದಾರೆ ಮತ್ತು ಎಲ್ಲರಿಗೂ ಉತ್ತಮ ಡೆವಲಪರ್‌ಗಳು ಬೇಕಾಗಿದ್ದಾರೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಮಾರುಕಟ್ಟೆಯು ಯಾರಿಗೆ ಯೋಗ್ಯವಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ - ಉದ್ಯಮವು ನೆಲೆಸಿದೆ. ಈ ದಿನಗಳಲ್ಲಿ DevOps ವಿಷಯದಲ್ಲಿ ಹಾಗಲ್ಲ.
- ನಾನು ಕೇಳಿದ ಪ್ರಕಾರ, ಪ್ರಸ್ತುತ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಹೆಚ್ಚು ಚಿಂತಿಸಬಾರದು ಎಂದು ನಾನು ತೀರ್ಮಾನಿಸಿದೆ, ಆದರೆ ಇದು ಅವರ ಕೌಶಲ್ಯಗಳನ್ನು ನವೀಕರಿಸಲು ಮತ್ತು ನಾಳೆ ಹೆಚ್ಚಿನ ಕೆಲಸ ಇರುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ತಯಾರಿ ಮಾಡುವ ಸಮಯ, ಆದರೆ ಅದು ಹೆಚ್ಚು ಅರ್ಹವಾಗಿರುತ್ತದೆ.
ಡಿಮಿಟ್ರಿ: ನೂರು ಪ್ರತಿಶತ. ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು 2019 ರಲ್ಲಿ ವಾಸಿಸುತ್ತೇವೆ ಮತ್ತು ಜೀವನದ ನಿಯಮ ಹೀಗಿದೆ: ಜೀವಮಾನದ ಕಲಿಕೆ - ನಾವು ನಮ್ಮ ಜೀವನದುದ್ದಕ್ಕೂ ಕಲಿಯುತ್ತೇವೆ. ಈಗ ಪ್ರತಿಯೊಬ್ಬರೂ ಇದನ್ನು ಈಗಾಗಲೇ ತಿಳಿದಿದ್ದಾರೆ ಮತ್ತು ಅನುಭವಿಸುತ್ತಿದ್ದಾರೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ, ಆದರೆ ತಿಳಿದುಕೊಳ್ಳಲು ಇದು ಸಾಕಾಗುವುದಿಲ್ಲ - ನೀವು ಅದನ್ನು ಮಾಡಬೇಕು. ಪ್ರತಿದಿನ ನಾವು ಬದಲಾಗಬೇಕು. ನಾವು ಇದನ್ನು ಮಾಡದಿದ್ದರೆ, ಬೇಗ ಅಥವಾ ನಂತರ ನಾವು ವೃತ್ತಿಯ ಬದಿಗೆ ಬೀಳುತ್ತೇವೆ.
ತೀಕ್ಷ್ಣವಾದ 180-ಡಿಗ್ರಿ ತಿರುವುಗಳಿಗೆ ಸಿದ್ಧರಾಗಿರಿ. ಏನಾದರೂ ಆಮೂಲಾಗ್ರವಾಗಿ ಬದಲಾಗುವ, ಹೊಸದನ್ನು ಆವಿಷ್ಕರಿಸುವ ಪರಿಸ್ಥಿತಿಯನ್ನು ನಾನು ತಳ್ಳಿಹಾಕುವುದಿಲ್ಲ - ಅದು ಸಂಭವಿಸುತ್ತದೆ. ಹಾಪ್! - ಮತ್ತು ನಾವು ಈಗ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತೇವೆ. ಇದಕ್ಕಾಗಿ ಸಿದ್ಧರಾಗಿರಬೇಕು ಮತ್ತು ಚಿಂತಿಸಬಾರದು. ನಾಳೆ ನಾನು ಮಾಡುವ ಎಲ್ಲವೂ ಅನಗತ್ಯವಾಗಿ ಪರಿಣಮಿಸಬಹುದು - ಏನೂ ಇಲ್ಲ, ನಾನು ನನ್ನ ಜೀವನದುದ್ದಕ್ಕೂ ಅಧ್ಯಯನ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಕಲಿಯಲು ಸಿದ್ಧನಿದ್ದೇನೆ. ಅದು ಸಮಸ್ಯೆಯಲ್ಲ. ಉದ್ಯೋಗ ಭದ್ರತೆಯ ಬಗ್ಗೆ ಭಯಪಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ನಿರಂತರವಾಗಿ ಹೊಸದನ್ನು ಕಲಿಯಲು ನೀವು ಸಿದ್ಧರಾಗಿರಬೇಕು.
ಶುಭಾಶಯಗಳು ಮತ್ತು ಒಂದು ನಿಮಿಷದ ಜಾಹೀರಾತು
- ನಿಮಗೆ ಏನಾದರೂ ಆಸೆ ಇದೆಯೇ?
ಡಿಮಿಟ್ರಿ: ಹೌದು, ನನಗೆ ಹಲವಾರು ಆಸೆಗಳಿವೆ.
ಮೊದಲ ಮತ್ತು ಮರ್ಕೆಂಟೈಲ್ - ಚಂದಾದಾರರಾಗಿ . ಆತ್ಮೀಯ ಓದುಗರೇ, YouTube ಗೆ ಹೋಗಿ ಮತ್ತು ನಮ್ಮ ಚಾನಲ್‌ಗೆ ಚಂದಾದಾರರಾಗಿ. ಸುಮಾರು ಒಂದು ತಿಂಗಳಲ್ಲಿ ನಾವು ವೀಡಿಯೊ ಸೇವೆಯಲ್ಲಿ ಸಕ್ರಿಯ ವಿಸ್ತರಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಶೈಕ್ಷಣಿಕ ವಿಷಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಮುಕ್ತ ಮತ್ತು ವೈವಿಧ್ಯಮಯ: ಪ್ರಾಯೋಗಿಕ ವಿಷಯಗಳಿಂದ ಹಿಡಿದು ಪ್ರಯೋಗಾಲಯಗಳವರೆಗೆ, ಆಳವಾದ ಮೂಲಭೂತ ಸೈದ್ಧಾಂತಿಕ ವಿಷಯಗಳವರೆಗೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು ತತ್ವಗಳು ಮತ್ತು ಮಾದರಿಗಳ ಮಟ್ಟ.
ಎರಡನೇ ಮರ್ಕೆಂಟೈಲ್ ಹಾರೈಕೆ - ಹೋಗಿ ಮತ್ತು ನಕ್ಷತ್ರಗಳನ್ನು ಹಾಕುತ್ತೇವೆ ಏಕೆಂದರೆ ನಾವು ಅವುಗಳನ್ನು ತಿನ್ನುತ್ತೇವೆ. ನೀವು ನಮಗೆ ನಕ್ಷತ್ರಗಳನ್ನು ನೀಡದಿದ್ದರೆ, ನಮಗೆ ತಿನ್ನಲು ಏನೂ ಇರುವುದಿಲ್ಲ. ಇದು ಕಂಪ್ಯೂಟರ್ ಆಟದಲ್ಲಿ ಮನದಂತಿದೆ. ನಾವು ಏನನ್ನಾದರೂ ಮಾಡುತ್ತೇವೆ, ನಾವು ಮಾಡುತ್ತೇವೆ, ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಇವು ಭಯಾನಕ ಬೈಸಿಕಲ್‌ಗಳು ಎಂದು ಯಾರಾದರೂ ಹೇಳುತ್ತಾರೆ, ಎಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಾಗಿದೆ ಎಂದು ಯಾರಾದರೂ ಹೇಳುತ್ತಾರೆ, ಆದರೆ ನಾವು ಮುಂದುವರಿಯುತ್ತೇವೆ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತೇವೆ. ನಾವು ಸಮಸ್ಯೆಯನ್ನು ನೋಡುತ್ತೇವೆ, ಅದನ್ನು ಪರಿಹರಿಸುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ನಮಗೆ ನಕ್ಷತ್ರವನ್ನು ನೀಡಿ, ಅದು ನಿಮ್ಮಿಂದ ದೂರ ಹೋಗುವುದಿಲ್ಲ, ಆದರೆ ಅದು ನಮ್ಮ ಬಳಿಗೆ ಬರುತ್ತದೆ, ಏಕೆಂದರೆ ನಾವು ಅವುಗಳನ್ನು ತಿನ್ನುತ್ತೇವೆ.
ಮೂರನೇ, ಪ್ರಮುಖ ಮತ್ತು ಇನ್ನು ಮುಂದೆ ವ್ಯಾಪಾರದ ಆಶಯ - ಕಾಲ್ಪನಿಕ ಕಥೆಗಳನ್ನು ನಂಬುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ನೀವು ವೃತ್ತಿಪರರು. DevOps ಅತ್ಯಂತ ಗಂಭೀರ ಮತ್ತು ಜವಾಬ್ದಾರಿಯುತ ವೃತ್ತಿಯಾಗಿದೆ. ಕೆಲಸದ ಸ್ಥಳದಲ್ಲಿ ಆಟವಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಅದು ನಿಮಗಾಗಿ ಕ್ಲಿಕ್ ಮಾಡಲಿ ಮತ್ತು ನೀವು ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಿರಿ. ನೀವು ಆಸ್ಪತ್ರೆಗೆ ಬರುತ್ತೀರಿ ಎಂದು ಊಹಿಸಿ, ಮತ್ತು ಅಲ್ಲಿ ವೈದ್ಯರು ನಿಮ್ಮ ಮೇಲೆ ಪ್ರಯೋಗ ಮಾಡುತ್ತಿದ್ದಾರೆ. ಇದು ಯಾರಿಗಾದರೂ ಆಕ್ರಮಣಕಾರಿ ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ, ಆದರೆ, ಹೆಚ್ಚಾಗಿ, ಇದು ನಿಮ್ಮ ಬಗ್ಗೆ ಅಲ್ಲ, ಆದರೆ ಬೇರೆಯವರ ಬಗ್ಗೆ. ಇತರರಿಗೂ ನಿಲ್ಲಿಸಲು ಹೇಳಿ. ಇದು ನಿಜವಾಗಿಯೂ ನಮ್ಮೆಲ್ಲರ ಜೀವನವನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ - ಅನೇಕರು ಕಾರ್ಯಾಚರಣೆಗಳು, ನಿರ್ವಾಹಕರು ಮತ್ತು DevOps ಅನ್ನು ಮತ್ತೆ ಏನನ್ನಾದರೂ ಮುರಿದ ಡ್ಯೂಡ್ಸ್ ಎಂದು ಪರಿಗಣಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ನಾವು ಆಟವಾಡಲು ಹೋದ ಕಾರಣ ಇದು ಹೆಚ್ಚಾಗಿ "ಮುರಿದಿದೆ" ಮತ್ತು ಅದು ಹೀಗಿದೆ ಮತ್ತು ಅದು ಹೀಗಿದೆ ಎಂದು ತಣ್ಣನೆಯ ಪ್ರಜ್ಞೆಯಿಂದ ನೋಡಲಿಲ್ಲ.
ನೀವು ಪ್ರಯೋಗ ಮಾಡಬಾರದು ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ನಾವು ಪ್ರಯೋಗ ಮಾಡಬೇಕಾಗಿದೆ, ಅದನ್ನು ನಾವೇ ಮಾಡುತ್ತೇವೆ. ನಿಜ ಹೇಳಬೇಕೆಂದರೆ, ನಾವೇ ಕೆಲವೊಮ್ಮೆ ಆಟಗಳನ್ನು ಆಡುತ್ತೇವೆ - ಇದು ತುಂಬಾ ಕೆಟ್ಟದು, ಆದರೆ ಮನುಷ್ಯ ನಮಗೆ ಅನ್ಯವಾಗಿಲ್ಲ. 2019 ಅನ್ನು ಗಂಭೀರವಾದ, ಚೆನ್ನಾಗಿ ಯೋಚಿಸಿದ ಪ್ರಯೋಗಗಳ ವರ್ಷವೆಂದು ಘೋಷಿಸೋಣ ಮತ್ತು ಉತ್ಪಾದನೆಯ ಆಟಗಳಲ್ಲ. ಬಹುಶಃ ಹಾಗೆ.
- ತುಂಬ ಧನ್ಯವಾದಗಳು!
ಡಿಮಿಟ್ರಿ: ವಿಟಾಲಿ, ಸಮಯ ಮತ್ತು ಸಂದರ್ಶನಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು. ಆತ್ಮೀಯ ಓದುಗರೇ, ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಈ ಹಂತವನ್ನು ತಲುಪಿದ್ದರೆ ತುಂಬಾ ಧನ್ಯವಾದಗಳು. ನಾವು ನಿಮಗೆ ಕನಿಷ್ಠ ಒಂದೆರಡು ಆಲೋಚನೆಗಳನ್ನು ತಂದಿದ್ದೇವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಸಂದರ್ಶನದಲ್ಲಿ, ಡಿಮಿಟ್ರಿ ವರ್ಫ್ ಸಮಸ್ಯೆಯನ್ನು ಮುಟ್ಟಿದರು. ಈಗ ಇದು ಸಾರ್ವತ್ರಿಕ ಸ್ವಿಸ್ ಚಾಕು ಆಗಿದ್ದು ಅದು ಬಹುತೇಕ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಆದರೆ ಯಾವಾಗಲೂ ಹಾಗಿರಲಿಲ್ಲ. ಆನ್ ಉತ್ಸವದಲ್ಲಿ ಡಿಮಿಟ್ರಿ ಸ್ಟೊಲಿಯಾರೊವ್ ಈ ಉಪಕರಣದ ಬಗ್ಗೆ ವಿವರವಾಗಿ ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ. ವರದಿಯಲ್ಲಿ ಎಲ್ಲವೂ ಇರುತ್ತದೆ: ಕುಬರ್ನೆಟ್ಸ್ನ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಗುಪ್ತ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು, ಈ ತೊಂದರೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಆಯ್ಕೆಗಳು ಮತ್ತು ವರ್ಫ್‌ನ ಪ್ರಸ್ತುತ ಅನುಷ್ಠಾನವನ್ನು ವಿವರವಾಗಿ. ಮೇ 27 ಮತ್ತು 28 ರಂದು ನಮ್ಮೊಂದಿಗೆ ಸೇರಿ, ನಾವು ಪರಿಪೂರ್ಣ ಪರಿಕರಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ.
ಮೂಲ: www.habr.com