TechForge ನ ಹೊಸ ಮಾರ್ಗದರ್ಶಿಯು ಅನೇಕ ಆರಂಭಿಕ ಮೈಕ್ರೋಸರ್ವಿಸ್ (microservices) ಯೋಜನೆಗಳು "ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಮೊನೊಲಿತ್"ಗಳಾಗಿ (distributed monoliths) ಕೊನೆಗೊಳ್ಳುತ್ತವೆ ಎಂದು ಎಚ್ಚರಿಸುತ್ತದೆ, ಇದು ಯಾವುದೇ ಸ್ಕೇಲಿಂಗ್ ಪ್ರಯೋಜನಗಳಿಲ್ಲದೆ ನೆಟ್ವರ್ಕ್ ಕರೆಗಳ ವಿಳಂಬವನ್ನು (latency) ಮಾತ್ರ ನೀಡುತ್ತದೆ. ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು ಮೊದಲು ಒಂದು ಬಲಿಷ್ಠ ಮೊನೊಲಿತ್ನಿಂದ ಪ್ರಾರಂಭಿಸಬೇಕು ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ಅಥವಾ ಮಾಲೀಕತ್ವದ ಅಗತ್ಯತೆಗಳು ಸ್ಪಷ್ಟವಾಗಿ ಕಂಡುಬಂದಾಗ ಮಾತ್ರ ಅದನ್ನು ವಿಭಜಿಸಬೇಕು ಎಂದು ಈ ಲೇಖನವು ಒತ್ತಿಹೇಳುತ್ತದೆ.
ತಂಡಗಳು ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳತ್ತ ಏಕೆ ಅವಸರ ಮಾಡುತ್ತವೆ
ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳ ಆಕರ್ಷಣೆಯು ಸ್ಪಷ್ಟವಾಗಿದೆ: ಸ್ವತಂತ್ರ ಸೇವೆಗಳು, ಪ್ರತ್ಯೇಕ ನಿಯೋಜನೆಗಳು (deployments), ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ಪ್ರತಿಯೊಂದು ಭಾಗವನ್ನು ಅದರದೇ ಆದ ನಿಯಮಗಳ ಮೇಲೆ ಸ್ಕೇಲ್ ಮಾಡುವ ಭರವಸೆ. ಸ್ಟಾರ್ಟ್-ಅಪ್ ಸಂಸ್ಕೃತಿ ಮತ್ತು ಇತ್ತೀಚಿನ ಯಶಸ್ಸಿನ ಕಥೆಗಳು ಈ ಮಾದರಿಯನ್ನು ಆಧುನಿಕ ಎಂಜಿನಿಯರಿಂಗ್ನ ಸಂಕೇತವನ್ನಾಗಿ ಮಾಡಿದೆ. ಆದರೂ, ಮೊನೊಲಿತ್ ಅನ್ನು ಅತಿ ಬೇಗ ವಿಭಜಿಸುವುದು ಹೆಚ್ಚಾಗಿ ಹೊಸ ರೀತಿಯ ಮೊನೊಲಿತ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ—ಅಂದರೆ ಡಜನ್ಗಟ್ಟಲೆ ನೆಟ್ವರ್ಕ್ ಮಾಡಲಾದ ಘಟಕಗಳು. ಇದರ ಬೆಲೆ ಏನು? ಹೆಚ್ಚಿನ ವಿಳಂಬ (latency), ಕಷ್ಟಕರವಾದ ಡಿಬಗ್ಗಿಂಗ್ (debugging), ಮತ್ತು ಹೆಚ್ಚಿನ ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆ (operational overhead), ಆದರೆ ಮೂಲ ಪ್ರಯೋಜನಗಳು ಸಿಗುವುದಿಲ್ಲ.
ಮೊದಲ ತಪ್ಪು: ಕೇವಲ ಹೆಸರಿಗಷ್ಟೇ ಮೊನೊಲಿತ್ನಿಂದ ಪ್ರಾರಂಭಿಸುವುದು
ತಂಡಗಳು ಹೆಚ್ಚಾಗಿ ಒಂದೇ ಕೋಡ್ಬೇಸ್ (codebase) ಮತ್ತು ಹಂಚಿಕೆಯ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಇಟ್ಟುಕೊಂಡು, ವ್ಯವಸ್ಥೆಯನ್ನು "ಮೈಕ್ರೋ-ಸರ್ವಿಸ್-ಆಧಾರಿತ" ಎಂದು ಲೇಬಲ್ ಮಾಡುತ್ತವೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, HTTP ಅಥವಾ RPC ಮೂಲಕ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುವ ಬಿಗಿಯಾಗಿ ಜೋಡಿಸಲ್ಪಟ್ಟ (tightly coupled) ಮಾಡ್ಯೂಲ್ಗಳ ಸರಣಿ ಉಂಟಾಗುತ್ತದೆ. ಮಾರ್ಗದರ್ಶಿಯು ಇದನ್ನು "ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಮೊನೊಲಿತ್" ಎಂದು ಕರೆಯುತ್ತದೆ. ಇದರ ತೊಂದರೆಗಳು ಸಾಂಪ್ರದಾಯಿಕ ಮೊನೊಲಿತ್ನಂತೆಯೇ ಇರುತ್ತವೆ—ಬಿಗವಾದ ಜೋಡಣೆ ಮತ್ತು ಉಳಿದ ಭಾಗಗಳಿಗೆ ತೊಂದರೆಯಾಗದಂತೆ ಒಂದು ಭಾಗವನ್ನು ಬದಲಾಯಿಸುವ ಕಷ್ಟ—ಮತ್ತು ಜೊತೆಗೆ ನೆಟ್ವರ್ಕ್ ಹಾಪ್ಗಳಿಂದ (network hops) ಉಂಟಾಗುವ ಹೆಚ್ಚಿನ ವಿಳಂಬ.
ಬದಲಿಗೆ ಏನು ಮಾಡಬೇಕು: ಮೊದಲು ಒಂದು ಸ್ವಚ್ಛವಾದ ಮೊನೊಲಿತ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಸ್ಪಷ್ಟವಾದ ಮಾಡ್ಯೂಲ್ ಗಡಿಗಳನ್ನು (module boundaries) ವ್ಯಾಖ್ಯಾನಿಸಿ, ಡೇಟಾ ಲೇಯರ್ ಅನ್ನು ಏಕೀಕೃತವಾಗಿಡಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಏಕೈಕ ಘಟಕವಾಗಿ ಪರೀಕ್ಷಿಸಲು ಮತ್ತು ನಿಯೋಜಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ನೋಡಿಕೊಳ್ಳಿ. ಒಂದು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಸ್ವತಂತ್ರ ಸ್ಕೇಲಿಂಗ್ ಅಥವಾ ಪ್ರತ್ಯೇಕ ತಂಡದ ಮಾಲೀಕತ್ವದ ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಅದನ್ನು ತನ್ನದೇ ಆದ ಸೇವೆಯಾಗಿ ಹೊರತೆಗೆಯಿರಿ.
ತಾಂತ್ರಿಕ ಲೇಯರ್ ವರ್ಸಸ್ ಬಿಸಿನೆಸ್ ಕ್ಯಪಬಿಲಿಟಿ ಮೂಲಕ ವಿಭಜಿಸುವುದು
ಮತ್ತೊಂದು ಸಾಮಾನ್ಯ ತಪ್ಪು ಎಂದರೆ ತಾಂತ್ರಿಕ ವಿಷಯಗಳಾದ—UI, ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಅಥವಾ ಡೇಟಾ ಅಕ್ಸೆಸ್ ಆಧಾರದ ಮೇಲೆ ಸೇವೆಗಳನ್ನು ವಿಭಜಿಸುವುದು. ಇದು ಒಂದೇ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ವಿನಂತಿಯು (request) ಸೇವೆಗಳ ಸರಪಳಿಯ ಮೂಲಕ ಪ್ರಯಾಣಿಸಬೇಕಾಗುವಂತೆ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯ (response time) ಹೆಚ್ಚಾಗುತ್ತದೆ ಮತ್ತು ದುರ್ಬಲವಾದ ಅವಲಂಬನಾತ್ಮಕ ಗ್ರಾಫ್ (dependency graph) ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ.
ಉತ್ತಮ ವಿಧಾನ: "ಆರ್ಡರ್ಗಳು" (orders), "ಪಾವತಿಗಳು" (payments), ಅಥವಾ "ಇನ್ವೆಂಟರಿ" (inventory) ನಂತಹ ಬಿಸಿನೆಸ್ ಕ್ಯಪಬಿಲಿಟಿಗಳ ಸುತ್ತ ಸೇವೆಗಳನ್ನು ಸಂಘಟಿಸಿ. ಪ್ರತಿಯೊಂದು ಕ್ಯಪಬಿಲಿಟಿ ತನ್ನದೇ ಆದ ಡೇಟಾ ಮತ್ತು ತನ್ನದೇ ಆದ API ಅನ್ನು ಹೊಂದಿರಲಿ, ಇದರಿಂದ ವಿನಂತಿಯು ವಿವಿಧ ಲೇಯರ್ಗಳ ಮೂಲಕ ಜಿಗಿಯುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ಡೇಟಾ ಮಾಲೀಕತ್ವ ಮುಖ್ಯವಾಗುತ್ತದೆ
ಎರಡು ಸೇವೆಗಳು ಒಂದೇ ಡೇಟಾಬೇಸ್ ಟೇಬಲ್ಗೆ ಬರೆಯುವಾಗ, ಅವು ಸ್ವತಂತ್ರವಾಗಿರುವುದಿಲ್ಲ. ಒಂದು ಸೇವೆಯು ಇನ್ನೊಂದು ಸೇವೆಯ ಟೇಬಲ್ಗಳನ್ನು ನೇರವಾಗಿ ಕ್ವೆರಿ (query) ಮಾಡಬಾರದು; ಅದು ಯಾವಾಗಲೂ ಆ ಸೇವೆಯ ಪಬ್ಲಿಕ್ API ಮೂಲಕವೇ ಹೋಗಬೇಕು ಎಂದು ಮಾರ್ಗದರ್ಶಿಯು ಒತ್ತಿಹೇಳುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು ಸೇವೆಗಳನ್ನು ಪರಸ್ಪರ ಜೋಡಿಸುತ್ತದೆ, ಐಸೊಲೇಶನ್ (isolation) ಅನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಕೀಮಾ ಬದಲಾವಣೆಗಳನ್ನು (schema changes) ಸಮನ್ವಯಗೊಳಿಸುವುದು ಒಂದು ದುಸ್ವಲ್ಪನೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ.
ಸಿಂಕ್ರೋನಸ್ HTTP ಒಂದು ಸಾರ್ವತ್ರಿಕ ಪರಿಹಾರವಲ್ಲ
ಪ್ರತಿಯೊಂದು ಸಂವಹನಕ್ಕೂ ಸಿಂಕ್ರೋನಸ್ HTTP ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದು ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ಒಂದೇ ಒಂದು ನಿಧಾನಗತಿಯ ಸೇವೆಗೆ ಅಸುರಕ್ಷಿತವಾಗಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಮೊದಲು ಸರ್ವಿಸ್ A, ಸರ್ವಿಸ್ B ನ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯುತ್ತಿದ್ದರೆ, B ನಲ್ಲಿನ ಯಾವುದೇ ವಿಳಂಬವು A ಗೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಬಳಕೆದಾರರಿಗೆ ತಲುಪುತ್ತದೆ.
ಪರ್ಯಾಯ ಮಾದರಿಗಳು: ತಕ್ಷಣದ ಉತ್ತರದ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರ್ಯಗಳಿಗಾಗಿ ಅಸಿಂಕ್ರೋನಸ್ ಮೆಸೇಜಿಂಗ್ (asynchronous messaging) ಬಳಸಿ. ಮೆಸೇಜ್ ಕ್ಯೂಗಳು (Message queues) ಅಥವಾ ಬ್ಯಾಕ್ಗ್ರೌಂಡ್ ಜಾಬ್ಗಳು ಸೇವೆಗಳು ಕೆಲಸವನ್ನು ಹಸ್ತಾಂತರಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮುಂದುವರಿಸಲು way ಮಾಡಿಕೊಡುತ್ತವೆ, ಇದರಿಂದ ಒಟ್ಟಾರೆ ವ್ಯವಸ್ಥೆಯು ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು (resilient) ಹೊಂದಿರುತ್ತದೆ.
ಎವೆಂಟುವಲ್ ಕನ್ಸಿಸ್ಟೆನ್ಸಿಯನ್ನು (eventual consistency) ಒಪ್ಪಿಕೊಳ್ಳುವುದು
ಸಾಂಪ್ರದಾಯಿಕ ರಿಲೇಶನಲ್ ಡೇಟಾಬೇಸ್ಗಳು ನಿಮಗೆ ACID ಟ್ರಾನ್ಸಾಕ್ಷನ್ಗಳನ್ನು ನೀಡುತ್ತವೆ—Atomicity, Consistency, Isolation, Durability. ಸೇವೆಗಳ ಗಡಿಗಳ ಆಚೆಗಿನ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಆ ಗ್ಯಾರಂಟಿಗಳು ಮಾಯವಾಗುತ್ತವೆ. ಟೂ-ಫೇಸ್ ಕಮಿಟ್ಗಳನ್ನು (two-phase commits - ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ಗಳನ್ನು ಲೋಕಲ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ಗಳಂತೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವ ಪ್ರೋಟೋಕಾಲ್) ಬಲವಂತವಾಗಿ ಅನ್ವಯಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು ಸಂಕೀರ್ಣತೆ ಮತ್ತು ಅಸ್ಥಿರತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಮಾರ್ಗದರ್ಶಿಯು ಸಾಗಾಗಳನ್ನು (sagas - ಪರಿಹಾರ ಕ್ರಮಗಳ ಸರಣಿ) ಅಥವಾ ಔಟ್ಬಾಕ್ಸ್ ಮಾದರಿಯನ್ನು (outbox pattern - ಇಲ್ಲಿ ಒಂದು ಸೇವೆಯು ಸ್ಥಳೀಯ ಟೇಬಲ್ಗೆ ಇವೆಂಟ್ಗಳನ್ನು ಬರೆಯುತ್ತದೆ ಮತ್ತು ಅವು ನಂತರ ಪ್ರಕಟವಾಗುತ್ತವೆ) ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ. ಈ ವಿಧಾನಗಳು ಡೇಟಾ ತಾತ್ಕಾಲಿಕವಾಗಿ ಸಿಂಕ್ ಆಗಿಲ್ಲದಿರಬಹುದು ಎಂಬುದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಆ ಅಂತರಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತವೆ.
ಮೊದಲ ದಿನದಿಂದಲೇ ವೈಫಲ್ಯಕ್ಕಾಗಿ ಸಿದ್ಧರಾಗಿರಿ
ಒಂದು ಸೇವೆಯಲ್ಲಿನ ಬಗ್ ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡಬಾರದು. ಸದಾಕಾಲ ಕಾಯುವುದನ್ನು ತಪ್ಪಿಸಲು ಟೈಮೌಟ್ಗಳನ್ನು (timeouts), ತಾತ್ಕಾಲಿಕ ವೈಫಲ್ಯಗಳನ್ನು ನಿಭಾಯಿಸಲು ಬ್ಯಾಕ್-ಆಫ್ನೊಂದಿಗೆ ರಿಟ್ರೈಗಳನ್ನು (retries with back-off), ಮತ್ತು ಸೇವೆಯು ಚೇತರಿಸಿಕೊಳ್ಳುವವರೆಗೆ ವೈಫಲ್ಯದ ಸೇವೆಗೆ ಕರೆಗಳನ್ನು ನಿಲ್ಲಿಸುವ ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ಗಳನ್ನು (circuit breakers) ಅನುಷ್ಠಾನಗೊಳಿಸಿ. ಪ್ರೊಡಕ್ಷನ್ ಔಟೇಜ್ ನಂತರ ಈ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳನ್ನು ಸೇರಿಸುವುದು ತುಂಬಾ ತಡ; ಅವು ಆರಂಭಿಕ ವಿನ್ಯಾಸದಲ್ಲೇ ಇರಬೇಕು.
ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ (Observability) ಅನಿವಾರ್ಯ
ಅನೇಕ ಕಂಟೇನರ್ಗಳಲ್ಲಿ ಚದುರಿಹೋಗಿರುವ ಲಾಗ್ಗಳೊಂದಿಗೆ ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುವುದು ಅಸಾಧ್ಯದ ಮಾತು. ಕೇಂದ್ರೀಕೃತ ಲಾಗಿಂಗ್ (Centralized logging), ಕ್ರೆಗೇಟೆಡ್ ಮೆಟ್ರಿಕ್ಸ್ (aggregated metrics), ಮತ್ತು ರಿಕ್ವೆಸ್ಟ್-ಲೆವೆಲ್ ಕೊರಿಲೇಶನ್ ಐಡಿಗಳು (request-level correlation IDs) ಎಂಜಿನಿಯರ್ಗಳು ಒಂದೇ ಬಳಕೆದಾರರ ವಿನಂತಿಯು ಅನೇಕ ಸೇವೆಗಳ ಮೂಲಕ ಚಲಿಸುವಾಗ ಅದನ್ನು ಟ್ರೇಸ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ. ಟ್ರೇಸಿಂಗ್ ಪರಿಕರಗಳು ಕಾಲ್ ಗ್ರಾಫ್ ಅನ್ನು ದೃಶ್ಯೀಕರಿಸುತ್ತವೆ, ಇದರಿಂದ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಬಾಟಲ್ನೆಕ್ಗಳು (performance bottlenecks) ಮತ್ತು ವೈಫಲ್ಯಗಳನ್ನು ಸುಲಭವಾಗಿ ಪತ್ತೆಹಚ್ಚಬಹುದು.
ಆರಂಭದಲ್ಲಿ ಮೂಲಸೌಕರ್ಯವನ್ನು (infrastructure) ಲೈಟ್ವೇಟ್ ಆಗಿ ಇರಿಸಿ
Kubernetes ಶಕ್ತಿಯುತವಾಗಿದ್ದರೂ, ಇದು ಕಲಿಯಲು ಕಠಿಣವಾದ ಹಾದಿ ಮತ್ತು ಹೆಚ್ಚಿನ ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆಯನ್ನು ತರುತ್ತದೆ. ಕೆಲವೇ ಕೆಲವು ಸೇವೆಗಳಿಗಾಗಿ, ಇಡೀ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು Docker Compose ಸಾಕಷ್ಟು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಟ್ರಾಫಿಕ್ ಮಾದರಿಗಳು, ನಿಯೋಜನೆಯ ಆವರ್ತನ ಅಥವಾ ತಂಡದ ಗಾತ್ರವು ಅಗತ್ಯವಿರುವಾಗ ಮಾತ್ರ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಅನ್ನು ಪರಿಚಯಿಸಬೇಕು.
ಸೇವೆಗಳನ್ನು ತಂಡದ ಮಾಲೀಕತ್ವದೊಂದಿಗೆ ಹೊಂದಿಸಿ
ಸಣ್ಣ, ಸ್ವಾಯತ್ತ ತಂಡಗಳು ಒಂದು ಸೇವೆಯ ಸಂಪೂರ್ಣ ಜೀವನಚಕ್ರವನ್ನು ನಿರ್ವಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡಲು Microservices ಅನ್ನು ಭಾಗಶಃ ಕಂಡುಹಿಡಿಯಲಾಗಿತ್ತು. ಒಂದು ತಂಡವೇ ಹತ್ತು ಸೇವೆಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿದ್ದರೆ, ಸಮನ್ವಯ ವೆಚ್ಚಗಳು ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತವೆ ಮತ್ತು ಇದರಿಂದ ಉದ್ದೇಶಿತ ಪ್ರಯೋಜನಗಳು ಕುಂಠಿತಗೊಳ್ಳುತ್ತವೆ. ಹತ್ತು ಜನಕ್ಕಿಂತ ಕಡಿಮೆ ಇರುವ ತಂಡಗಳಿಗೆ monolith ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಬಹುದು ಎಂದು ಈ ಮಾರ್ಗದರ್ಶಿ ಸೂಚಿಸುತ್ತದೆ, ಇದು ಸರಳತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವ ಜೊತೆಗೆ ಮಾಡ್ಯುಲರ್ ಅಭಿವೃದ್ಧಿಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ.
ವಿರೋಧಾತ್ಮಕ ವಾದ: microservices ಯಾವಾಗ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತವೆ
Microservices ಮೂಲತಃ ಕೆಟ್ಟದ್ದೆಂದು ಈ ಮಾರ್ಗದರ್ಶಿ ಹೇಳುತ್ತಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ನ ವಿವಿಧ ಭಾಗಗಳು ವಿಭಿನ್ನ ಸ್ಕೇಲಿಂಗ್ ಅಗತ್ಯತೆಗಳನ್ನು ಹೊಂದಿರುವ ಅಥವಾ ನಿಯಂತ್ರಕ ನಿರ್ಬಂಧಗಳು ಕಟ್ಟುನಿಟ್ಟಾದ ಡೇಟಾ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಬಯಸುವ ಪರಿಸರಗಳಲ್ಲಿ, ಈ ಮಾದರಿಯು ನಿಜವಾದ ಮೌಲ್ಯವನ್ನು ನೀಡಬಲ್ಲದು. ಬಹು ಉತ್ಪನ್ನಗಳನ್ನು ಹೊಂದಿರುವ ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳಲ್ಲಿ, ಸ್ವತಂತ್ರ ಸೇವೆಗಳು ತಂಡಗಳ ನಡುವಿನ ಘರ್ಷಣೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತವೆ ಮತ್ತು ವೇಗವಾದ ಬಿಡುಗಡೆ ಚಕ್ರಗಳನ್ನು (release cycles) ಸಾಧ್ಯವಾಗಿಸುತ್ತವೆ ಎಂದು ಕಂಡುಬರುತ್ತದೆ.
ಇಲ್ಲಿ ಮುಖ್ಯವಾದುದು ಉದ್ದೇಶಪೂರ್ವಕತೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಫೀಚರ್ಗಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಲಕ್ಷಾಂತರ ವಿನಂತಿಗಳನ್ನು (requests) ನಿರ್ವಹಿಸಬೇಕಾದ ಅಗತ್ಯವಿದ್ದರೆ ಅಥವಾ ಹೊಸ ಉತ್ಪನ್ನವನ್ನು ಪ್ರತ್ಯೇಕ ವ್ಯವಹಾರ ಘಟಕವು ನಿರ್ವಹಿಸಬೇಕಾದ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ತಂಡವು microservices ಅನ್ನು ಅಳವಡಿಸಿಕೊಂಡರೆ, ಆ ಸಂಕೀರ್ಣತೆಯು ಸಮರ್ಥನೀಯವಾಗಿರುತ್ತದೆ. ನಿರ್ಧಾರವು ಸ್ಪಷ್ಟ ಅಗತ್ಯತೆಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ಕೇವಲ ಪ್ರಚಾರದ (hype) ಆಧಾರದ ಮೇಲೆ ತೆಗೆದುಕೊಳ್ಳಲ್ಪಟ್ಟಾಗ ಈ ಮಾರ್ಗದರ್ಶಿಯ ಎಚ್ಚರಿಕೆಗಳು ಅನ್ವಯಿಸುತ್ತವೆ.
ಮುಂದೆ ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು
ಹೆಚ್ಚು ಕಂಪನಿಗಳು cloud-native ಸ್ಟ್ಯಾಕ್ಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದಂತೆ, service mesh, distributed tracing ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ canary deployments ಸುತ್ತಲಿನ ಪರಿಕರಗಳು (tooling) ಹೆಚ್ಚು ಪರಿಣತಿ ಹೊಂದುತ್ತಿವೆ. ಈ ಪ್ರಗತಿಗಳು ಕಾರ್ಯಾಚರಣೆಯ ಅಡೆತಡೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತವೆ ಆದರೆ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ ಎತ್ತಿ ತೋರಿಸಲಾದ ಮೂಲಭೂತ ವಿನ್ಯಾಸದ ಆಯ್ಕೆಗಳನ್ನು ಇಲ್ಲವಾಗಿಸುವುದಿಲ್ಲ. ತಂಡಗಳು observability ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳು ಮತ್ತು async messaging ಫ್ರೇಮ್ವರ್ಕ್ಗಳ ವಿಕಸನವನ್ನು ಗಮನಿಸಬೇಕು, ಆದರೆ ತಾವು ಪ್ರಾರಂಭಿಸುವ ಪ್ರತಿಯೊಂದು ಸೇವೆಗೂ ಸ್ಪಷ್ಟವಾದ ಸಮರ್ಥನೆಯೊಂದಿಗೆ ಕೆಲಸ ಆರಂಭಿಸಬೇಕು.
ಸಾರಾಂಶ
Microservices ಎಂಬುದು ಒಂದು ಗುರಿಯನ್ನು ತಲುಪಲು ಬಳಸುವ ಸಾಧನವೇ ಹೊರತು, ಅದುವೇ ಗುರಿಯಲ್ಲ. ಉತ್ತಮವಾಗಿ ರಚಿಸಲಾದ monolith ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ, ಪ್ರತಿ ಸೇವೆಗೆ ಅದರ ಡೇಟಾದ ಮೇಲೆ ನಿಜವಾದ ಮಾಲೀಕತ್ವವನ್ನು ನೀಡಿ, ಸಾಧ್ಯವಿರುವ ಕಡೆ ಅಸಿಂಕ್ರೋನಸ್ ಸಂವಹನವನ್ನು ಬಳಸಿ ಮತ್ತು ಮೊದಲ ಸಾಲಿನ ಕೋಡ್ನಿಂದಲೇ resilience ಮತ್ತು observability ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ. ವ್ಯವಹಾರದ ಅಗತ್ಯತೆ ಸ್ಪಷ್ಟವಾದಾಗ ಮಾತ್ರ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೇವೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ; ಇಲ್ಲದಿದ್ದರೆ, ಸಮಸ್ಯೆಯ ಅಗತ್ಯಕ್ಕೆ ತಕ್ಕಂತೆ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಸರಳವಾಗಿ ಇರಿಸಿ.