چگونه دروازه های API مکمل ESB ها هستند

سازمان‌های وسواس مشتری باید دروازه‌های API را در کنار اتوبوس‌های خدمات سازمانی برای بهینه‌سازی اتصال سرویس معرفی کنند. در اینجا نحوه

برای شرکت های مدرن، ارائه تجربیات لذت بخش برای مشتریان ممکن است یک کار فراگیر باشد، اما وسواس در مورد مشتریان ارزش تلاش را دارد. تحقیق Forrester نشان می‌دهد که شرکت‌های وسواس مشتری ۲.۵ برابر رشد درآمد بالاتر و ۲.۲ برابر حفظ مشتری بهتر.

پیاده‌سازی سیستم‌هایی که مشتری را در مرکز قرار می‌دهند، مستلزم استفاده از تمام منابع سازمان به‌گونه‌ای است که بیشتر از مجموع اجزای آن باشد. اتصال بخش مهمی از هر زیرساخت مدرن فناوری اطلاعات است و پیچیده‌تر و مهم‌تر از همیشه می‌شود.

شرکت‌ها در سراسر صنایع از تمرکززدایی استقبال می‌کنند، خدمات ریز را جایگزین یکپارچه‌ها می‌کنند، و ایده استفاده کل سازمان‌ها از یک پشته فناوری را کنار می‌گذارند. در عوض، تیم‌ها از تنوع زبان‌ها، پلتفرم‌ها و راه‌حل‌ها استقبال می‌کنند و از APIها برای آزادسازی داده‌های Siled و مدرن‌سازی برنامه‌های قدیمی استفاده می‌کنند.

در این مقاله، دو عامل اتصال را با هم مقایسه می‌کنم: گذرگاه خدمات سازمانی (ESB) و دروازه API. هدف من توضیح دادن محیط‌ها و استفاده از مواردی است که هر کدام برای آنها مناسب‌تر است، از جمله توصیه‌هایی برای اینکه چگونه سازمان‌ها می‌توانند به بهترین نحو در مدرن‌سازی زیرساخت API خود به روشی متفکرانه و تدریجی پیش بروند.

ارتباط حاکم است

برای ارائه تجربیات دیجیتالی عالی به مشتریان، مهم است که تمام تعاملات سازمان خود را با مشتری در بازاریابی، فروش، فناوری اطلاعات و سایر بخش‌ها مرتبط کنید. فقط از طریق این اتصال کامل می توانید درک جامع تری از مشتری – تاریخچه سفارش، اطلاعات جمعیتی، داده های وفاداری، سابقه شکایت و موارد دیگر به دست آورید.

برای ایجاد این نمای ۳۶۰ درجه و تجربه حاصل از آن همه کانال، باید اتصال را به عنوان هسته استراتژی IT خود داشته باشید. هر سیستم و فرآیند کسب و کار در شرکت باید متصل باشد و به روز نگه داشته شود تا یک تجربه مشتری یکپارچه، شخصی و لذت بخش را فراهم کند.

اتصال و ESB

در گذشته، شرکت‌ها با تلاش‌های ارتباطی خود بر کارایی سازمانی تمرکز داشتند. اتوبوس خدمات سازمانی (ESB) در ابتدا به عنوان یک اتصال دهنده برای همه سرویس ها پیش بینی شده بود. در یک معماری سرویس‌محور (SOA) – که هنوز در حال رشد و تکامل بود – چالش اتصال سرویس‌های مختلف با استانداردها و پروتکل‌های مختلف قابل توجه بود و ESB برای مقابله با این چالش تلاش کرد.

در محیط‌هایی که متمرکزتر می‌شدند، ESB یک عامل قابل‌توجه برای معماری سازمانی یکپارچه بود. با نیاز به اتصال برنامه‌ها و پایگاه‌های داده بزرگ و داخلی، ESB به این اتصال دست یافت.

عملکرد ESB

نقش یک ESB جدا کردن سرویس‌ها و برنامه‌هایی است که در یک محیط فناوری اطلاعات مبتنی بر SOA وجود دارند. هر سرویس باید فقط یک ادغام واحد را با ESB راه اندازی کند و ESB آن سرویس را برای تمام سرویس های دیگر متصل به ESB در دسترس قرار می دهد. ESB به عنوان یک فروشگاه یک‌جا برای هر برنامه یا سرویسی که به دنبال مصرف یا انتشار داده است عمل می‌کند. ESB معمولاً این موارد را مدیریت می کند:

