More Decisions: Capacity, Storage and Gateways

1. More Decisions: Capacity, Storage and Gateways

In your Fabric environment, you'll face multiple important decisions. Beyond choosing the right SKU, selecting appropriate Fabric tools for your environment is crucial. This will be the scope of this video.

2. Decision 1: One or multiple Fabric capacities?

Usually, you maintain one capacity for simplicity. The more capacities, the more overhead and maintenance are needed. Thus, you should aim to keep things as simple as possible. However, in more complex organizations, you may need two or more separate capacities for billing, compliance, or security reasons. For example, if your company has different legal entities, they may ask for different capacities to keep their data segregated.

3. Decision 1: One or multiple Fabric capacities?

This won't significantly change your workflow, except that capacities won't communicate with each other. For example, you won't be able to create a report in Capacity A that reads a model in Capacity B. However, this separation may be necessary for your organization.

4. Decision 2: How to read your data?

Another critical decision involves how to read from external data storage. Usually, the data comes from external sources, and you need to connect to them from Fabric to read your data using Pipelines or Dataflow. It could come from anywhere: Cloud storage like Amazon S3 or Azure Data Lake, other cloud databases like Snowflake, Azure SQL, and Azure Cosmos, or the company's systems in the company's local infrastructure (called on-premises) Let's see which tool you can use to read data for each case.

5. For Cloud Storage: use Shortcuts

For cloud resources like S3 or Azure Data Lake, you'll use Fabric shortcuts: Direct links to your cloud storage folder, readily available in Fabric

6. For Cloud Databases: use Mirroring

For Cloud Databases, you can use Mirroring. This beta feature, limited to some Database types at the moment, creates a live copy of the database in Fabric and synchronizes changes from both sides.

7. For On-Premises Data: use Gateways

Finally, we have gateways. They are applications that, after being installed in the company's local infrastructure, act as secure tunnels between your on-premises data (typically a SQL database) and Fabric. Think of them like a secure bridge that allows data to travel safely.

8. Addendum on gateways: On-premise vs Vnet

Speaking about Data Gateways, the decision is a tad more complicated. There are some cases when you need to decide between two similar options: On-premises and V-net. On-premises gateways are the classic choice for any system outside of the Cloud. You install them in the on-premises server and open the tunnel to send the data to Fabric. If you work with resources in Azure, such as Azure SQL Instances or Azure Databricks, you can use V-net gateways. They are special connections that require an Azure Private network to safely connect to the source. Their point of strength? Simpler maintenance and compatibility. Thumb's rule for this choice is to check if your data source is in Azure or in the list of Azure-compatible services, then go to V-net gateways. Otherwise, stick with the classic On-premises Gateways.

9. Let's practice!

Now that you know how to tackle critical decisions for your Fabric environment, we can put this knowledge to practice.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.