Simplicity is a form of art...

Hybrid cloud can be very complex

I am not an advocate for hybrid cloud architectures. Or at least, not the definition for hybrid cloud that assumes one (cloud or on premise) environment is just an extension of another (cloud or on premise) environment. While such architectures seem to be simple and fruitful - you can easily add some capacity in the other environment to handle burst load - they are a complex beast to tame.

Scale is a cloud threat

Not that long ago, a vulnerability was found in Microsoft Azure Cosmos DB, a NoSQL SaaS database within the Microsoft Azure cloud. The vulnerability, which is dubbed ChaosDB by the Wiz Research Team, uses a vulnerability or misconfiguration in the Jupyter Notebook feature within Cosmos DB. This vulnerability allowed an attacker to gain access to other's Cosmos DB credentials. Not long thereafter, a second vulnerability dubbed OMIGOD showed that cloud security is not as simple as some vendors like you to believe.

These vulnerabilities are a good example of how scale is a cloud threat. Companies that do not have enough experience with public cloud might not assume this in their threat models.

Disaster recovery in the public cloud

The public cloud is a different beast than an on-premise environment, and that also reflects itself on how we (should) look at the processes that are actively steering infrastructure designs and architecture. One of these is the business continuity, severe incident handling, and the hopefully-never-to-occur disaster recovery. When building up procedures for handling disasters (DRP = Disaster Recovery Procedure or Disaster Recover Planning), it is important to keep in mind what these are about.

Not sure if TOSCA will grow further

TOSCA is an OASIS open standard, and is an abbreviation for Topology and Orchestration Specification for Cloud Applications. It provides a domain-specific language to describe how an application should be deployed in the cloud (the topology), which and how many resources it needs, as well as tasks to run when certain events occur (the orchestration). When I initially came across this standard, I was (and still am) interested in how far this goes. The promise of declaring an application (and even bundling the necessary application artefacts) within a single asset and then using this asset to deploy on whatever cloud is very appealing to an architect. Especially in organizations that have a multi-cloud strategy.

Integrating or customizing SaaS within your own cloud environment

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.