Custom Built or Pre-Packaged API?
I felt the power, the power as if I had everything I needed when I first built a customized API with Python3, during my Cisco DevNet training. Without API, my program was useless since all the data I needed to process was external, out of reach without API.
System integration with APIs plays a crucial role during system development by enabling disparate software applications, systems, and services to communicate and work together. Specifically, APIs define the methods and data formats that different software components should use for interaction, essentially serving as a bridge between different software systems.
Integrating SaaS applications like ServiceNow or Salesforce into an existing platform typically requires use of APIs, as well as potentially middleware platforms or integration tools. Other than the vendor-specific API toolkit, there is a wide range of commercial integration platforms to choose from.
- MuleSoft Anypoint Platform: MuleSoft is owned by Salesforce and is deeply integrated with it, but it can also be used to connect to other applications like ServiceNow.
- Dell Boomi: Boomi is a multi-tenant platform that provides cloud-based integration, API management, and Master Data Management services. It supports integration with a wide range of applications including ServiceNow and Salesforce.
- Jitterbit: Jitterbit allows rapid connect SaaS, on-premises, and cloud applications and instantly infuses artificial intelligence into any business process.
Now we can even build self-integrating services!
A self-integrating application is an application that uses a combination of automated service discovery, metadata extraction and mapping, and machine learning to integrate itself into an existing application portfolio with minimal human interactions. It leverages technologies like machine learning, natural language processing, and AI to automate the integration process, reducing the need for manual labor and potentially speeding up the process.
It is part of modern integration trends when devising an integration strategy. It can be adapted to the system development for Azure Stack HCI.
-
Enable Self-Service Use of Integration Platforms: As part of Azure Stack HCI system development, the new trends suggest shifting from a centralized model to a self-service model. It will allow more agility and faster delivery of integration use cases by involving various roles in the integration process, under an Integration Strategy Empowerment Team (ISET).
-
Reuse Existing APIs: It’s suggested to avoid creating new APIs if existing ones can solve integration issues. API-led integration is crucial, and APIs themselves are essential for data exchange but they also require integration for data to be sent across interfaces.
- Hybrid Integration Platform (HIP) for Simplifying Hybrid and Multicloud Integration Scenarios: The document encourages using HIP to address the challenges posed by hybrid and multi-cloud environments. With Azure Stack HCI, I should be able to leverage hybrid deployment, hybrid patterns, hybrid roles, and hybrid endpoints.
- Limited Use of SaaS-Embedded Integration Tools: While the embedded integration features in SaaS offerings can provide quick solutions, it’s advised to use them only when they significantly reduce time to value. Azure Stack HCI with various SaaS applications might lack integrated monitoring, causing escalating costs, and duplication of skills.
Nerve System vs. API
I see API as a human nerve system. It responds to changes both inside and outside the body, sending signals to elicit appropriate responses. Similarly, an API can detect changes in the data or state of one application and communicate those changes to another, triggering appropriate responses.
As I do with my peripheral nerves and central nervous system by following new exercise trends, I should protect and improve my API.