Software as a Service (SaaS) solutions are often a quick way to get new capabilities into an organization’s portfolio. Smaller SaaS solutions are simple, web-based solutions which barely integrate with the organization’s other solutions, besides the identity and access management (which is often handled by federated authentication).

More complex or intermediate solutions require more integration focus, and a whole new market of Integration Platform as a Service (iPaaS) solutions came up to facilitate cross-cloud integrations. But even without the iPaaS offerings, integrations are often a mandatory part to leverage the benefits of the newly activated SaaS solution.

In this post I want to bring some thoughts on the integrations that might be needed to support customizing a SaaS solution.

Integrations versus customizations

There are plenty of ways to integrate solutions in a larger ecosystem. Most integrations focus on data integration (file transfers mostly) and service integration (using APIs or Enterprise Service Bus solutions), although many other creative methods are used to facilitate the integration of a SaaS within the organization’s portfolio.

This creativity, in my opinion, often transforms into customization of a SaaS solution rather than an integration approach. SaaS services are being extended with new, customized functionality, but in a way that we’re no longer thinking about integrating this customization with the SaaS, but injecting the SaaS with closely tied services. And SaaS providers are often happy to support this, as it binds the customer to their solution.

Now, customizations are not integrations, and integrations are not customizations. If you customize a SaaS offering, then you still need an integration between the custom development and the SaaS offering. Sometimes this integration is as simple as uploading the customization into the SaaS and the SaaS does the rest. Or the customization is a completely separate application service, which integrates over managed APIs with the SaaS. Or you use an intermediate solution that bridges the two solutions.

While many integrations are possible, I feel that there are a few integration approaches that are in most cases just wrong. One of these is linking the SaaS within your own private solution (network or cloud).

Don’t just extend a SaaS environment into your own

I don’t believe that it is wise to just extend a SaaS environment into your own, even when the SaaS provider enables this. Services like VPC peering, which can be used to link your VPC with the SaaS provider’s VPC, are easy ways to do so, but applying it without adjusting the architecture for it makes your long-term maintainability and security more challenging. How do you ensure that the SaaS does not abuse this link? How do you ensure that you don’t accidentally leak information to the SaaS? How do you ensure high availability and resiliency is retained?

In traditional architectures, we would have these provider’s locations considered as a separate network, and introduce the appropriate controls (like those offered by application firewalls, reverse proxies, etc.) in between the business application and the third party. This would often be facilitated by the network operations teams, and governed through more centralized environments.

In cloud environments, architectures can be completely different, and individual applications might pick integration architectures that are more fruitful for them, without considering the larger environment. If the DevOps teams that manage the solution architecture are mature, then they too will consider the various non-functionals that play a role with such integrations. But if the experience is lacking, setting up direct extensions towards the SaaS might seem to be a quick and valid solution.

Some areas that I would focus on when such integrations are requested, are (in no particular order):

• Impact of the integration to the deployment architecture of the solution, considering the availability zones and region concepts used within the solution
• Authentication of the integration at various levels (not just authentication based on the identity being used)
• Isolation of the integration, ensuring that no other parties are impacted by the integration
• Filtering capabilities on network and application level
• Logging and metrics to get visibility on the integration, its usage, the volumes sent over, etc.
• Resilience in case of temporary failures (be it through buffering mechanisms, or asynchronous integrations)
• Registration of the integration in the enterprise architecture, so that assessments, vendor relationship, and other processes are aware of the integration

When properly tackled, then services like AWS PrivateLink of course do have a role to play. But it isn’t to just link one solution with another and be done with it.

Granting SaaS providers limited access to your resources

Another approach that I see happening is to grant a SaaS provider administrative access to your own resources. Just like with extending SaaS environments, I feel that this is not something to apply by default and has to be carefully assessed. For some SaaS solutions, this is part of their selling proposal, and is something you know up front. But not all SaaS solutions are equally obvious in this requirement.

Some organizations might not have their cloud architecture, account structure and the like designed to enable SaaS providers to get administrative access to (some) resources. If the current architectures focus on highly integrated accounts and solutions, then granting a SaaS administrative access might jeopardize the security and stability of your overall architecture.

Furthermore, granting a third party access to your resources also has implications on accountability. If a SaaS has access to storage within your account, it could accidentally manipulate data it shouldn’t have access to, upload another customer’s data on your storage (or vice-versa), or due to a cyber incident upload toxic data to your account. The provider might also inadvertently access the data in an economically unfriendly way.

Using such access patterns should be carefully designed. While you can often not implement specific IT or security measures on the solution design, it might be possible to use separate accounts for instance, focusing on the integration between your ‘core’ solutions and this intermediate one to ensure a secure and resilient setup, while optimizing cost management for this intermediate account. You can even consider putting such accounts under a different tree in the organization structure and apply restrictive policies such as through AWS’ Service Control Policies (SCP).

Conclusions

Creating solutions that link with third parties requires thought and design. Cloud providers make it a lot easier to change and apply connections and integrations, but that does not make the architectural work that precedes it less obvious - on the contrary.

Customizations with SaaS providers still need to be carefully assessed and integrated, with attention on the non-functionals such as resilience, availability, security and the like.

If the SaaS provider needs access to your own resources, carefully assess how fine-grained this can be implemented and how the accountability is assigned. See if an intermediate account can be used where both you and the SaaS provider have administrative access to, while keeping the rest of the organization’s data and solutions elsewhere.