• تغییر قالب
• مذاکره پروتکل
• در صف
• منطق تجاری اضافی (در برخی موارد)

شکل ۱: گذرگاه خدمات سازمانی.

ESB یک واسطه برای تمام ارتباطات سرویس به سرویس است. ESB در نقش خود به‌عنوان مذاکره‌کننده و میانجی ارتباطات بین‌سرویسی، تمایل دارد به مرکز مرکزی زیرساخت‌های فناوری اطلاعات تبدیل شود و ویژگی‌های زیادی را ارائه می‌کند که به آن امکان می‌دهد تقریباً با هر سرویس، از جمله سرویس‌های قدیمی، یکپارچه شود.

ESB در مقیاس

همانطور که خدمات بیشتری از طریق ESB انجام می شود، درایو ارائه هر سرویس جدید از طریق ESB افزایش می یابد. یک “اثر شبکه” مانند برنامه های بزرگ شبکه های اجتماعی وجود دارد. هرچه افراد بیشتری در شبکه باشند، جذب دیگران برای پیوستن بیشتر است.

ESB در نهایت تبدیل به یک سرویس یکپارچه ضروری برای خود می شود. هر ادغام با ESB کمی فراتر می رود و حاوی منطق کمی است. طولی نکشید که منطق کسب و کار دیگر در خدمات فردی نیست، بلکه در ESB وجود دارد.

با رشد ESB، طبیعتاً به نگهداری و توجه بیشتری نیاز دارد. این مسئولیت معمولاً بر عهده یک تیم اختصاصی فناوری اطلاعات است. از آنجایی که ESB به عنوان یک هاب متمرکز برای تمام ارتباطات سرویس به سرویس عمل می کند، تیم ESB باید به طور مشابه عمل کند و با تیم های مختلف برنامه ارتباط برقرار کرده و کار کند. هماهنگ کردن ویژگی‌ها و عرضه‌های جدید از شکستن وابستگی‌های پایین‌دستی جلوگیری می‌کند.

معایب ESB ها در محیط های مدرن

در چشم‌انداز فناوری اطلاعات مدرن، توسعه خدمات به سمت رویکرد اول API و اولین spec حرکت کرده است. محیط های IT نیز به طور فزاینده ای توزیع می شوند. به هر حال، سازمان‌ها دیگر در محل یا حتی فقط ابری نیستند، بلکه با محیط‌های ابری ترکیبی و چند ابری کار می‌کنند. و تیم های آنها از نظر فیزیکی نیز توزیع شده اند. بنابراین، نقاط ادغام باید بتوانند انواع مختلفی از محیط ها را در بر گیرند.

حرکت به سمت میکروسرویس ها اساساً با ESB سنتی و یکپارچه در تضاد است. با تقسیم یکپارچه ESB به چندین سرویس متمرکز، می توانید بسیاری از مزایای ESB را حفظ کنید و در عین حال انعطاف و چابکی را افزایش دهید.

با درک درستی از ESBها و تغییراتی که در شرکت مدرن رخ می‌دهد، به دروازه API به عنوان مدلی برای ادغام.

دروازه API

یک دروازه API یک جزء زیرساخت مدرن بین مشتریان و خدمات است. دروازه API برخلاف ESB که تمام ارتباطات بین سرویسی را مدیریت می کند، به عنوان یک نقطه ورود برای مشتریان عمل می کند.

شکل ۲: دروازه API.

درگاه‌های API مانند ESBها، سرویس‌های متفاوتی را به یکدیگر متصل می‌کنند و آن اطلاعات را یکپارچه می‌کنند. با این حال، با ظهور APIها، وظیفه اتصال بیشتر متمرکز شده است.

تغییر از service-first (نمایش ESB) به API-first

APIها قرارداد استاندارد شده‌ای را ارائه می‌کنند که در محیط SOAP وجود نداشت. در شکل اصلی خود، ESB ها یک راه حل فنی برای یک مشکل استاندارد قبلی بودند. علاوه بر این، با ظهور اولین API توسعه، قرارداد بین مشتری و سرویس دیگر نیازی به انتظار برای توسعه سرویس ندارد و تیم‌های توسعه بیشتر از هم جدا می‌شوند. طراحی API-first منجر به استفاده مجدد و ارتباط بهتر برای «محصولات» تحت رهبری کسب‌وکار می‌شود.

