Cloud connections, how to integrate SaaS services
By their very datacentre-based web-linked existence and their essentially abstracted virtualised shape and circumference, all applications that are deployed and run in cloud environments or are delivered as SaaS should (or at least could) be connected, in theory at least.
Of course, not all SaaS services or SaaS-based cloud components are connected, but let’s dig deeper to ask why and look at how (when and where needed) we can forge and fuse more effective connections, bridges and integration points.
Because a cloud computing ‘instance’ all on its lonesome is, in simplistic terms, really just a lump of compute, storage and ancillary intelligence services ranging from big data analytics capabilities, automations and the entire smörgåsbord of Machine Learning and Artificial Intelligence that we are now empowering with generative functions, clouds are on their own aren’t always as truly functional as we might imagine.
It is only when we start to connect clouds and think about essential aspects of Software-as-a-Service (SaaS) integration that we can start to consider the scope for computing with cloud that (for want of a diametrically different idiom) really lies at our feet.
Core questions
So then, the basic questions are:
- How do we connect SaaS entities?
- Who is responsible for connecting SaaS services?
- What elements of any given cloud stack need to be integrated externally, or indeed internally?
- When – in the cloud-native software application development lifecyle – should we connect SaaS services and the wider cloud estate?
- Why does connecting the cloud give us a technology service that represents more than the sum of the parts within?
- When should we break SaaS connections – and how?
- Where – in physical data sovereignty terms – can clouds be connected and where should borders, guardrails and port of entry checks be in place?
- What roles do automation and the wider world of RPA play in the cloud connection SaaS landscape?
Beyond APIs
We know that Application Programming Interfaces (APIs) give us the ability to connect SaaS services.
Written according to a defined syntax and structure, APIs – which typically themselves also exist as cloud-hosted cloud-native code structures – are designed to connect applications, services and data sources to other similar cloud resources or indeed to whole operating systems, databases and more.
But as we know, cloud connectivity neither starts with or ends with APIs, so where do they fit into the equation and how should we use these invaluable conduit structures safely, effectively and efficiently?
Data everything
If we further think about the existence of data warehouses, data lakehouses, data reefs (they don’t exist, but it’s in there to make sure you’re listening) and the interchange junctions that are now created by data marketplace & data exchanges, then how do we integrate these resources in the connected cloud conundrum and, for the sake of completeness, do we need to think about decoupling and separation of the same channels?
Beyond iPaaS?
We know that cloud itself offers core options to use integration Platform-as-a-Service (iPaaS) technologies, so we will aim to examine the role these platform-play IT functions offer, but to also go beyond iPaaS into new realms perhaps as-yet unknown.
This is the Computer Weekly Developer Network series on connected cloud and integrated SaaS service, let’s plug-in.
Image credit: Adrian Bridgwater.