ಪ್ರತಿ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡವೂ ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲದೆ ಬೆಳೆಯುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಯಸುತ್ತದೆ. ಟ್ರಾಫಿಕ್ ಸುಗಮವಾಗಿ ಏರುವುದು, ಸರ್ವರ್ಗಳು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದು ಮತ್ತು ಆದಾಯವು ನಿರಂತರವಾಗಿ ಹೆಚ್ಚಾಗುವುದು ನಮ್ಮ ಕನಸು. ಆದರೆ ವಾಸ್ತವವು ಬೇರೆಯೇ ಇರುತ್ತದೆ. ಒಂದು ವೈರಲ್ ಮಾರ್ಕೆಟಿಂಗ್ ಕ್ಯಾಂಪೇನ್ನಿಂದಾಗಿ ಬಳಕೆದಾರರ ಅಲೆ ಬಂದಾಗ, ಡೇಟಾಬೇಸ್ ಲಾಕ್ ಆಗುತ್ತದೆ ಮತ್ತು ಮರುದಿನ ಬೆಳಗಿನ ಮೂರು ಗಂಟೆಗೆ ಯಾರೋ ಒಬ್ಬರು ಆತಂಕದಿಂದ ಸರ್ವಿಸ್ಗಳನ್ನು ರೀಸ್ಟಾರ್ಟ್ ಮಾಡುತ್ತಿರುತ್ತಾರೆ. ಅಂತಹ ಸಮಯದಲ್ಲಿ ನಾವು ಬಳಸುವ ಪರಿಕರಗಳನ್ನು (tools) ದೂಷಿಸುವುದು ಸಹಜ. ನಮಗೆ ಹೆಚ್ಚಿನ ಕೋರ್ಗಳು (cores), ವೇಗವಾದ ಡಿಸ್ಕ್ಗಳು ಅಥವಾ ಇನ್ನೊಂದು ಕ್ಯಾಷಿಂಗ್ ಲೇಯರ್ ಬೇಕಿತ್ತು ಎಂದು ನಾವು ನಮಗೆ ನಾವೇ ಹೇಳಿಕೊಳ್ಳುತ್ತೇವೆ. ಆದರೆ ಬೆಳವಣಿಗೆಯು ಹಾರ್ಡ್ವೇರ್ನಿಂದ ಬರುವುದಿಲ್ಲ; ಅದು ರಚನೆಯಿಂದ (structure) ಬರುತ್ತದೆ. ನಿಮ್ಮ ಅಡಿಪಾಯವು ಹೊರೆಯನ್ನು ಹಂಚಿಹಂಚಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಪ್ರತಿಯೊಬ್ಬ ಹೊಸ ಬಳಕೆದಾರನೂ ಗೆಲುವಿನ ಬದಲು ಹೊರೆಯಾಗುತ್ತಾನೆ.
ದೌರ್ಬಲ್ಯಗೊಂಡ ಅಡಿಪಾಯವನ್ನು ಪರಿಕರಗಳು (Tools) ಏಕೆ ಉಳಿಸಲಾರವು
ನೀವು ನೂರಾರು ಕ್ಲೌಡ್ ಇನ್ಸ್ಟೆನ್ಸ್ (cloud instances) ಪ್ರಾರಂಭಿಸಬಹುದು, ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳ ನಡುವೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ಗಳನ್ನು (load balancers) ಸೇರಿಸಬಹುದು ಮತ್ತು ಗ್ಲೋಬಲ್ ಕಂಟೆಂಟ್ ಡೆಲಿವರಿ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಪ್ರತಿಯೊಂದು ಸ್ಟ್ಯಾಟಿಕ್ ಅಸೆಟ್ ಅನ್ನು ಕ್ಯಾಶ್ ಮಾಡಬಹುದು. ಇವೆಲ್ಲವೂ ಬಲವರ್ಧಕಗಳು (force multipliers). ಆದರೂ, ಶೂನ್ಯವನ್ನು ಎಷ್ಟೇ ಗುಣಿಸಿದರೂ ಅದು ಶೂನ್ಯವೇ ಇರುತ್ತದೆ. ಗೊಂದಲಮಯ ಅವಲಂಬನೆಗಳನ್ನು (tangled dependencies) ಹೊಂದಿರುವ ಒಂದು ಮೊನೊಲಿಥಿಕ್ ಅಪ್ಲಿಕೇಶನ್ (monolithic application), ಅದರ ಅಡಿಯಲ್ಲಿ ಎಷ್ಟೇ ಶಕ್ತಿಯುತವಾದ ಹಾರ್ಡ್ವೇರ್ ಇದ್ದರೂ ತನ್ನದೇ ತೂಕಕ್ಕೆ ಅಡಗಿಹೋಗುತ್ತದೆ.
ಉತ್ಪನ್ನಗಳ ಕ್ಯಾಟಲಾಗ್, ಪಾವತಿ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಬಳಕೆದಾರರ ದೃಢೀಕರಣ ಎಲ್ಲವೂ ಒಂದೇ ಕೋಡ್ಬೇಸ್ನಲ್ಲಿ (codebase) ಇರುವ ಒಂದು ಆನ್ಲೈನ್ ಸ್ಟೋರ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಚೆಕ್ಔಟ್ ಪ್ರಕ್ರಿಯೆಯು ನಿಧಾನವಾದಾಗ, ಇಡೀ ಸೈಟ್ ಕುಸಿಯುತ್ತದೆ. ಲಾಗಿನ್ ಪೇಜ್ ತಡವಾಗುತ್ತದೆ. ಬ್ರೌಸಿಂಗ್ ಅನುಭವವು ಹದಗೆಡುತ್ತದೆ. ಉಳಿದ ಎಲ್ಲವನ್ನೂ ಸ್ಕೇಲ್ ಮಾಡದೆ ಕೇವಲ ಆ ಒಂದು ಅಡಚಣೆಯನ್ನು (bottleneck) ಮಾತ್ರ ಸ್ಕೇಲ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ದುಬಾರಿ, ಅಸಮರ್ಥ ಮತ್ತು ಅಸ್ಥಿರವಾದ ವಿಧಾನ. ಬಳಕೆದಾರರು ತಕ್ಷಣ ಲೋಡ್ ಆಗಬೇಕಾದ ಪೇಜ್ಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ, ನೀವು ಯಾರಿಗೂ ಪ್ರಯೋಜನವಾಗದ ಕಂಪ್ಯೂಟ್ ಪವರ್ಗಾಗಿ ಹಣ ವ್ಯಯಿಸುತ್ತಿರುತ್ತೀರಿ.
ಈ ಬಲೆಗೆ ಸಿಲುಕದಂತೆ ತಪ್ಪಿಸಲು ಆರ್ಕಿಟೆಕ್ಚರ್ (Architecture) ആണ് ಉತ್ತರ. ನಿಮ್ಮ ಪರಿಕರಗಳು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆಯೇ ಅಥವಾ ಹಾನಿ ಮಾಡುತ್ತವೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಅದೃಶ್ಯ ಅಸ್ಥಿಪಂಜರವೇ ಈ ಆರ್ಕಿಟೆಕ್ಚರ್.
ದೃಢವಾದ ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂದರೆ ನಿಜವಾಗಿ ಏನು
ದೃಢವಾದ ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂದರೆ ಸರಳವಾಗಿ ಜವಾಬ್ದಾರಿಗಳು ಎಲ್ಲಿ ಇರಬೇಕು ಎಂಬ ಯೋಜನೆ. ಇದು ಆರಂಭದಲ್ಲೇ ಕಷ್ಟಕರವಾದ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತದೆ. ಒಂದು ಭಾಗವು ಮುರಿದರೆ ಏನಾಗುತ್ತದೆ? ರೆಕಮೆಂಡೇಶನ್ ಇಂಜಿನ್ ಅನ್ನು ಮುಟ್ಟದೆಯೇ ನೀವು ಬಿಲ್ಲಿಂಗ್ ಲಾಜಿಕ್ ಅನ್ನು ಬದಲಾಯಿಸಬಲ್ಲಿರಾ? ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಒಂದು ಮೂಲೆಯಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಏರಿಕೆ ಕಂಡುಬಂದಾಗ, ಉಳಿದ ವ್ಯವಸ್ಥೆಯು ಸುಗಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಲ್ಲದೇ? ಈ ಪ್ರಶ್ನೆಗಳು ನೀವು ಬಳಸುವ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆ, ಫ್ರೇಮ್ವರ್ಕ್ ಅಥವಾ ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ನ ಆಯ್ಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿವೆ.
ಒಳ್ಳೆಯ ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿಮ್ಮ ನಿರ್ಧಾರಗಳನ್ನು ಬದಲಾಯಿಸಿಕೊಳ್ಳಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಇದು ಸ್ಪಷ್ಟವಾದ ಗಡಿಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಒಂದು ತಂಡದ ಪ್ರಯೋಗವು ಇನ್ನೊಂದು ತಂಡದ ಪ್ರೊಡಕ್ಷನ್ ವರ್ಕ್ಲೋಡ್ ಅನ್ನು ಅಸ್ಥಿರಗೊಳಿಸುವುದಿಲ್ಲ. ಇದು ವೈಫಲ್ಯವನ್ನು (failure) ಆಕಸ್ಮಿಕವೆಂದು ಪರಿಗಣಿಸದೆ, ಒಂದು ಸಾಮಾನ್ಯ ಕಾರ್ಯನಿರ್ವಣಿಕೆಯ ಭಾಗವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ನೀವು ವೈಫಲ್ಯವನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು ವಿನ್ಯಾಸಗೊಳಿಸಿದಾಗ, ನೀವು ಗಾಜಿನ ಮನೆಗಳನ್ನು ಕಟ್ಟುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಬಾಗುವಂತಹ (flexible) ರಚನೆಗಳನ್ನು ಕಟ್ಟಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.
ಮೈಕ್ರೋಸರ್ವಿಸಸ್ ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾದರಿಯಾಗಿ
ಅಂತಹ ರಚನೆಯನ್ನು ಸಾಧಿಸಲು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗವೆಂದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮೈಕ್ರೋಸರ್ವಿಸಸ್ಗಳಾಗಿ (microservices) ವಿಭಜಿಸುವುದು. ಒಂದು ಬೃಹತ್ ಕೋಡ್ಬೇಸ್ಗೆ ಬದಲಾಗಿ, ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಣ್ಣ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೀರಿ. ಪ್ರತಿಯೊಂದು ಭಾಗವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಪಾವತಿ ಸೇವೆ (payment service) ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಇನ್ವೆಂಟರಿ ಸೇವೆ (inventory service) ಸ್ಟಾಕ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ. ನೋಟಿಫಿಕೇಶನ್ ಸೇವೆ (notification service) ಇಮೇಲ್ ಮತ್ತು ಪಠ್ಯ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಅವುಗಳು ಡೈರೆಕ್ಟ್ ಮೆಮೊರಿ ಅಕ್ಸೆಸ್ ಅಥವಾ ಹಂಚಿಕೆಯ ಡೇಟಾಬೇಸ್ ಟೇಬಲ್ಗಳ ಬದಲಿಗೆ ನಿರ್ದಿಷ್ಟ ಇಂಟರ್ಫೇಸ್ಗಳ ಮೂಲಕ ಸಂವಹನ ನಡೆಸುತ್ತವೆ.
ಈ ಪ್ರತ್ಯೇಕತೆಯು ತಾಂತ್ರಿಕವಾಗಿ ಮತ್ತು ಸಾಂಸ್ಥಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ನಿಜವಾದ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ.
ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಹಾಳು ಮಾಡದೆಯೇ ಸಣ್ಣ ಭಾಗಗಳನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿ
ಸೇವೆಗಳು ಸಣ್ಣದಾಗಿದ್ದಾಗ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಉದ್ದೇಶ ಹೊಂದಿದ್ದಾಗ, ನೀವು ಇಡೀ ವ್ಯವಸ್ಥೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದೆ ಒಂದು ಭಾಗವನ್ನು ಸರಿಪಡಿಸಬಹುದು (patch). ನಿಮ್ಮ ತಂಡವು ಶಿಪ್ಪಿಂಗ್ ಲೆಕ್ಕಾಚಾರದ ಅಲ್ಗಾರಿದಮ್ನಲ್ಲಿ ದೋಷವನ್ನು (bug) ಕಂಡುಕೊಂಡರೆ, ನೀವು ಆ ನಿರ್ದಿಷ್ಟ ಸೇವೆಯನ್ನು ಸರಿಪಡಿಸಿ ಸ್ವತಂತ್ರವಾಗಿ ನಿಯೋಜಿಸಬಹುದು (deploy). ಉಳಿದ ಅಪ್ಲಿಕೇಶನ್ ಸುಗಮವಾಗಿ ಚಲಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ಇನ್ನೂ ಉತ್ಪನ್ನಗಳನ್ನು ನೋಡಬಹುದು, ಲಾಗಿನ್ ಆಗಬಹುದು ಮತ್ತು ಕಾರ್ಟ್ಗೆ ವಸ್ತುಗಳನ್ನು ಸೇರಿಸಬಹುದು. ಯಾವುದೇ ಬದಲಾವಣೆಯ ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿ (blast radius) ಅತ್ಯಂತ ಕಡಿಮೆ ಇರುತ್ತದೆ. ಒಂದು ಹೆಲ್ಪರ್ ಫಂಕ್ಷನ್ನಲ್ಲಿನ ಸಣ್ಣ ತಪ್ಪಿನಿಂದಾಗಿ ಚೆಕ್ಔಟ್, ರಿಜಿಸ್ಟ್ರೇಶನ್ ಮತ್ತು ರಿಪೋರ್ಟಿಂಗ್ ಎಲ್ಲವೂ ಏಕಕಾಲದಲ್ಲಿ ಸ್ಥಗಿತಗೊಳ್ಳುವ ಮೊನೊಲಿತ್ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಇದನ್ನು ಹೋಲಿಸಿ ನೋಡಿ.
ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಾದಾಗ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಗಳನ್ನು ಸ್ಕೇಲ್ ಮಾಡಿ
ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಎಂದಿಗೂ ಏಕರೂಪವಾಗಿ ಇರುವುದಿಲ್ಲ. ಫ್ಲ್ಯಾಶ್ ಸೇಲ್ (flash sale) ಸಮಯದಲ್ಲಿ, ನಿಮ್ಮ ಕಂಟೆಂಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್ ಸುಮ್ಮನೆ ಇದ್ದರೂ, ನಿಮ್ಮ ಆರ್ಡರ್ ಪೈಪ್ಲೈನ್ ಮೇಲೆ ಒತ್ತಡವಿರಬಹುದು. ಬಿಗಿದ ಸಂಬಂಧ ಹೊಂದಿರುವ (tightly coupled) ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ನೀವು ಎಲ್ಲವನ್ನೂ ಸ್ಕೇಲ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಅಥವಾ ಯಾವುದನ್ನೂ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಮೈಕ್ರೋಸರ್ವಿಸಸ್ಗಳೊಂದಿಗೆ, ನೀವು ನಿಮ್ಮ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಖರವಾಗಿ ಬಳಸಬಹುದು. ಚೆಕ್ಔಟ್ ಸೇವೆಯ ಹೆಚ್ಚಿನ ಇನ್ಸ್ಟೆನ್ಸ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿ. ಉತ್ಪನ್ನಗಳ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ಅದರ ಸಾಮಾನ್ಯ ಮಟ್ಟದಲ್ಲಿ ನಡೆಯಲು ಬಿಡಿ. ಉತ್ಪನ್ನ ಬಿಡುಗಡೆಯ ಸಮಯದಲ್ಲಿ, ನಿಮ್ಮ ಸರ್ಚ್ ಇಂಡೆಕ್ಸ್ ಶಾಂತವಾಗಿದ್ದರೂ, ಇಮೇಜ್ ಪ್ರೊಸೆಸಿಂಗ್ ವರ್ಕರ್ಗಳು ಸಾವಿರಾರು ಥಂಬ್ನೈಲ್ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು. ಕೇವಲ ಇಮೇಜ್ ವರ್ಕರ್ಗಳಿಗಾಗಿ ಸರ್ಚ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ವಿಸ್ತರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಬಳಕೆದಾರರಿಗೆ ಅಗತ್ಯವಿರುವ ಕಡೆ ನೀವು ಹಣ ವ್ಯಯಿಸುತ್ತೀರಿ ಮತ್ತು ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯು ಒತ್ತಡದಲ್ಲೂ ಸ್ಪಂದನೀಯವಾಗಿರುತ್ತದೆ.
ದೀರ್ಘಾವಧಿಯ ಡೌನ್ಟೈಮ್ ಇಲ್ಲದೆ ಹೊಸ ಕೋಡ್ ಅನ್ನು ನಿಯೋಜಿಸಿ
ಸಣ್ಣ ಸೇವೆಗಳು ಅಂತಹ ನಿಯೋಜನೆ ಮಾದರಿಗಳಿಗೆ (deployment patterns) ಅವಕಾಶ ನೀಡುತ್ತವೆ, ಇದು ನಿರ್ವಹಣಾ ಅವಧಿಗಳ (maintenance windows) ಅಗತ್ಯವನ್ನೇ ಇಲ್ಲದಂತೆ ಮಾಡುತ್ತದೆ. ನೀವು ರೋಲಿಂಗ್ ನಿಯೋಜನೆಗಳನ್ನು (rolling deployments) ಬಳಸಬಹುದು, ಅಂದರೆ ಉಳಿದವುಗಳು ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ನಿರ್ವಹಿಸುತ್ತಿರುವಾಗ, ಹೊಸ ಕೋಡ್ ಅನ್ನು ಕೆಲವು ಇನ್ಸ್ಟೆನ್ಸ್ಗಳಿಗೆ ಮಾತ್ರ ಕಳುಹಿಸುವುದು. ನಿಮ್ಮ ದೋಷದ ಪ್ರಮಾಣವನ್ನು (error rates) ಗಮನಿಸಿ, ಮತ್ತು ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಎಂದು ಅನಿಸಿದರೆ, ಸೆಕೆಂಡುಗಳಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು (requests) ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಮರುನಿರ್ದೇಶಿಸಿ. ಬ್ಲೂ-ಗ್ರೀನ್ ನಿಯೋಜನೆಗಳು (Blue-green deployments) ನಿಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸ ಪರಿಸರವನ್ನು ಸ್ಥಾಪಿಸಲು, ಅದನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ಕನಿಷ್ಠ ಅಪಾಯದೊಂದಿಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವರ್ಗಾಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ. ಯಾರೋ ಡೇಟಾಬೇಸ್ ಮೈಗ್ರೇಷನ್ಗಳನ್ನು (database migrations) ಕೈಯಾರೆ ಮಾಡುವಾಗ ಸಿಸ್ಟಮ್ ಗಂಟೆಗಟ್ಟಲೆ ಸ್ಥಗಿತಗೊಳ್ಳುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ವೇಗವಾಗಿ ನಿರ್ಮಿಸಿ
ದೊಡ್ಡ ಕೋಡ್ಬೇಸ್ಗಳು (codebases) ಎಚ್ಚರಿಕೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ. ಕೇವಲ ಒಂದು ಬದಲಾವಣೆಯು ಸಾವಿರಾರು ಸಂಬಂಧವಿಲ್ಲದ ಲಾಜಿಕ್ ಸಾಲುಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು, ಗಂಟೆಗಟ್ಟಲೆ ತೆಗೆದುಕೊಳ್ಳುವ ರಿಗ್ರೆಷನ್ ಪರೀಕ್ಷೆಗಳು (regression tests) ಮತ್ತು ರಾಕೆಟ್ ಉಡಾವಣೆಯಂತೆ ಭಾಸವಾಗುವ ನಿಯೋಜನಾ ವೇಳಾಪಟ್ಟಿಗಳನ್ನು ಬಯಸುತ್ತದೆ. ಸಣ್ಣ ಸೇವೆಗಳು ಆ ಭಯವನ್ನು ಹೋಗಲಾಡಿಸುತ್ತವೆ. ಒಂದು ತಂಡವು ತಮಗೆ ಪರಿಚಿತವಾಗಿರುವ ಸೇವೆಯಲ್ಲಿ ಕೆಲವು ನೂರಾರು ಸಾಲುಗಳನ್ನು ಮಾರ್ಪಡಿಸುವ ಮೂಲಕ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಿರ್ಮಿಸಬಹುದು. ಅವರು ಅದೇ ದಿನದಲ್ಲಿ ಕಮಿಟ್ (commit), ಪರೀಕ್ಷೆ ಮತ್ತು ಶಿಪ್ (ship) ಮಾಡಬಹುದು. ಆ ವೇಗವು ಕ್ರಮೇಣ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಸೇವೆಗಳು ಸ್ಪಷ್ಟವಾದ ಜವಾಬ್ದಾರಿಗಳಿಂದ ಬದ್ಧವಾಗಿರდესაც, ತಂಡಗಳು ಪರಸ್ಪರರ ಕೆಲಸದಲ್ಲಿ ಅಡಚಣೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ. ಅವರು ತಮ್ಮ ಡೊಮೇನ್ ಅನ್ನು ಅ부터 ಅಂತ್ಯದವರೆಗೆ (end to end) ನಿರ್ವಹಿಸುತ್ತಾರೆ.
ಸ್ವಾತಂತ್ರ್ಯವು ದೊಡ್ಡ ಅಡಚಣೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ
ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆ ಸ್ವಾತಂತ್ರ್ಯವು ಕೇವಲ ಸಾಂಸ್ಥಿಕ ಅನುಕೂಲಕ್ಕಾಗಿ ಮಾತ್ರವಲ್ಲ; ಅದು ರಚನಾತ್ಮಕ ವಿಮೆಯಾಗಿದೆ (structural insurance). ಒಂದು ವೇಳೆ ರೆಕಮೆಂಡೇಶನ್ ಇಂಜಿನ್ (recommendation engine) ಸ್ಥಗಿತಗೊಂಡರೆ, ಸ್ಟೋರ್ ಇನ್ನೂ ಉತ್ಪನ್ನಗಳನ್ನು ಮಾರಾಟ ಮಾಡಲೇಬೇಕು. ಅನಾಲಿಟಿಕ್ಸ್ ಪೈಪ್ಲೈನ್ (analytics pipeline) ತಪ್ಪಾದ ಇವೆಂಟ್ನಿಂದಾಗಿ ವಿಫಲವಾದರೆ, ಲಾಗಿನ್ ಸೇವೆ ಬಳಕೆದಾರರನ್ನು ದೃಢೀಕರಿಸುತ್ತಲೇ ಇರಬೇಕು. ಒಂದು ವೈಫಲ್ಯವು ಸಂಪೂರ್ಣ ಸ್ಥಗಿತಕ್ಕೆ ಕಾರಣವಾಗದಂತೆ ನೀವು ಸೇವೆಗಳ ನಡುವೆ ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ಗಳು (circuit breakers) ಮತ್ತು ಫಾಲ್ಬ್ಯಾಕ್ ಮಾರ್ಗಗಳನ್ನು (fallback paths) ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತೀರಿ. ಸಿಸ್ಟಮ್ ನಿಮ್ಮ ಬಳಕೆದಾರರೊಂದಿಗೆ ಬೆಳೆಯುತ್ತದೆ ಏಕೆಂದರೆ ಅದು ಒಡೆದು ಹೋಗದೆ ಒತ್ತಡವನ್ನು ತಡೆದುಕೊಳ್ಳಬಲ್ಲದು.
ಒಂದು ಎಚ್ಚರಿಕೆ: ಕುರುಡಾಗಿ ವಿಭಜಿಸಬೇಡಿ
ಇದರರ್ಥ ನೀವು ಮೊದಲ ದಿನವೇ ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ವಿಭಜಿಸಬೇಕು ಎಂದಲ್ಲ. ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳಿಗೆ (Microservices) ಸ್ಪಷ್ಟವಾದ ಗಡಿಗಳು ಬೇಕು. ಒಂದು ಡೊಮೇನ್ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಎಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದು ನಿಮ್ಮ ತಂಡಗಳಿಗೆ ಇನ್ನೂ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ಅವರು ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಯ ಬದಲಿಗೆ (distributed system) ವಿತರಿಸಿದ ಗೊಂದಲವನ್ನು (distributed mess) ಸೃಷ್ಟಿಸುತ್ತಾರೆ. ನೀವು ಕೋಡ್ ಸಂಕೀರ್ಣತೆಯನ್ನು ಕಾರ್ಯಾಚರಣೆಯ ಸಂಕೀರ್ಣತೆಗಾಗಿ (operational complexity) ಬದಲಾಯಿಸುತ್ತೀರಿ, ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನೀವು ಡಜನ್ಗಟ್ಟಲೆ ಲಾಗ್ ಸ್ಟ್ರೀಮ್ಗಳ ಮೂಲಕ ನೆಟ್ವರ್ಕ್ ವಿಳಂಬ (network latency), ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ಗಳು, ರಿಟ್ರೈ ಸ್ಟಾರ್ಮ್ಗಳು ಮತ್ತು ಅಬ್ಸರ್ವೇಬಿಲಿಟಿಯನ್ನು (observability) ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ. ನಿಧಾನಗತಿಯ ಚೆಕ್ಔಟ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುವುದು ಎಂದರೆ ಈಗ ನಾಲ್ಕು ನೆಟ್ವರ್ಕ್ ಹಾಪ್ಗಳು ಮತ್ತು ಮೂರು ವಿಭಿನ್ನ ಡೇಟಾ ಸ್ಟೋರ್ಗಳ ಮೂಲಕ ಒಂದೇ ವಿನಂತಿಯನ್ನು ಟ್ರೇಸ್ ಮಾಡುವುದು ಎಂದರ್ಥವಾಗಬಹುದು.
ನಿಮ್ಮ ತಂಡವು ಆ ಹೊರೆಯನ್ನು ಹೊರಲು ಸಿದ್ಧವಿಲ್ಲದಿದ್ದರೆ, ಪರಿಹಾರವು ಕಾಯಿಲೆಯನ್ನು விட ಕೆಟ್ಟದಾಗಿರುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ ಮಾಡ್ಯುಲರ್ ಮೊನೊಲಿತ್ (modular monolith) ಮೂಲಕ ಪ್ರಾರಂಭಿಸುವುದು ಬುದ್ಧಿವಂತಿಕೆಯ ಕ್ರಮವಾಗಿದೆ. ಅವು ಒಟ್ಟಿಗೆ ನಿಯೋಜನೆಯಾಗುತ್ತಿದ್ದರೂ ಸಹ, ಕೋಡ್ಬೇಸ್ನ ಒಳಗಡೆ ಪೇಮೆಂಟ್ ಲಾಜಿಕ್ ಅನ್ನು ಇನ್ವೆಂಟರಿ ಲಾಜಿಕ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡಿ. ಇಂಟರ್ನಲ್ APIs ಮತ್ತು ಒಂದೇ ಇಂಜಿನ್ನೊಳಗಿನ ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾಗಳೊಂದಿಗೆ ಗಡಿಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅನುಷ್ಠಾನಗೊಳಿಸಿ. ಆ ವಿಭಜನೆಗಳು ಸ್ಥಿರವಾಗಿವೆ ಎಂದು ಸಾಬೀತಾದಾಗ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಮಾದರಿಗಳು ಹೆಚ್ಚಿನ ವೆಚ್ಚವನ್ನು ಸಮರ್ಥಿಸಿದಾಗ, ಒಂದು ಸೇವೆಯನ್ನು ಹೊರತೆಗೆಯಿರಿ (extract). ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂಬುದು ಉದ್ದೇಶಪೂರ್ವಕವಾದ ಬಾಗಿಲುಗಳ ಸರಣಿಯಾಗಿರಬೇಕೇ ಹೊರತು, ನೀವು ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ಓದಿದ್ದಕ್ಕಾಗಿ ರಾತ್ರೋರಾತ್ರಿ ನಿರ್ಮಿಸಿದ ಗೋಡೆಗಳಲ್ಲ.
ಉದ್ದೇಶದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ
ಬಲಿಷ್ಠ ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂದರೆ ಐದು ವರ್ಷಗಳ ನಂತರದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮುನ್ಸೂಚನೆ ನೀಡುವುದಲ್ಲ. ಅದು ನಿಮಗೆ ಆಯ್ಕೆಗಳನ್ನು ನೀಡುವುದರ ಬಗ್ಗೆಯಾಗಿದೆ. ನಿಮ್ಮ ವೆಬ್ ಆಪ್ ಅನ್ನು ಬೆಳೆಸಲು ನೀವು ಕೇವಲ ಪರಿಕರಗಳ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಒತ್ತಡ ಹೆಚ್ಚಾಗುವ ಮೊದಲು ನೀವು ತೊಂದರೆಯಿಂದ ಹೊರಬರಲು ಯೋಚಿಸಬಹುದು. ಜವಾಬ್ದಾರಿಗಳ ನಡುವಿನ ಗಡಿಗಳನ್ನು ಗೌರವಿಸಿ. ತಮ್ಮ ವಿಧಿಯನ್ನು ತಾವೇ ನಿರ್ಧರಿಸುವ ಸಣ್ಣ, ಕೇಂದ್ರೀಕೃತ ಭಾಗಗಳನ್ನು ನಿರ್ಮಿಸಿ. ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ಹಾಳುಮಾಡದೆ ವೇಗವಾಗಿ ಚಲಿಸಲು ತಂಡಗಳಿಗೆ ಸ್ವಾಯತ್ತತೆಯನ್ನು (autonomy) ನೀಡಿ. ನೀವು ಬಲಿಷ್ಠ ಆರ್ಕಿಟೆಕ್ಚರ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದಾಗ, ನೀವು ನಂತರ ಸಮಯ ಮತ್ತು ಶ್ರಮವನ್ನು ಉಳಿಸುತ್ತೀರಿ ಏಕೆಂದರೆ ಸೈಟ್ ಉರಿಯುತ್ತಿರುವಾಗ ನೀವು ಕೋರ್ ಲಾಜಿಕ್ ಅನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ನಿಜವಾದ ಸಾರಾಂಶ
ಸ್ಕೇಲೆಬಿಲಿಟಿ (Scalability) ಎಂಬುದು ಬೆಳವಣಿಗೆ ಬಂದಾಗ ನೀವು ಸೇರಿಸುವ ವೈಶಿಷ್ಟ್ಯವಲ್ಲ. ಅದು ನಿಮ್ಮ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಜವಾಬ್ದಾರಿ ಹೇಗೆ ಹರಿಯುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನೀವು ಆರಂಭದಲ್ಲೇ ಮಾಡಿದ ಆಯ್ಕೆಗಳ ನೈಸರ್ಗಿಕ ಫಲಿತಾಂಶವಾಗಿದೆ. ಸರಿಯಾದ ವಿಭಜನೆಯನ್ನು ಆರಿಸಿ. ವೈಫಲ್ಯವನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ತೊಂದರೆ ನೀಡುವ ಭಾಗವನ್ನು ಸ್ಕೇಲ್ ಮಾಡಿ ಮತ್ತು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಭಾಗವನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ. ಹಾಗೆ ಮಾಡಿದರೆ, ನೀವು ನಂತರ ಸೇರಿಸುವ ಪರಿಕರಗಳು ನಿಜವಾಗಿಯೂ ಯಾವುದನ್ನಾದರೂ ಭದ್ರವಾಗಿ ತಲುಪಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.