XOAP and Spacelift are often compared, but they serve very different purposes. Spacelift focuses on safely creating and managing infrastructure using code, while XOAP primarily handles running and maintaining systems after they exist.

That said, XOAP can also provision new resources, for example, building a VM image and creating a VM from it, but it still requires some underlying infrastructure, such as a VMware ESX host or an existing AWS account, to be in place.

For example, XOAP can:

• Build VM or cloud provider services
• Apply some system-level configurations

Keep in mind that:

• XOAP manages the “system” inside the infrastructure (it makes sure the VM or server is set up, applications are installed, patches applied and it keeps it “healthy” over time)
• Spacelift manages the “infrastructure itself” (it controls how many servers exist, which networks, storage, clusters and cloud resources are created and enforces rules on all changes at the code level)

AWS is defining sovereignty standards with European authorities, particularly Germany’s BSI, to ensure the cloud meets European legal and compliance expectations.

This isn’t about marketing. It’s about building trust with governments and regulated industries.

Autopilot doesn’t install software, except in Autopilot Pre-Provisioning scenario, formerly known as ‘white glove’.  Usually that’s handled through Intune. But what if you need more?

With Application Management module, you get:

• A rich, reusable package library
• Centralized packaging support across multiple tenants
• A solution that works beyond Intune, including SCCM, hybrid setups, and disconnected environments

It’s a modern take on application delivery, with better flexibility and fewer limitations.

It’s tough to manage what you can’t see. In hybrid IT, teams often lack a complete view of what’s happening across all systems. This can lead to slower responses when something breaks or performs poorly.

However, this isn’t about a lack of skill – it’s about infrastructure complexity. It has a lot of moving parts, from on-prem servers and cloud platforms to APIs, containers, and third-party tools. These are often spread out across different environments, which makes it hard to see everything at once. Even strong IT teams can miss issues if they don’t have a clear, unified view.

In response, existing solutions have been around for a long time that still follow the core ideas of infrastructure as code, but with different priorities. Instead of being dependent on state files and extensive tooling, they are often enough to fulfill the needs of modern infrastructure deployments. We are discussing cloud-provider SDKs and command-line interfaces (CLIs).

These tools offer first-class feature access without the Terraform delay. And they give you finer control and custom logic through programmatic control and additional conditional logic, which is sometimes cumbersome or verbose in Terraform.

Often, the approach to implementing small-scale tasks leads to easier maintainability, faster execution, more predictable deployments, and less stress for the teams involved.

Last but not least, it reduces abstraction overhead; native tools do exactly what the API says, no translation or misalignment.

We could still say that with Terraform, you have one language that you have to learn to automate your entire infrastructure deployment on different platforms, but although you are using only one language, you still have to adjust all resource definitions to the cloud-specific parameters. So, why not use platform-specific tools directly from the start?

Not all systems are the same. A web server in production might need one setup, while a test server or a server in a different country might need something slightly different.

Custom modules make that easier. You can build logic into the module to decide how it should behave based on things like location, server role, or environment. That way, you don’t have to create completely different configurations for every scenario.

Step 1: Retrieve the latest Microsoft Endpoint Data > PowerShell Script (scripted action) – call Microsoft Endpoint API for IP ranges

Step 2: Update firewall configuration > inject latest IPs into configuration template – store in XOAP

Step 3: Deploy configuration > XOAP pushes configuration to target firewalls (local, cloud, hybrid)

Step 4: Execute scripted action > run PowerShell or CLI commands to apply settings – directly against Azure Firewall/NSGs/Third-party appliances

Step 5: Continuous compliance monitoring > XOAP detects drift – automatically reapply configuration if necessary