ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ವಿಷಯದ ಬಗ್ಗೆ ನಾನು ಬಹಳ ಸಮಯದಿಂದ ಲೇಖನವನ್ನು ಬರೆಯಲು ಬಯಸಿದ್ದೆ, ಆದರೆ ಎರಡು ವಿಷಯಗಳು ನನ್ನನ್ನು ತಡೆಯುತ್ತಲೇ ಇದ್ದವು - ಮುಂದೆ ನಾನು ವಿಷಯಕ್ಕೆ ಧುಮುಕಿದೆ, ನನಗೆ ತಿಳಿದಿರುವುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ನಾನು ಏನು ಮಾಡುತ್ತಿಲ್ಲ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಅದನ್ನು ಅಧ್ಯಯನ ಮಾಡಬೇಕು ಮತ್ತು ಅಧ್ಯಯನ ಮಾಡಬೇಕು ಎಂದು ತಿಳಿದಿದೆ. ಮತ್ತೊಂದೆಡೆ, ವಿಶಾಲ ಪ್ರೇಕ್ಷಕರ ನಡುವೆ ಚರ್ಚಿಸಲು ಈಗಾಗಲೇ ಏನಾದರೂ ಇದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಹಾಗಾಗಿ ಪರ್ಯಾಯ ಅಭಿಪ್ರಾಯಗಳಿಗೆ ಸ್ವಾಗತ.
ಕಾನ್ವೇಯ ಕಾನೂನು ಮತ್ತು ವ್ಯಾಪಾರ, ಸಂಸ್ಥೆ ಮತ್ತು ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಯ ನಡುವಿನ ಸಂಬಂಧ
ಮತ್ತೊಮ್ಮೆ ನಾನು ಉಲ್ಲೇಖಿಸಲು ಅನುಮತಿಸುತ್ತೇನೆ:
"ಒಂದು ವ್ಯವಸ್ಥೆಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಯಾವುದೇ ಸಂಸ್ಥೆಯು (ವಿಶಾಲ ಅರ್ಥದಲ್ಲಿ) ವಿನ್ಯಾಸವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅದರ ರಚನೆಯು ಆ ಸಂಸ್ಥೆಯಲ್ಲಿನ ತಂಡಗಳ ರಚನೆಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ."
- ಮೆಲ್ವಿನ್ ಕಾನ್ವೇ, 1967
ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಈ ಕಾನೂನು ನೇರವಾಗಿ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗೆ ಬದಲಾಗಿ ವ್ಯಾಪಾರವನ್ನು ಸಂಘಟಿಸುವ ಕಾರ್ಯಸಾಧ್ಯತೆಗೆ ಸಂಬಂಧಿಸಿದೆ. ನಾನು ಉದಾಹರಣೆಯೊಂದಿಗೆ ವಿವರಿಸುತ್ತೇನೆ. ಉದ್ಯಮವನ್ನು ಸಂಘಟಿಸಲು ಅರ್ಥಪೂರ್ಣವಾದ ಉದ್ದದ ಜೀವನ ಚಕ್ರದೊಂದಿಗೆ ನಾವು ಸಾಕಷ್ಟು ಸ್ಥಿರವಾದ ವ್ಯಾಪಾರ ಅವಕಾಶವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ (ಇದು ಮುದ್ರಣದೋಷವಲ್ಲ, ಆದರೆ ನಾನು ಕದ್ದ ಈ ಪದವನ್ನು ನಾನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುತ್ತೇನೆ). ಸ್ವಾಭಾವಿಕವಾಗಿ, ಈ ವ್ಯವಹಾರದ ಪೋಷಕ ವ್ಯವಸ್ಥೆ ಈ ವ್ಯವಹಾರಕ್ಕೆ ಸಾಂಸ್ಥಿಕವಾಗಿ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ.
ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳ ವ್ಯಾಪಾರ ದೃಷ್ಟಿಕೋನ
ನಾನು ಒಂದು ಉದಾಹರಣೆಯೊಂದಿಗೆ ವಿವರಿಸುತ್ತೇನೆ. ಪಿಜ್ಜಾವನ್ನು ಮಾರಾಟ ಮಾಡುವ ವ್ಯಾಪಾರವನ್ನು ಸಂಘಟಿಸಲು ವ್ಯಾಪಾರ ಅವಕಾಶವಿದೆ ಎಂದು ಹೇಳೋಣ. V1 ಆವೃತ್ತಿಯಲ್ಲಿ (ಇದನ್ನು ಪೂರ್ವ-ಮಾಹಿತಿ ಎಂದು ಕರೆಯೋಣ), ಕಂಪನಿಯು ಪಿಜ್ಜೇರಿಯಾ, ನಗದು ರಿಜಿಸ್ಟರ್ ಮತ್ತು ವಿತರಣಾ ಸೇವೆಯಾಗಿದೆ. ಈ ಆವೃತ್ತಿಯು ಕಡಿಮೆ ಪರಿಸರದ ವ್ಯತ್ಯಾಸದ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ದೀರ್ಘಕಾಲ ಉಳಿಯಿತು. ನಂತರ ಆವೃತ್ತಿ 2 ಅದನ್ನು ಬದಲಿಸಲು ಬಂದಿತು - ಹೆಚ್ಚು ಸುಧಾರಿತ ಮತ್ತು ಏಕಶಿಲೆಯ ವಾಸ್ತುಶಿಲ್ಪದೊಂದಿಗೆ ವ್ಯವಹಾರಕ್ಕಾಗಿ ಅದರ ಕೇಂದ್ರದಲ್ಲಿ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಏಕಶಿಲೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಭಯಾನಕ ಅನ್ಯಾಯವಿದೆ - ಆಪಾದಿತ ಏಕಶಿಲೆಯ ವಾಸ್ತುಶಿಲ್ಪವು ಡೊಮೇನ್ ವ್ಯವಹಾರ ಮಾದರಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಹೌದು, ಇದು ಹಾಗಿದ್ದಲ್ಲಿ, ವ್ಯವಸ್ಥೆಯು ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ - ಅದೇ ಕಾನ್ವೇ ಕಾನೂನು ಮತ್ತು ಸಾಮಾನ್ಯ ಜ್ಞಾನಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ. ಇಲ್ಲ, ಏಕಶಿಲೆಯ ವಾಸ್ತುಶಿಲ್ಪವು ವ್ಯವಹಾರದ ಅಭಿವೃದ್ಧಿಯ ಈ ಹಂತದಲ್ಲಿ ವ್ಯವಹಾರ ಮಾದರಿಯೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಿರವಾಗಿದೆ - ನಾನು, ಸಹಜವಾಗಿ, ವ್ಯವಸ್ಥೆಯನ್ನು ಈಗಾಗಲೇ ರಚಿಸಿದ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗೆ ಒಳಪಡಿಸಿದ ಹಂತವನ್ನು ಅರ್ಥೈಸುತ್ತೇನೆ. ವಾಸ್ತುಶಿಲ್ಪದ ವಿಧಾನವನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ, ಸೇವಾ-ಆಧಾರಿತ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆವೃತ್ತಿ 3 ಮತ್ತು ಮೈಕ್ರೋಸರ್ವೀಸಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆವೃತ್ತಿ N ಎರಡೂ ಸಮಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದು ಸಂಪೂರ್ಣವಾಗಿ ಅದ್ಭುತವಾದ ಸತ್ಯವಾಗಿದೆ. ಕ್ಯಾಚ್ ಏನು?
ಎಲ್ಲವೂ ಹರಿಯುತ್ತದೆ, ಎಲ್ಲವೂ ಬದಲಾಗುತ್ತದೆ, ಅಥವಾ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು ಸಂಕೀರ್ಣತೆಯನ್ನು ಎದುರಿಸುವ ಸಾಧನವೇ?
ನಾವು ಮುಂದುವರಿಯುವ ಮೊದಲು, ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಬಗ್ಗೆ ಕೆಲವು ತಪ್ಪು ಕಲ್ಪನೆಗಳನ್ನು ನೋಡೋಣ.
ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ವಿಧಾನವನ್ನು ಬಳಸುವ ಪ್ರತಿಪಾದಕರು ಸಾಮಾನ್ಯವಾಗಿ ಏಕಶಿಲೆಯನ್ನು ಮೈಕ್ರೋ ಸರ್ವಿಸ್‌ಗಳಾಗಿ ಒಡೆಯುವುದರಿಂದ ವೈಯಕ್ತಿಕ ಸೇವೆಗಳ ಕೋಡ್ ಬೇಸ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ ಅಭಿವೃದ್ಧಿ ವಿಧಾನವನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಎಂದು ವಾದಿಸುತ್ತಾರೆ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಈ ಹೇಳಿಕೆಯು ಸಂಪೂರ್ಣ ಅಸಂಬದ್ಧವಾಗಿದೆ. ಗಂಭೀರವಾಗಿ, ಏಕಶಿಲೆ ಮತ್ತು ಏಕರೂಪದ ಕೋಡ್‌ನೊಳಗಿನ ಸ್ಪಷ್ಟವಾದ ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಜಟಿಲವಾಗಿದೆಯೇ? ಇದು ನಿಜವಾಗಿದ್ದರೆ, ಎಲ್ಲಾ ಯೋಜನೆಗಳನ್ನು ಆರಂಭದಲ್ಲಿ ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳಾಗಿ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅಭ್ಯಾಸವು ಏಕಶಿಲೆಯಿಂದ ಮೈಕ್ರೋಸರ್ವೀಸ್‌ಗಳಿಗೆ ವಲಸೆ ಹೆಚ್ಚು ಸಾಮಾನ್ಯವಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಸಂಕೀರ್ಣತೆಯು ಕಣ್ಮರೆಯಾಗುವುದಿಲ್ಲ; ಇದು ವೈಯಕ್ತಿಕ ಮಾಡ್ಯೂಲ್‌ಗಳಿಂದ ಇಂಟರ್‌ಫೇಸ್‌ಗಳಿಗೆ (ಅದು ಡೇಟಾ ಬಸ್‌ಗಳು, ಆರ್‌ಪಿಸಿ, ಎಪಿಐಗಳು ಮತ್ತು ಇತರ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು) ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಚಲಿಸುತ್ತದೆ. ಮತ್ತು ಇದು ಕಷ್ಟ!
ವೈವಿಧ್ಯಮಯ ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸುವ ಪ್ರಯೋಜನವೂ ಸಹ ಪ್ರಶ್ನಾರ್ಹವಾಗಿದೆ. ಇದು ಸಹ ಸಾಧ್ಯ ಎಂದು ನಾನು ವಾದಿಸುವುದಿಲ್ಲ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಇದು ವಿರಳವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ (ಮುಂದೆ ನೋಡುತ್ತಿರುವುದು - ಇದು ಆಗಬೇಕು - ಆದರೆ ಪ್ರಯೋಜನಕ್ಕಿಂತ ಪರಿಣಾಮವಾಗಿ).
ಉತ್ಪನ್ನ ಜೀವನ ಚಕ್ರ ಮತ್ತು ಸೇವಾ ಜೀವನ ಚಕ್ರ
ಮೇಲಿನ ರೇಖಾಚಿತ್ರವನ್ನು ಮತ್ತೊಮ್ಮೆ ನೋಡೋಣ. ವ್ಯವಹಾರದ ಪ್ರತ್ಯೇಕ ಆವೃತ್ತಿಯ ಜೀವನ ಚಕ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದನ್ನು ನಾನು ಗಮನಿಸಿರುವುದು ಕಾಕತಾಳೀಯವಲ್ಲ - ಆಧುನಿಕ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ವ್ಯವಹಾರದ ಯಶಸ್ಸಿಗೆ ನಿರ್ಣಾಯಕವಾದ ಆವೃತ್ತಿಗಳ ನಡುವೆ ಪರಿವರ್ತನೆಯ ವೇಗವರ್ಧನೆಯಾಗಿದೆ. ಉತ್ಪನ್ನದ ಯಶಸ್ಸನ್ನು ಅದರಲ್ಲಿರುವ ವ್ಯವಹಾರ ಕಲ್ಪನೆಗಳನ್ನು ಪರೀಕ್ಷಿಸುವ ವೇಗದಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಪ್ರಮುಖ ಪ್ರಯೋಜನವಿದೆ. ಆದರೆ ಕ್ರಮವಾಗಿ ಹೋಗೋಣ.
ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳ ವಿಕಾಸದಲ್ಲಿ ಮುಂದಿನ ಹಂತಕ್ಕೆ ಹೋಗೋಣ - SOA ಯ ಸೇವಾ-ಆಧಾರಿತ ವಾಸ್ತುಶಿಲ್ಪಕ್ಕೆ. ಆದ್ದರಿಂದ, ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಹಂತದಲ್ಲಿ ನಾವು ನಮ್ಮ ಉತ್ಪನ್ನದಲ್ಲಿ ಹೈಲೈಟ್ ಮಾಡಿದ್ದೇವೆ ದೀರ್ಘಾವಧಿಯ ಸೇವೆಗಳು - ಉತ್ಪನ್ನದ ಆವೃತ್ತಿಗಳ ನಡುವೆ ಚಲಿಸುವಾಗ, ಸೇವೆಯ ಜೀವನ ಚಕ್ರವು ಉತ್ಪನ್ನದ ಮುಂದಿನ ಆವೃತ್ತಿಯ ಜೀವನ ಚಕ್ರಕ್ಕಿಂತ ದೀರ್ಘವಾಗಿರುತ್ತದೆ ಎಂಬ ಅರ್ಥದಲ್ಲಿ ದೀರ್ಘಕಾಲ ಬದುಕಿದೆ. ಅವುಗಳನ್ನು ಬದಲಾಯಿಸದಿರುವುದು ತಾರ್ಕಿಕವಾಗಿದೆ - ನಾವು ಮುಂದಿನ ಆವೃತ್ತಿಗೆ ಪರಿವರ್ತನೆಯ ವೇಗವು ಮುಖ್ಯವಾದುದು. ಆದರೆ ಅಯ್ಯೋ, ಸೇವೆಗಳಿಗೆ ನಿರಂತರ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ನಾವು ಒತ್ತಾಯಿಸಲ್ಪಡುತ್ತೇವೆ - ಮತ್ತು ಇಲ್ಲಿ ಎಲ್ಲವೂ ನಮಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, DevOps ಅಭ್ಯಾಸಗಳು, ಕಂಟೈನರೈಸೇಶನ್ ಮತ್ತು ಹೀಗೆ - ಮನಸ್ಸಿಗೆ ಬರುವ ಎಲ್ಲವೂ. ಆದರೆ ಇವು ಇನ್ನೂ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳಲ್ಲ!
ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು ಸಂಕೀರ್ಣತೆಯನ್ನು ಎದುರಿಸುವ ಸಾಧನವಾಗಿ... ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣೆ
ಮತ್ತು ಇಲ್ಲಿ ನಾವು ಅಂತಿಮವಾಗಿ ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳ ವ್ಯಾಖ್ಯಾನದ ಪಾತ್ರಕ್ಕೆ ಹೋಗಬಹುದು - ಇದು ಉತ್ಪನ್ನ ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣೆಯನ್ನು ಸರಳಗೊಳಿಸುವ ವಿಧಾನವಾಗಿದೆ. ಹೆಚ್ಚು ವಿವರವಾಗಿ, ಪ್ರತಿ ಮೈಕ್ರೋ ಸರ್ವಿಸ್‌ನ ಕಾರ್ಯವು ಡೊಮೇನ್ ಮಾದರಿಯ ಪ್ರಕಾರ ಉತ್ಪನ್ನದೊಳಗಿನ ವ್ಯವಹಾರ ಕಾರ್ಯವನ್ನು ನಿಖರವಾಗಿ ವಿವರಿಸುತ್ತದೆ - ಮತ್ತು ಇವುಗಳು ಅಲ್ಪಾವಧಿಯ ಆವೃತ್ತಿಯಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ದೀರ್ಘಾವಧಿಯ ವ್ಯಾಪಾರ ಅವಕಾಶದಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ಮತ್ತು ಉತ್ಪನ್ನದ ಮುಂದಿನ ಆವೃತ್ತಿಗೆ ಪರಿವರ್ತನೆಯು ಅಕ್ಷರಶಃ ಗಮನಕ್ಕೆ ಬರುವುದಿಲ್ಲ - ನೀವು ಒಂದು ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೀರಿ / ಸೇರಿಸುತ್ತೀರಿ, ಮತ್ತು ಬಹುಶಃ ಅವರ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಯೋಜನೆ, ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನಿಮ್ಮನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ, ಆವೃತ್ತಿಗಳ ನಡುವೆ ಜಿಗಿಯುವುದನ್ನು ಮುಂದುವರಿಸುವ ಅಳುವ ಸ್ಪರ್ಧಿಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತೀರಿ. ಅವರ ಏಕಶಿಲೆಗಳು. ಪೂರ್ವನಿರ್ಧರಿತ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಮತ್ತು ವ್ಯಾಪಾರ ಸಾಮರ್ಥ್ಯಗಳೊಂದಿಗೆ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಿವೆ ಎಂದು ಈಗ ಊಹಿಸಿ. ಮತ್ತು ನೀವು ಬಂದು ನಿಮ್ಮ ಉತ್ಪನ್ನದ ರಚನೆಯನ್ನು ರೆಡಿಮೇಡ್ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳಿಂದ ನಿರ್ಮಿಸುತ್ತೀರಿ - ರೇಖಾಚಿತ್ರವನ್ನು ಎಳೆಯುವ ಮೂಲಕ, ಉದಾಹರಣೆಗೆ. ಅಭಿನಂದನೆಗಳು - ನೀವು ವೇದಿಕೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ - ಮತ್ತು ಈಗ ನೀವು ನಿಮಗಾಗಿ ವ್ಯಾಪಾರವನ್ನು ಆಕರ್ಷಿಸಬಹುದು. ಡ್ರೀಮ್ಸ್ ಡ್ರೀಮ್ಸ್.
ಸಂಶೋಧನೆಗಳು
- ವ್ಯವಸ್ಥೆಯ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಅದರ ಘಟಕಗಳ ಜೀವನ ಚಕ್ರದಿಂದ ನಿರ್ಧರಿಸಬೇಕು. ಒಂದು ಘಟಕವು ಉತ್ಪನ್ನದ ಆವೃತ್ತಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದರೆ, ಮೈಕ್ರೋಸರ್ವಿಸ್ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಸಿಸ್ಟಮ್ನ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ.
- ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಡೊಮೇನ್ ಮಾದರಿಯನ್ನು ಆಧರಿಸಿರಬೇಕು - ಏಕೆಂದರೆ ವ್ಯಾಪಾರದ ಅವಕಾಶವು ದೀರ್ಘಾವಧಿಯ ಡೊಮೇನ್ ಆಗಿದೆ
- ವಿತರಣಾ ಅಭ್ಯಾಸಗಳು (DevOps ಅಭ್ಯಾಸಗಳು) ಮತ್ತು ವಾದ್ಯವೃಂದವು ಮೈಕ್ರೊ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಪ್ರಮುಖವಾದವುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ - ಘಟಕಗಳ ಬದಲಾವಣೆಯ ದರದಲ್ಲಿನ ಹೆಚ್ಚಳವು ವಿತರಣೆಯ ವೇಗ ಮತ್ತು ಗುಣಮಟ್ಟದ ಮೇಲೆ ಬೇಡಿಕೆಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ
ಮೂಲ: www.habr.com