درگاه API به شما امکان می دهد کار اتصال به هر API را ساده کنید. یک دروازه API نگرانی‌های متقابلی مانند احراز هویت، ثبت‌نام و نظارت و همچنین هماهنگ‌سازی را برای کاهش رفت و آمدها و ارائه API صحیح برای هر مشتری انجام می‌دهد.

درگاه های API مزایای بسیاری را ارائه می دهند، از جمله موارد زیر:

• ریزسرویس های ناب به تمرکز عملکردهای رایج برای کاهش هزینه های اضافی اجازه می دهند. به جای اختراع مجدد چرخ با هر سرویس، نگرانی های مقطعی مانند احراز هویت، ورود به سیستم و نظارت را می توان در سطح دروازه مدیریت کرد. این همچنین پیچیدگی کلی سیستم را کاهش می دهد، زیرا این نگرانی های مقطعی را می توان یک بار در دروازه پیاده سازی کرد.
• کلینت ها و سرویس های جدا شده امکان هماهنگی چندین میکروسرویس را در یک API مشتری فراهم می کند. به طور مشابه، کلاینت‌های مختلف می‌توانند API‌های متفاوتی را متناسب با نیازهایشان دریافت کنند، که در الگوی «انتهای پشتی برای جلویی» تغییر می‌کند.
• کشف سریع API توسعه مشتریان و ویژگی‌های جدید را سرعت می‌بخشد.
• کاهش تعداد درخواست‌های مورد نیاز عملکرد را افزایش می‌دهد. از طریق ارکستراسیون، چندین تماس API در انتهای پشتی را می توان در یک رفت و برگشت بین مشتری به دروازه API جمع کرد. این می تواند تجربه کاربر را بهبود بخشد.
• ثبات از طریق افزونه‌ها بهترین شیوه حاکمیت، امنیت، مشاهده‌پذیری و رسیدگی به سایر نگرانی‌های بین‌بخشی را ممکن می‌سازد.

مقایسه دروازه‌های API و ESB

شباهت‌های بین دروازه‌های API و ESB واضح است. هر دو راه حل مکان مشابهی را در معماری اشغال می کنند: به عنوان یک واسطه متمرکز برای ارتباط با خدمات. با این حال، دروازه‌های API مزایا و همچنین رویکرد مدرن‌تری برای دستیابی به آن مزایا ارائه می‌دهند.

مزیت اصلی این است که دروازه‌های API دامنه واضحی دارند. ESB ها به عنوان راه حل نهایی و همه چیز برای ارتباط بین همه برنامه ها و سرویس ها در نظر گرفته شدند. همانطور که آنها در این نقش رشد کردند، ویژگی های اضافی اضافه شدند که به قوانین و منطق تجاری اجازه می دهد تا در سیستم گنجانده شوند. به این ترتیب، ESB خیلی راحت شد. آنچه به عنوان پروژه ای برای کاهش پیچیدگی سیستم آغاز شد، به یک سیستم بسیار پیچیده تبدیل شد.

درگاه‌های API، از سوی دیگر، نقش متمرکزتری دارند. اول، دروازه API مسئول (به همان اندازه) تبدیل و مذاکره پروتکل نیست. همانطور که استانداردهای API به بلوغ رسیده اند، دروازه API می تواند از یک ESB نازک تر باشد و به طور خاص بر روی نگرانی های متقابل متمرکز شود. علاوه بر این، دروازه API عمدتاً بر روی ارتباط سرویس گیرنده-خدمت متمرکز است نه بر تمام ارتباطات سرویس به سرویس.

این ویژگی scope به دروازه‌های API اجازه می‌دهد تا از خزش دامنه جلوگیری کنند و از تبدیل شدن آنها به یکپارچگی دیگری که باید شکسته شوند، جلوگیری می‌کند. هنگام انتخاب یک دروازه API، مهم است که محصولی با هویت مشخص به جای مجموعه ویژگی های گسترده پیدا کنید.

برخلاف ماهیت متمرکز و بسیار جفت شده ESBها، دروازه‌های API امکان تمرکززدایی و توزیع را فراهم می‌کنند. این جنبه به هر دو نوع شرکت – آنهایی که در سفر به ابر هستند و کسانی که رویکرد ترکیبی دارند – قدرت می‌دهد.

