ಸಾಫ್ಟ್ವೇರ್ ತಂಡಗಳು Fabric Workload Dev Kit ಅನ್ನು ನೋಡುವಾಗ ಒಂದೇ ರೀತಿಯ ವರ್ಗೀಕರಣದ ತಪ್ಪನ್ನು ಮಾಡುತ್ತವೆ. ಅವರು ಇದನ್ನು ಒಂದು ಪಬ್ಲಿಷಿಂಗ್ ಪೈಪ್ಲೈನ್, ಸರ್ಟಿಫಿಕೇಶನ್ ಚೆಕ್ಲಿಸ್ಟ್ ಮತ್ತು ಪಾರ್ಟ್ನರ್ ಪೋರ್ಟಲ್ ಎಂದು ನೋಡುತ್ತಾರೆ. ಅಂದರೆ, ಅವರು ಇದನ್ನು ಒಂದು ಮಾರ್ಕೆಟ್ಪ್ಲೇಸ್ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಗ್ರಾಹಕರು ತಮ್ಮ Microsoft ಸ್ಟ್ಯಾಕ್ ಜೊತೆಗೆ ಬಳಸಬಹುದಾದ ಒಂದು 'add-in' ಎಂದು ಅವರು ಕಲ್ಪಿಸಿಕೊಳ್ಳುತ್ತಾರೆ.
ಇದು ತಪ್ಪು ದೃಷ್ಟಿಕೋನ. Fabric workload ಎಂಬುದು ಕೇವಲ ಒಂದು phụಂಗ (accessory) ಅಲ್ಲ. ಇದು ಒಂದು 'native surface'. ಒಮ್ಮೆ ನಿಯೋಜಿಸಿದ ನಂತರ (deployed), ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ Lakehouse, Power BI ಮತ್ತು Notebook ನಂತೆಯೇ ಒಂದೇ ಶೆಲ್ನೊಳಗೆ ಇರುತ್ತದೆ. ಇದು ವರ್ಕ್ಸ್ಪೇಸ್ನಲ್ಲಿ ತನ್ನದೇ ಆದ 'item type' ಅನ್ನು ಪಡೆಯುತ್ತದೆ. ಬಳಕೆದಾರರು "New" ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ಇದು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ UI, Fabric ಕ್ರೋಮ್ನಲ್ಲೇ ರেন্ডರ್ ಆಗುತ್ತದೆ, ಪಾಪ್-ಔಟ್ ಟ್ಯಾಬ್ನಲ್ಲಿ ಅಲ್ಲ. ನಿಮ್ಮ ಫೀಚರ್ ಸೆಟ್ ಡೇಟಾ ತಂಡಗಳು ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುವ ಸ್ಥಳದಲ್ಲೇ ಇರುತ್ತದೆ. ಇದು ಕೇವಲ ವಿತರಣೆಯ ಸೈಡ್ಬಾರ್ ಅಲ್ಲ; ಇದು Microsoft ನ ಡೇಟಾ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ ಮಾಡಿಕೊಂಡಿರುವ ಒಂದು ರಚನಾತ್ಮಕ ಬದ್ಧತೆ (structural commitment). ಇದನ್ನು ಕೇವಲ ಒಂದು ಲಿಸ್ಟಿಂಗ್ ಎಂದು ಪರಿಗಣಿಸಿದರೆ, ನೀವು ನಿಯಂತ್ರಣವಿಲ್ಲದ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನೊಳಗೆ ಸಿಲುಕಿಕೊಳ್ಳಬಹುದು.
ನೇಟಿವ್ ಅನುಕೂಲ (The Native Advantage)
ನೀವು Fabric ಗಾಗಿ ನಿರ್ಮಿಸಿದಾಗ, ನೀವು ಹೋಸ್ಟ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನ ವಿಶ್ವಾಸ ಮತ್ತು ಸಂದರ್ಭವನ್ನು (context) ಪಡೆದುಕೊಳ್ಳುತ್ತೀರಿ. ನಿಮ್ಮ workload ಗೆ OneLake ಗೆ ಓದುವ ಮತ್ತು ಬರೆಯುವ (read and write) ಪ್ರವೇಶ ಸಿಗುತ್ತದೆ, ಅಂದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾವನ್ನು ಡಜನ್ಗಟ್ಟಲೆ ETL ಪೈಪ್ಲೈನ್ಗಳ ಮೂಲಕ ಕಾಪಿ ಮಾಡದೆ ನೇರವಾಗಿ Delta tables ಗಳನ್ನು ಕ್ವೇರಿ ಮಾಡಬಹುದು. Authentication Microsoft Entra ID ಮೂಲಕ ನಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸೈನ್-ಇನ್ ಆಗಿರುವ ಬಳಕೆದಾರರಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಿರ್ವಹಿಸಲು ಪ್ರತ್ಯೇಕ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ವಾಲ್ಟ್ (credential vault) ಅಗತ್ಯವಿಲ್ಲ, ಯಾವುದೇ SSO ಬ್ರಿಡ್ಜ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಭದ್ರತಾ ತಂಡವು ಚಿಂತಿಸಬೇಕಾದ ಫಿಶಿಂಗ್-ಪ್ರವೃತ್ತಿಯ ಪಾಸ್ವರ್ಡ್ ಪ್ರಾಂಪ್ಟ್ಗಳೂ ಇರುವುದಿಲ್ಲ.
ತಾಂತ್ರಿಕ ಅಂಶಗಳಷ್ಟೇ ಪ್ರಮುಖವಾಗಿ ಕಾರ್ಯಾಚರಣೆಯ ಪ್ರಭಾವ (operational gravity) ಕೂಡ ಮುಖ್ಯವಾಗುತ್ತದೆ. ಗ್ರಾಹಕರ ಡೇಟಾ ಅವರ ಸ್ವಂತ ಟೆನೆಂಟ್ನಲ್ಲೇ ಇರುವುದರಿಂದ, ಹೆಚ್ಚಿನ ಎಂಟರ್ಪ್ರೈಸ್ SaaS ಡೀಲ್ಗಳನ್ನು ಹಾಳುಮಾಡುವ ಪ್ರೊಕ್ಯೂರ್ಮೆಂಟ್ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ (procurement theater) ನೀವು ಪಾರಾಗಬಹುದು. CISO ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ ಬಗ್ಗೆ ಚರ್ಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಪ್ರೊಕ್ಯೂರ್ಮೆಂಟ್ ಆಫೀಸರ್ ಎಗ್ರೆಸ್ ಚಾರ್ಜ್ಗಳನ್ನು (egress charges) ಲೆಕ್ಕಹಾಕುವ ಅಗತ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ಸಾಫ್ಟ್ವೇರ್ ಅವರು ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಸುರಕ್ಷಿತ ವಲಯದೊಳಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆರೋಗ್ಯ ರಕ್ಷಣೆ, ಹಣಕಾಸು ಸೇವೆಗಳು, ಸರ್ಕಾರಿ ಏಜೆನ್ಸಿಗಳಂತಹ ನಿಯಂತ್ರಿತ ಉದ್ಯಮಗಳಿಗೆ ಮಾರಾಟ ಮಾಡುವ ಮಾರಾಟಗಾರರಿಗೆ, ಈ ಒಂದು ಗುಣವು ಹನ್ನೆರಡು ವಾರಗಳ ಭದ್ರತಾ ವಿಮರ್ಶೆಯನ್ನು ಕೇವಲ ಕೆಲವು ದಿನಗಳ ಸಂಭಾಷಣೆಯಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಬಹುದು.
ಎಚ್ಚರಿಕೆಗಳು ಎಲ್ಲಿ ಅಡಗಿವೆ (Where the Traps Hide)
ನೇಟಿವ್ ಸ್ಥಿತಿಯು ನೇಟಿವ್ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ಬರುತ್ತದೆ, ಮತ್ತು ಅವು ನಿರ್ಬಂಧಗಳಾಗಿ ಪರಿಣಮಿಸಬಹುದು.
ಮೊದಲನೆಯದಾಗಿ, ಕಂಪ್ಯೂಟ್ ಲೆಕ್ಕಾಚಾರ (compute math). ನಿಮ್ಮ ಲಾಭದ ಪ್ರಮಾಣವು (margins) ಈಗ Microsoft Capacity Units ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ನಿಮ್ಮ workload ಮಾಡುವ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಾಚರಣೆಯು ಗ್ರಾಹಕರ Spark jobs, Semantic models ಮತ್ತು Power BI ರಿಫ್ರೆಶ್ಗಳಿಗೆ ಬಳಸುವ ಅದೇ CU ಪೂಲ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. Microsoft ಬೆಲೆಯನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿದರೆ ಅಥವಾ ಹೊಸ ಸಾಮರ್ಥ್ಯದ ಹಂತಗಳನ್ನು (capacity tiers) ಪರಿಚಯಿಸಿದರೆ, ನಿಮ್ಮ ಘಟಕದ ಅರ್ಥಶಾಸ್ತ್ರವು (unit economics) ನಿಮ್ಮ ಸಮ್ಮತಿಯಿಲ್ಲದೆಯೇ ಬದಲಾಗುತ್ತದೆ. ನೀವು ಮೂಲಸೌಕರ್ಯ ಪದರವನ್ನು (infrastructure layer) ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ, ಅಂದರೆ ನೀವು ಅದನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು ಅದನ್ನು ಕೇವಲ ಅಂದಾಜಿಸಬಹುದು ಮತ್ತು ನಂಬಬಹುದು ಅಷ್ಟೆ.
ಎರಡನೆಯದಾಗಿ, ರೋಡ್ಮ್ಯಾಪ್ ಅಪಾಯವು ನಿಜವಾಗಿದೆ. ಉಪಯುಕ್ತ ಲಂಬ (vertical) ಫೀಚರ್ಗಳನ್ನು ಗಮನಿಸಿ, ನಂತರ ಅವುಗಳ ಸಮಾನವಾದ ಅಡ್ಡ (horizontal) ಫೀಚರ್ಗಳನ್ನು ಕೋರ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲೇ ಸೇರಿಸುವ ಪದ್ಧತಿಯನ್ನು Microsoft ಅನುಸರಿಸುತ್ತದೆ. ನಿಮ್ಮ ಮೌಲ್ಯ ಪ್ರಸ್ತಾಪವು (value proposition) ಸಾಮಾನ್ಯ ಡೇಟಾ ಕಾರ್ಯಗಳ ಮೇಲಿನ ಕೇವಲ ಒಂದು ತೆಳುವಾದ UI ವೆರಪ್ಪ್ ಆಗಿದ್ದರೆ, ನೀವು ಅಂತಿಮವಾಗಿ Redmond ವಶಪಡಿಸಿಕೊಳ್ಳಬಹುದಾದ ಭೂಮಿಯ ಮೇಲೆ ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ಇದಕ್ಕೆ ಏಕೈಕ ರಕ್ಷಣೆ ಎಂದರೆ ಆಳವಾದ ಜ್ಞಾನ ಮತ್ತು ಡೊಮೇನ್ ನಿರ್ದಿಷ್ಟತೆ (domain specificity). ಸಾಮಾನ್ಯ ಡೇಟಾ ಕ್ಲೀನಿಂಗ್ ಅಥವಾ ಸರಳ ವಿಶುವಲೈಸೇಶನ್ ಪರಿಕರಗಳು ಸಮಯದೊಂದಿಗೆ ಅಪ್ರಸ್ತುತವಾಗಬಹುದು. ಆದರೆ ಪ್ರೊಪ್ರೈಟರಿ ಮೆಷಿನ್ ಲರ್ನಿಂಗ್ ಮಾಡೆಲ್ಗಳು, ಉದ್ಯಮ-ನಿರ್ದಿಷ್ಟ ಲೆಕ್ಕಾಚಾರಗಳು ಅಥವಾ ಕಸ್ಟಮ್ ಟೆಲಿಮೆಟ್ರಿ ಸ್ಕೀಮಾಗಳನ್ನು ಬಳಸುವ ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ ಲಾಜಿಕ್ ಇವುಗಳು ಅನಿವಾರ್ಯವಾಗಿ ಉಳಿಯುವ ಹೆಚ್ಚಿನ ಅವಕಾಶವನ್ನು ಹೊಂದಿವೆ.
ಮೂರನೆಯದಾಗಿ, ಎಂಜಿನಿಯರಿಂಗ್ ಪ್ರಯತ್ನವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಕಡಿಮೆ ಅಂದಾಜಿಸಲಾಗುತ್ತದೆ. ಕ್ವಿಕ್ಸ್ಟಾರ್ಟ್ ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಮತ್ತು ಸ್ಯಾಂಪಲ್ ರೆಪೊಸಿಟರಿಗಳನ್ನು ನೋಡಿದರೆ ಒಂದು ಮಧ್ಯಾಹ್ನದಲ್ಲಿ workload ಅನ್ನು ಸಿದ್ಧಪಡಿಸಬಹುದು ಎಂದು ಅನಿಸುತ್ತದೆ. ನಿಮ್ಮ ಗುರಿ ಕೇವಲ ಡೆಮೊ ಆಗಿದ್ದರೆ ಅದು ಸಾಧ್ಯ. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ ಪರಿಸ್ಥಿತಿ ಬೇರೆಯೇ ಇರುತ್ತದೆ. ನೀವು ಸಂಪೂರ್ಣ ಬ್ಯಾಕೆಂಡ್ ಕಾಂಟ್ರಾಕ್ಟ್ ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಬೇಕು, ಐಟಂ ಲೈಫ್ಸೈಕಲ್ ಇವೆಂಟ್ಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕು, ನಿಮ್ಮ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಮತ್ತು Fabric ನಡುವಿನ ಸ್ಟೇಟ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸಬೇಕು ಮತ್ತು ಸಾಮರ್ಥ್ಯವು ಸ್ಥಗಿತಗೊಂಡಾಗ ಅಥವಾ ಮರುಸಂಪರ್ಕಗೊಂಡಾಗ ಸುಗಮವಾಗಿ ಚೇತರಿಸಿಕೊಳ್ಳಬೇಕು. ಬಳಕೆದಾರರು ಸ್ಪರ್ಶಿಸುವ ಮೇಲ್ಮೈ ಸರಳವಾಗಿರಬಹುದು, ಆದರೆ ಅದರ ಅಡಿಯಲ್ಲಿರುವ ಕಾಂಟ್ರಾಕ್ಟ್ ಅಷ್ಟು ಸರಳವಾಗಿಲ್ಲ.
ನಿರ್ಮಿಸಬೇಕೆ ಅಥವಾ ಬಿಡಬೇಕೆ? (Build It, or Skip It?)
ನಿರ್ಧಾರವು Microsoft ನ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಮೇಲಿನ ನಿಮ್ಮ ಉತ್ಸಾಹದ ಮೇಲೆ ಅಲ್ಲದೆ, ನಿಮ್ಮ ಮೌಲ್ಯವು ಎಲ್ಲಿಂದ ಉದ್ಭವಿಸುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರಬೇಕು.
ನಿರ್ಮಿಸಿ (Build) ಎಂದರೆ ನಿಮ್ಮ ಉತ್ಪನ್ನವು ಗ್ರಾಹಕರ ಡೇಟಾಕ್ಕೆ ಎಷ್ಟು ಹತ್ತಿರವಿದೆಯೋ ಅಷ್ಟು ಹೆಚ್ಚು ಮೌಲ್ಯವನ್ನು ಪಡೆಯುತ್ತದೆ ಎಂದರ್ಥ. ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳು, ಉದ್ಯಮ-ನಿರ್ದಿಷ್ಟ ಅನಾಲಿಟಿಕ್ಸ್ ಇಂಜಿನ್ಗಳು ಮತ್ತು ಗವರ್ನೆನ್ಸ್ ಪರಿಕರಗಳು ಇಲ್ಲಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ. ನಿಮ್ಮ ಖರೀದಿದಾರರು ಈಗಾಗಲೇ Microsoft ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಮತ್ತೊಂದು ವೆಂಡರ್ ಅನ್ನು ಸೇರಿಸಿಕೊಳ್ಳುವ ಬದಲು ವೆಂಡರ್ ವೆಚ್ಚವನ್ನು ಕ್ರೋಢೀಕರಿಸಲು ಬಯಸಿದರೆ ನಿರ್ಮಿಸಿ. ನಿಮ್ಮ ಬೌದ್ಧಿಕ ಆಸ್ತಿ (intellectual property) ಸ್ಟೋರೇಜ್ ಪದರಕ್ಕಿಂತ ಮೇಲಿರುವಾಗ—ಅಂದರೆ ಪ್ರೊಪ್ರೈಟರಿ ಡೊಮೇನ್ ಲಾಜಿಕ್, ಕಸ್ಟಮ್ ML ಇನ್ಫರೆನ್ಸ್ ಅಥವಾ ವಿಶಿಷ್ಟ ಎನ್ರಿಚ್ಮೆಂಟ್ ಪೈಪ್ಲೈನ್ಗಳು—ನಿರ್ಮಿಸಿ, ಏಕೆಂದರೆ ಅಂತಹ IP ಅನ್ನು Microsoft ಸಾಮಾನ್ಯ ರೂಪದಲ್ಲಿ ನಕಲು ಮಾಡುವುದು ಕಷ್ಟ.
ಕಡೆಗಣಿಸಿ (Skip) ನಿಮ್ಮ ಮೌಲ್ಯವು ಡೇಟಾ ಲೋಕಲಿಟಿ (data locality) ಗೆ ಸಂಬಂಧಿಸದಿದ್ದರೆ. ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸೂಟ್ ಅಥವಾ ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ API ಗೇಟ್ವೇ ವರ್ಕ್ಸ್ಪೇಸ್ನ ಒಳಗೆ ಇರಬೇಕಾಗಿಲ್ಲ. ನಿಮ್ಮ ಗುರಿ ಗ್ರಾಹಕರು ಮಲ್ಟಿ-ಕ್ಲೌಡ್ ನ್ಯೂಟ್ರಾಲ್ ಆಗಿರುವುದರ ಬಗ್ಗೆ ಹೆಮ್ಮೆಪಡುವವರಾಗಿದ್ದರೆ ಇದನ್ನು ಕಡೆಗಣಿಸಿ; ಅವರನ್ನು Fabric ಒಳಗೆ ನಿಯೋಜಿಸಲು (deploy) ಕೇಳುವುದು ಅವರ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು (architectural independence) ರಾಜಿ ಮಾಡಿಕೊಳ್ಳುವಂತಾಗುತ್ತದೆ. ನಿಮ್ಮ ಲಾಭದ ಮಾರ್ಜಿನ್ಗಳನ್ನು ರಕ್ಷಿಸಲು ಮೂಲಸೌಕರ್ಯ ವೆಚ್ಚಗಳ ಮೇಲೆ ಸೂಕ್ಷ್ಮ ನಿಯಂತ್ರಣ ಬೇಕಿದ್ದರೆ ಇದನ್ನು ಕಡೆಗಣಿಸಿ. Microsoft ನ ಕಂಪ್ಯೂಟ್ ಓಪೇಕ್ ಪೂಲ್ ಅನ್ನು ಬಾಡಿಗೆಗೆ ಪಡೆಯುವುದು ಕಾಸ್ಟ್ ಇಂಜಿನಿಯರಿಂಗ್ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯಾಗುವುದಿಲ್ಲ.
90-ದಿನಗಳ ವಾಸ್ತವ ಪರಿಶೀಲನೆ (Reality Check)
ಈ ಮೂರು ಹಂತಗಳ ಪ್ರಯೋಗವನ್ನು ನಡೆಸುವವರೆಗೆ ಸಂಪೂರ್ಣ ರೋಡ್ಮ್ಯಾಪ್ಗೆ ಬದ್ಧರಾಗಬೇಡಿ.
ದಿನ 1 ರಿಂದ 30: ಅತ್ಯಂತ ಕಷ್ಟದ ಭಾಗದ ಪ್ರೊಟೊಟೈಪ್ ತಯಾರಿಸಿ. ಒಂದು 'ಥಿನ್ ವರ್ಟಿಕಲ್ ಸ್ಲೈಸ್' ಅನ್ನು ನಿರ್ಮಿಸಿ, ಆದರೆ ಅದು ಅಸಮರ್ಪಕವಾಗಿದ್ದರೂ ಪ್ರಾಮಾಣಿಕವಾಗಿರಲಿ. ಒಂದು ಐಟಂ ಪ್ರಕಾರವನ್ನು ಆರಿಸಿ, 'create' ಮತ್ತು 'delete' ಅನ್ನು ಅಳವಡಿಸಿ, ಮತ್ತು OneLake ನಿಂದ ಓದುವ ಅಥವಾ ಅದಕ್ಕೆ ಬರೆಯುವ ಒಂದು ಬಳಕೆದಾರರ ಸಂವಹನವನ್ನು (user interaction) ನಿರ್ವಹಿಸಿ. ಗುರಿ ಸುಂದರವಾದ ಸ್ಕ್ರೀನ್ಶಾಟ್ ಪಡೆಯುವುದಲ್ಲ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು Fabric ನ ಲೈಫ್ಸೈಕಲ್ ಕಾಂಟ್ರಾಕ್ಟ್ ನಡುವಿನ ಘರ್ಷಣೆಯನ್ನು (friction) ಅಳೆಯುವುದು ಇದರ ಗುರಿಯಾಗಿದೆ.
ದಿನ 31 ರಿಂದ 60: ನೈಜ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ವೆಚ್ಚದ ಮಾದರಿಯನ್ನು ರೂಪಿಸಿ. ಒಂದು ಟ್ರಯಲ್ ಕೆಪಾಸಿಟಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಅದರ ಮೇಲೆ ವಾಸ್ತವಿಕ ಲೋಡ್ ಪ್ಯಾಟರ್ನ್ಗಳನ್ನು ಚಲಾಯಿಸಿ. ಪ್ರತಿ ಬಳಕೆದಾರರ ಕ್ರಿಯೆಗೆ ತಗಲುವ CU ಬರ್ನ್ ಅನ್ನು ಅಳೆಯಿರಿ. ನಿಮ್ಮ ನಿರೀಕ್ಷಿತ ಕನ್ಕರನ್ಸಿಗೆ (concurrency) ಅದನ್ನು ವಿಸ್ತರಿಸಿ ಅಂದಾಜಿಸಿ. ನಿಮ್ಮ ಮಾರ್ಜಿನ್ಗಳನ್ನು ಕೇವಲ ಊಹಿಸಬೇಡಿ. ಟ್ರಯಲ್ ಕೆಪಾಸಿಟಿಗಳು ಹೆಚ್ಚಾಗಿ ಪೇಯ್ಡ್ ಕೆಪಾಸಿಟಿಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ, ಆದ್ದರಿಂದ ಗರಿಷ್ಠ ಮಟ್ಟದ ಒತ್ತಡವನ್ನು ನೀಡಿ. ನಿಮ್ಮ ಪೈಲಟ್ ಸ್ಕೇಲ್ನ ಹತ್ತರಷ್ಟು ಪಟ್ಟು ಹೆಚ್ಚಿಸಿದಾಗ ಅಂಕಿಅಂಶಗಳು ನಿಲ್ಲದಿದ್ದರೆ, ಅವು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.
ದಿನ 61 ರಿಂದ 90: ಡಿಸೈನ್ ಪಾರ್ಟ್ನರ್ಗಳೊಂದಿಗೆ ದೃಢೀಕರಿಸಿ. ಕೇವಲ ಕುತೂಹಲಕ್ಕಾಗಿ ಕೇಳುವವರಲ್ಲದೆ, ನಿಜವಾದ Microsoft ಬಳಕೆದಾರರಾದ ಇಬ್ಬರು ಅಥವಾ ಮೂವರು ಗ್ರಾಹಕರನ್ನು ತರಬಡಿ. ನೇರವಾದ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ. ನೇಟಿವ್ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ (native deployment) ಅವರ ಸೆಕ್ಯೂರಿಟಿ ರಿವ್ಯೂ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಿತೇ? ಅವರ ಟೆನೆಂಟ್ ಅಡ್ಮಿನ್ ಇದನ್ನು ಸ್ಟ್ಯಾಂಡ್ಅಲೋನ್ SaaS ಅಪ್ಲಿಕೇಶನ್ಗಿಂತ ವೇಗವಾಗಿ ಅನುಮೋದಿಸುತ್ತಾರೆಯೇ? Fabric ಒಳಗೆ ಇರುವುದು ನಿಮ್ಮ ಟೂಲ್ಗಾಗಿ ಅವರು ಬಜೆಟ್ ಮಾಡುವ ರೀತಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆಯೇ? ಉತ್ತರಗಳು ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ನೀವು ನೋಡುತ್ತಿರುವುದು ಕೇವಲ ಮಾರ್ಕೆಟಿಂಗ್ ಇಂಟಿಗ್ರೇಷನ್ ಅನ್ನು ಹೊರತು ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಚಾನೆಲ್ ಅಲ್ಲ.
ಮೂಲಸೌಕರ್ಯವಾಗುವುದು (Becoming Infrastructure)
ಈ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ಭವಿಷ್ಯವು ಮಾನವ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳಲ್ಲ. ಅದು ಏಜೆಂಟ್ಗಳು (agents). AI ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ಗಳು ಚಾರ್ಟ್ ಪಡೆಯಲು ಸ್ಟ್ಯಾಂಡ್ಅಲೋನ್ SaaS ಪೋರ್ಟಲ್ಗಳಿಗೆ ಲಾಗ್ ಇನ್ ಆಗುವುದಿಲ್ಲ. ಅವು ಡೇಟಾ ಎಸ್ಟೇಟ್ಗೆ (data estate) ನೇರವಾದ, ದೃಢೀಕೃತ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುವ ವರ್ಕ್ಲೋಡ್ಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತವೆ. ನೀವು ಸರಿಯಾಗಿ ನಿರ್ಮಿಸಿದರೆ, ನೀವು ಕೇವಲ ಮನುಷ್ಯರು ತೆರೆಯುವ ಮತ್ತೊಂದು ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಆಗಿ ಉಳಿಯದೆ, ಏಜೆಂಟ್ ಕರೆ ಮಾಡುವ ಕಂಪ್ಯೂಟ್ ಲೇಯರ್ (compute layer) ಆಗುತ್ತೀರಿ.
Fabric ಅನ್ನು ಕೇವಲ ಒಂದು ಮಾರ್ಕೆಟ್ಪ್ಲೇಸ್ ಎಂದು ಪರಿಗಣಿಸಿದರೆ, ನೀವು ಬಳಸಿ ಬಿಸಾಡುವ ಒಂದು ವಿಜೆಟ್ (disposable widget) ಆಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತೀರಿ. ಅದನ್ನು ಗ್ರಾಹಕರ ಡೇಟಾ ಆರ್ಕಿಟೆಕ್ಚರ್ನ ಕೇಂದ್ರಕ್ಕೆ ತಲುಪುವ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಚಾನೆಲ್ ಎಂದು ಪರಿಗಣಿಸಿದರೆ, ನೀವು ಅವರ ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ಎಷ್ಟು ಆಳವಾಗಿ ಅಡಕವಾಗುತ್ತೀರಿ ಎಂದರೆ ಅಲ್ಲಿಂದ ಹೊರಬರುವುದು ದುಬಾರಿಯಾಗುತ್ತದೆ. ಕೇವಲ ನಿಮ್ಮ ಲಾಗಿನ್ ಬಾಕ್ಸ್ ಮಾತ್ರವಲ್ಲದೆ, ನಿಮ್ಮ ಲಾಜಿಕ್ ಕೂಡ ಆ ಎಸ್ಟೇಟ್ನ ಭಾಗವಾಗುವ ಹಾದಿಯನ್ನು ಆರಿಸಿ.