There are more SaaS providers than ever. Every non-core (and sometimes, core) layer is outsourced to an API provider – authentication (Auth0), video (Mux), HR (Merge), integration (Tray), SSO (WorkOS), Finance (Modern Treasury), data warehouse (Snowflake), and even usage-based billing (Metronome).
Some of these may run cloud-prem, but many of them are fully hosted by the vendor. This is convenient for the customer (nothing to manage) and has been happening for decades. But the proliferation of SaaS and the dependence of third-party SaaS in many critical paths have created some uniquely new issues for stitching the SaaS together.
- No common security layer. The current standard is "whitelist our IP." But, of course, to access your infrastructure, someone need only create an account with a third party and find a way to access it through that. SSH tunnels are another archaic alternative. Per-customer IP whitelists are probably the form of this method, but far worse than the security offered by a cloud provider. In Building the VPC Layer for Cloud, I outline a possible solution.
- No infrastructure as code. While AWS services are often not as good as best-of-breed SaaS, they are standardized (as much as one can in a large company). Every AWS service works with Cloudformation, and many are supported out-of-the-box in the Cloud Development Kit. SaaS providers may have their own ways of creating and managing deployments, test environments, and everything else. API styles and clients necessarily differ.
I'm not sure how infrastructure-as-code could work for the Cambrian explosion of SaaS. For a long time, I believed the answer involved Kubernetes, but it's becoming more apparent that the cloud development kit layer lives at a slightly higher layer of abstraction. So maybe there will be standards that these companies can hook onto or adapt.