زمان استفاده از دروازه API

درگاه‌های API برای کسب‌وکارهایی که بر حرکت سریع‌تر و ایجاد نوآوری متمرکز هستند مناسب هستند، که از طریق تیم‌های توزیع‌شده با استقلال و توانایی انجام کارشان به دست می‌آید.

ESBها این استاندارد را رد می کنند، زیرا آنها یکپارچه های بزرگ و متمرکز هستند که جفت یا وابستگی متقابل بین تیم ها را افزایش می دهند و استقلال را کاهش می دهند.

درگاه‌های API – با پورتال‌های توسعه‌دهنده – همچنین رویکرد طراحی اول را برای APIها تقویت می‌کنند و رویکرد مصرف مبتنی بر کشف را ترویج می‌کنند. با ارائه API مناسب برای هر مشتری، دروازه های API می توانند افزایش پذیرش، استفاده مجدد و سرعت تکرار را فعال کنند. دروازه‌های API همچنین مصرف و کشف APIها را در سراسر سازمان تسهیل می‌کنند و استفاده از ابزارهای بدون کد یا کم‌کد را امکان‌پذیر می‌سازند. باز هم، تمرکز بر فعال کردن تیم‌های مستقل به جای اتصال به تیم دروازه API است.

ESB ها و دروازه های API برای شرکت های مدرن

سفر یک شرکت مدرن شامل ایجاد چابکی و نوآوری سریع برای خوشحال کردن مشتری است. این سفر به افزایش استقلال تیم بستگی دارد و آن تیم ها را قادر می سازد تا لاغر و متمرکز باقی بمانند.

برای انجام این کار، سازمان‌های فناوری اطلاعات باید از نظر فنی ناهمگن و متنوع شوند تا همگن. آنها باید بهترین راه حل را برای هر مورد استفاده کنند. این تغییر نیازمند تنوع در راه حل ها و رویکردهای فنی است. به هر حال، تغییر جهت چند وجهی است. در اینجا چند نمونه آورده شده است:

• در محل یا فقط فضای ابری ➡ محیط‌های ابری ترکیبی و/یا چند ابری
• متمرکز ➡ توزیع شده
• معماری یکپارچه ➡ میکروسرویس
• سرورها ➡ بدون سرور، توابع، Kubernetes، کانتینرها
• زبان‌های سراسر سازمان ➡ تیم‌ها و سازمان‌های چند زبانه

با توجه به پلتفرم‌های یکپارچه‌سازی، اکنون باید تمرکز روی APIها باشد. اتصال API میدان نبرد رقابتی جدید است و دروازه‌های API راه حلی ویژه برای این منظور هستند.

در بیشتر شرایط، رویکرد ترکیبی تدریجی بهترین نقطه شروع است. با پیاده سازی یک دروازه API با API های جدید شروع کنید و به آرامی خدمات بیشتری را در صورت فرصت و زمان به ارمغان بیاورید. با گذشت زمان، این رویکرد تدریجی یکپارچه ESB را از هم خواهد پاشید. از این فرصت برای استخراج منطق تجاری در داخل ESB و توزیع آن در میکروسرویس های جدید استفاده کنید.

هدف این نیست که ESB را به طور کامل جایگزین کنیم، زیرا هنوز هم جایگاهی با خدمات قدیمی دارد که ممکن است هرگز ارتقا پیدا نکنند. تمرکز بر خروج ESB از مسیر حیاتی برای توسعه جدید است. با این حال، در میان مدت، قرارداد API با ایجاد وابستگی در سطح کسب و کار در بالای آنها، عمر طولانی‌تری خواهد داشت. به این ترتیب، تمرکز بر اتصال API برای شرکت مدرن ارزش ایجاد می کند.

مارکو پالادینو، مخترع، توسعه‌دهنده نرم‌افزار و کارآفرین اینترنتی مستقر در سانفرانسیسکو، مدیر ارشد فناوری و یکی از بنیان‌گذاران Kong Inc. مارکو در جامعه فناوری به خوبی شناخته شده است، به طور منظم در کنفرانس های صنعتی صحبت می کند (مانند اجلاس وب< /em>، KubeCon/ServiceMeshCon)، و قبلاً مقالاتی را در سایت های رسانه ای از جمله پشته جدید و < em>InfoWorld.

—

انجمن فناوری جدید مکانی را برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.