Developing a Custom API for Cloud and On-Premises Integration
Everyone wants to be in the Cloud.
Software as a Service (SaaS), Infrastructure as a Service (IaaP), Platform as a Service (PaaS), and other web-based solutions, have tremendous appeal.
Their up-front costs tend to be relatively low and they promise quick deployment and payback, are scalable and straightforward to maintain, and are generally nice and easy to use.
Yet these very benefits can lead to a proliferation of solutions in the cloud, even as many systems remain on-premises, so companies end up with software and data being spread across different environments. As a consequence response times are poor and information becomes fragmented – the exact opposite of what today’s technology promises.
Working with Hybrid Environments
In a recent InaPlex post (Cloud and On-Premises Integration Tips) we described how a purpose designed ETL could help deliver efficient integration across hybrid environments by using a combination of caching, and smart selection criteria and data manipulation.
This approach, however, is not appropriate for all hybrid systems integration. For instance, if a company has custom software, integration may not be able to rely on off-the-shelf connectors. Instead, data would need to be pulled from the cloud, dropped into an intermediate format (such as CSV or XML files) on-premises, and then picked up and processed by custom code. The introduction of this interim step can impact performance, and unnecessarily complicate the data consolidation process.
A lack of connectors is not the only challenge. Moving data across locations, or giving third parties (such as Partners or clients) access to proprietary cloud data, introduces significant security and compliance issues, of particular concern where sensitive customer data is concerned.
Building a Custom Web API
In situations where the environment has very particular requirements – such as complex security access or specialized on-premises legacy applications – the best solution may be to build a custom web API. This can be developed in one of many different environments, such as AWS or Google Coud Services, however at InaPlex we have a preference for Azure.
The Microsoft Azure ecosystem has a rich range of services handling diverse needs, from global reach to full disaster recovery. It utilizes leading edge technology, and fully supports both cloud and on-premises environments with a development environment incorporating excellent tools and comprehensive functions. Azure is also closely aligned with Microsoft software solutions, like Active Directory, which is especially helpful for managing security requirements.
Secure Cloud Access
A recent project illustrates a typical Azure development for hybrid environments. InaPlex worked with a Partner to develop a custom API for a major Realty Advisor providing services to financial institutions. The API provided access from the Advisor’s CRM cloud data to the clients’ on-premises systems. Access to the cloud was rigidly restricted to ensure each institution could only see and download information that fit their security profile, and transferred data was reformatted to meet each company’s unique requirements. Everything was developed using Visual Studio, and details of this project, the requirement, our solution and the benefits, can be found at blog post Fast, Secure Access to Cloud CRM with a Custom API.
It is fair to say that Cloud-based services will continue to proliferate and be adopted by companies, however enterprise based systems will also be a feature of IT solutions for the foreseeable future. This means that companies need to consider carefully how to navigate the intersection of enterprise and cloud systems.
Managing hybrid setups is fraught with difficulties such as controlling security, flexibility, scalability and logistics across the discrete environments. As this post has noted, a single development process does not work for every business need that arises, so understanding the issues surrounding requirements, and the various merits of potential approaches is imperative. Only in this way will it be possible to choose an appropriate implementation to meet the business need.