Azure

Building a Dev Environment with Terraform, Azure and VS Code

Learn Terraform with Azure by Building a Dev Environment – Full Course for Beginners

This project will guide you through Terraform basics as you utilize Visual Studio Code (on Windows, Mac, or Linux!) to deploy Azure resources and an Azure VM that you can SSH into to have your own redeployable environment that will be perfect for your own future projects!

⭐️ Course Contents ⭐️
⌨️ (0:00:00) Intro
⌨️ (0:01:51) VSCode Setup
⌨️ (0:05:24) Terraform Provider Init
⌨️ (0:11:26) A Resource Group
⌨️ (0:16:57) A Virtual Network and Referencing other Resources 
⌨️ (0:23:29) Terraform State
⌨️ (0:27:17) Terraform Destroy
⌨️ (0:30:29) A Subnet
⌨️ (0:35:36) A Security Group
⌨️ (0:41:51) Security Group Associations
⌨️ (0:44:00) A Public IP
⌨️ (0:47:40) A Network Interface
⌨️ (0:52:45) A Key Pair
⌨️ (0:57:57) Custom Data
⌨️ (1:02:24) SSH Config Scripts
⌨️ (1:05:56) The Provisioner
⌨️ (1:14:53) Data Sources
⌨️ (1:19:04) Outputs
⌨️ (1:23:09) Variables
⌨️ (1:26:41) Variable Precedence
⌨️ (1:31:09) Conditionals

#terraform #azure #visualstudiocode #vscode 

Azure Cosmos DB Is A Wonderful, Multiparadigm, Easy to Use

Azure Cosmos DB is a wonderful, multiparadigm, easy to use No SQL solution for storing all kinds of data. With a few clicks, one can have a Cosmos Cluster installed and running in no time. At the same time, there are some pitfalls that can impact Cosmos DB if careful consideration is not taken. In this video, we'll look at several of those pitfalls and how to avoid them.

#azure #cosmosdb 

Azure Cosmos DB Has Versatile Hidden Feature: The Change Feed

Azure Cosmos DB has versatile hidden feature: the change feed. The Change Feed allows apps to subscribe to Cosmos DB for inserts and updates on data. When this happens, the changes are published to the change feed as an event, and code can respond to the changes rather than polling the database or having to create complex dataflows. In this video, we'll set one up and show you how easy it is to use.

#azure #cosmosdb 

Azure SQL Database Frente A Azure Cosmos DB: ¿Cuál Debería Elegir?

¿Comenzó recientemente a desarrollar o migrar una aplicación a Microsoft Azure? Si es así, una de las cosas que probablemente tenga que decidir es la solución de base de datos que desea utilizar. La nube de Microsoft ofrece múltiples opciones, siendo las dos más populares Azure SQL Database (y sus dos hermanos, Azure SQL Managed Instances y SQL Server en Azure VM) y Azure Cosmos DB.

Recientemente, estuve comparando estas dos alternativas para mi aplicación. Obtuve algunas ideas que me encantaría compartir con mis lectores. Primero, veamos ambos productos por separado y veamos qué características ofrecen.

Base de datos Azure SQL

Azure SQL es la oferta de SQL Server de Microsoft en Azure. Hay tres servicios relacionados con Azure SQL para elegir:

• Base de datos Azure SQL
• Instancia administrada de Azure SQL
• SQL Server en máquinas virtuales de Azure

Azure SQL Database es el servicio más "administrado" de los tres. Es una oferta de PaaS que le permite configurar SQL Server de forma rápida y sin esfuerzo. La mayoría de las tareas de administración, incluidas las copias de seguridad, las actualizaciones y la supervisión, están a cargo de usted. Tampoco necesita administrar la infraestructura subyacente.

Hay varios niveles de servicio para elegir, incluida una opción de base de datos única con memoria y cómputo configurables, una opción de grupo elástico que le permite compartir recursos entre varias bases de datos, así como una opción sin servidor que puede escalar sus recursos dinámicamente según el uso.

SQL Server en máquinas virtuales de Azure simplemente le permite ejecutar una instancia de SQL Server en su propia máquina virtual de Azure aprovisionada. Esto significa que obtiene un control casi total sobre todos los aspectos de la implementación. Esto también significa que deberá ocuparse de la mayoría de las tareas de administración a las que está acostumbrado a realizar en su solución local.

Azure SQL Managed Instance es una especie de híbrido entre estos dos. Por un lado, le permite transferir sin problemas su base de datos local de SQL Server a la nube. Por otro lado, le brinda muchas ventajas de la nube, incluida la seguridad mejorada, parches automáticos, actualizaciones de versiones y copias de seguridad automáticas.

Since Azure SQL is mostly compatible with SQL Server, it also offers the same transactional guarantees (ACID) as the on-premises product. Due to these strong guarantees, scaling out by adding multiple server instances is mostly limited to read-only replicas. This is also true for the geo-replication feature of Azure SQL.

Pricing for Azure SQL Database is based on the computing and memory you require (vCores) as well as the local storage and backup storage you configure. Overall, the pricing seems easy to understand.

Azure Cosmos DB

Cosmos DB is the NoSQL offering on Azure. It is designed from the ground up to support extreme scalability, fully embracing the concept of eventual consistency. The main target applications are IoT and global-facing cloud applications. To this end, Cosmos DB offers different consistency levels, data access methods (APIs) as well as scaling options.

Since Cosmos DB is a NoSQL database, it generally conforms well with how data is used by your application. For instance, an “item” can be inserted into the database as a JSON document and the output of a query is a JSON document as well. Databases and containers are used as namespaces over the items with certain additional functions.

To support extreme horizontal scaling, Cosmos DB uses multiple mechanisms. First, Cosmos DB partitions each container according to a partition key. These partitions are automatically spread across physical nodes. Additionally, global distribution of data is achieved by deploying your data across multiple Azure regions. This decreases latency and increases responsiveness across the world. It also provides a failover during regional outages.

Understandably, global distribution comes at the expense of consistency. In contrast to SQL Server which provides strong ACID guarantees by default, Cosmos DB allows you to choose between multiple consistency levels, each providing its guarantees. The most extreme of these, eventual consistency, only guarantees that all replicas will converge at some point in the future.

The pricing model of Cosmos DB is based on request units (RU). 1RU is the cost of a 1KB point-read. Queries are correspondingly more expensive. Request units seem simple enough, but it’s hard to estimate the usage given your particular data access patterns without prior experience.

Pros and Cons

Having described both solutions, you may ask which one is most suitable for you? Let us discuss some strengths and weaknesses of both databases.

Azure SQL Database Pros

• Flexible deployment options. Whether you want a fully managed service or if you simply want to run SQL Server on Azure’s VMs, Azure SQL Database got you covered.
• Familiar with SQL developers. Since Azure SQL Database is essentially the Azure implementation of the well-known SQL Server, most skills directly transfer to the cloud offering.
• Customizability. If you run your own SQL Server instance, you have control over every setting.
• Transparent pricing. Pricing is based on the required memory, compute, and storage resources.
• Migration. Relatively easy migration of your on-premises SQL Server databases to Azure SQL due to the same underlying engine.
• Stability and reliability. Microsoft SQL Server was initially released back in 1989 and has come a long way since then. It is a mature, stable, and well-tested database engine.

Azure SQL Database Cons

• Fixed schema. Generally, SQL databases are less suited for frequently changing software requirements due to their fixed schema. Schema migration may be hard to manage. Although SQL Server can work with JSON data nowadays (thus bridging the gap between SQL and NoSQL), it requires special syntax and feels a bit like an afterthought.
• ACID guarantees and distributed transactions. While these features can be very useful for some applications, they also drastically reduce scalability in case you don’t need them.
• Limited scaling. While scaling up (by adding more memory or compute to your SQL Server instances) is a quick and easy way to ramp up performance, it may become prohibitively expensive beyond a certain point. Scaling out (by adding multiple instances of SQL Server) is mostly limited to read-only replicas.

Azure Cosmos DB Pros

• Global distribution. Many companies nowadays act worldwide. Their customers expect the same performance from applications regardless of where they are located. This makes the standard SQL database model very inefficient. Having one write-enabled master node with multiple read-only replicas is not sufficient for tasks such as social network feeds or IoT data streams.
• Multiple consistency levels. On the other hand, these applications usually do not need the consistency guarantees of the traditional databases. They can rely on weaker consistency models such as consistent prefix or even eventual consistency. Having the freedom to choose the consistency level is a major benefit of Cosmos DB.
• Auto-indexing support. Every container has an indexing policy set to speed up queries. By default every property is indexed and range indexes are enforced. This is sufficient for most use cases. However, advanced indexing settings are available.
• Support for multiple languages out-of-the-box. There are ready-made APIs available for .NET, Java, Python, Ruby, and JavaScript. No need for complex ORM layers.
• Multiple APIs. Cosmos DB provides its own Core API as well as multiple alternative database APIs (Gremlin API, Cassandra API, MongoDB API, Table API) that help with migration from other NoSQL databases. This lowers the migration cost and learning curve.

Azure Cosmos DB Cons

• Harder to understand for traditional DB admins. Since Cosmos DB is a NoSQL database and doesn’t necessarily provide strong ACID guarantees (depending on configuration), it is harder to understand for DB administrators used to dealing with traditional SQL databases.
• Complex migration from SQL Server. Migration from a SQL Server-based solution may prove to be very costly and in extreme cases may require rewriting major parts of the application. Subsequent optimization will then take up even more time. I would only advise doing this if the benefits of global scaling outweigh the efforts.
• Hard-to-understand pricing model. The pricing model is based on Request Units which may be unintuitive. The Cosmos DB Capacity Calculator in the portal may help with cost estimates provided you can estimate certain key metrics. In general, Cosmos DB may be quite expensive.
• Public cloud-only. The only place where Cosmos DB is deployed is in Microsoft’s datacenters. Currently, there is no offering for hybrid or on-premises cloud solutions such as Azure Arc.

Conclusion

Both products have a place in the Azure ecosystem. While Azure SQL Database provides easy migration from your on-premises SQL Server solution and helps you to leverage your existing SQL Server knowledge, Cosmos DB was designed from the ground up for global distribution and is fully managed.

If I had to decide which database to use for a new project, I would certainly go with Cosmos DB, as I simply love its scalability and flexibility. As a NoSQL service, interacting with the database simply feels more natural in your application code than working for complex ORM middleware required for traditional databases. Moreover, the choice of multiple consistency levels makes it very easy to choose the right balance between speed and consistency.

My main concern with Cosmos DB is its steep learning curve for administrators used to dealing with traditional SQL databases. Setting up your first Cosmos DB database feels overwhelming. You will have to read through lots of documentation or watch lots of tutorials to figure out how to set up the service to fulfill your specific requirements.

Sin embargo, creo que esto mejorará con el tiempo a medida que aumente la tasa de adopción. Cosmos DB ya ha recorrido un largo camino en poco tiempo y no veo la hora de ver hacia dónde nos dirigimos a continuación.

Fuente: https://betterprogramming.pub/azure-sql-database-vs-cosmos-db-which-should-you-choose-cda17b60d6d2

#cosmosdb #azure #sql 

Azure SQL Database Contre Azure Cosmos DB — Lequel Choisir ?

Avez-vous récemment commencé à développer ou à porter une application sur Microsoft Azure ? Si tel est le cas, vous devrez probablement décider de la solution de base de données que vous souhaitez utiliser. Le cloud Microsoft offre plusieurs options, les deux plus populaires étant Azure SQL Database (et ses deux frères, Azure SQL Managed Instances et SQL Server sur les machines virtuelles Azure) et Azure Cosmos DB.

Récemment, je comparais ces deux alternatives pour mon application. J'ai acquis des idées que j'aimerais partager avec mes lecteurs. Tout d'abord, examinons les deux produits séparément et voyons quelles fonctionnalités ils offrent.

Base de données SQL Azure

Azure SQL est l'offre SQL Server de Microsoft sur Azure. Vous avez le choix entre trois services liés à Azure SQL :

• Base de données SQL Azure
• Instance gérée Azure SQL
• SQL Server sur les machines virtuelles Azure

Azure SQL Database est le service le plus « géré » des trois. Il s'agit d'une offre PaaS vous permettant de configurer SQL Server rapidement et sans effort. La plupart des tâches d'administration, y compris les sauvegardes, les mises à jour et la surveillance, sont prises en charge pour vous. Vous n'avez pas non plus besoin de gérer l'infrastructure sous-jacente.

Vous avez le choix entre plusieurs niveaux de service, notamment une option de base de données unique avec mémoire et calcul configurables, une option de pool élastique qui vous permet de partager des ressources entre plusieurs bases de données, ainsi qu'une option sans serveur qui peut faire évoluer vos ressources de manière dynamique en fonction de l'utilisation.

SQL Server sur les machines virtuelles Azure vous permet simplement d'exécuter une instance SQL Server sur votre propre machine virtuelle Azure provisionnée. Cela signifie que vous obtenez un contrôle presque total sur tous les aspects du déploiement. Cela signifie également que vous devrez vous soucier de la plupart des tâches d'administration que vous avez l'habitude d'effectuer sur votre solution sur site.

Azure SQL Managed Instance est une sorte d'hybride entre les deux. D'une part, il vous permet de transférer en toute transparence votre base de données SQL Server sur site vers le cloud. D'autre part, il vous offre de nombreux avantages du cloud, notamment une sécurité améliorée, des correctifs automatiques, des mises à jour de version et des sauvegardes automatisées.

Étant donné qu'Azure SQL est principalement compatible avec SQL Server, il offre également les mêmes garanties transactionnelles (ACID) que le produit sur site. En raison de ces solides garanties, la mise à l'échelle en ajoutant plusieurs instances de serveur est principalement limitée aux répliques en lecture seule. Cela est également vrai pour la fonctionnalité de géoréplication d'Azure SQL.

La tarification d'Azure SQL Database est basée sur l'informatique et la mémoire dont vous avez besoin (vCores), ainsi que sur le stockage local et le stockage de sauvegarde que vous configurez. Dans l'ensemble, le prix semble facile à comprendre.

Azure Cosmos DB

Cosmos DB est l'offre NoSQL sur Azure. Il est conçu dès le départ pour prendre en charge une évolutivité extrême, en adoptant pleinement le concept de cohérence éventuelle. Les principales applications cibles sont l'IoT et les applications cloud mondiales. À cette fin, Cosmos DB propose différents niveaux de cohérence, des méthodes d'accès aux données (API) ainsi que des options de mise à l'échelle.

Étant donné que Cosmos DB est une base de données NoSQL, elle se conforme généralement bien à la manière dont les données sont utilisées par votre application. Par exemple, un "élément" peut être inséré dans la base de données en tant que document JSON et la sortie d'une requête est également un document JSON. Les bases de données et les conteneurs sont utilisés comme espaces de noms sur les éléments avec certaines fonctions supplémentaires.

Pour prendre en charge une mise à l'échelle horizontale extrême, Cosmos DB utilise plusieurs mécanismes. Tout d'abord, Cosmos DB partitionne chaque conteneur en fonction d'une clé de partition. Ces partitions sont automatiquement réparties sur les nœuds physiques. De plus, la distribution mondiale des données est obtenue en déployant vos données dans plusieurs régions Azure. Cela diminue la latence et augmente la réactivité à travers le monde. Il fournit également un basculement pendant les pannes régionales.

Naturellement, la distribution mondiale se fait au détriment de la cohérence. Contrairement à SQL Server qui fournit par défaut de fortes garanties ACID, Cosmos DB vous permet de choisir entre plusieurs niveaux de cohérence , chacun fournissant ses garanties. La plus extrême d'entre elles, la cohérence éventuelle, garantit uniquement que toutes les répliques convergeront à un moment donné dans le futur.

Le modèle de tarification de Cosmos DB est basé sur les unités de demande (RU). 1RU est le coût d'une lecture ponctuelle de 1 Ko. Les requêtes sont donc plus chères. Les unités de requête semblent assez simples, mais il est difficile d'estimer l'utilisation compte tenu de vos modèles d'accès aux données particuliers sans expérience préalable.

Avantages et inconvénients

Après avoir décrit les deux solutions, vous pouvez vous demander laquelle vous convient le mieux ? Discutons quelques forces et faiblesses des deux bases de données.

Avantages de la base de données Azure SQL

• Options de déploiement flexibles. Que vous souhaitiez un service entièrement géré ou que vous souhaitiez simplement exécuter SQL Server sur les machines virtuelles d'Azure, Azure SQL Database est là pour vous.
• Familier avec les développeurs SQL. Étant donné qu'Azure SQL Database est essentiellement l'implémentation Azure du célèbre serveur SQL, la plupart des compétences sont directement transférées vers l'offre cloud.
• Personnalisation. Si vous exécutez votre propre instance SQL Server, vous contrôlez chaque paramètre.
• Tarification transparente. La tarification est basée sur les ressources de mémoire, de calcul et de stockage requises.
• Migration. Migration relativement facile de vos bases de données SQL Server sur site vers Azure SQL grâce au même moteur sous-jacent.
• Stabilité et fiabilité. Microsoft SQL Server a été initialement publié en 1989 et a parcouru un long chemin depuis lors. C'est un moteur de base de données mature, stable et bien testé.

Inconvénients de la base de données Azure SQL

• Schéma fixe. Généralement, les bases de données SQL sont moins adaptées aux exigences logicielles qui changent fréquemment en raison de leur schéma fixe. La migration de schéma peut être difficile à gérer. Bien que SQL Server puisse fonctionner avec des données JSON de nos jours (comblant ainsi le fossé entre SQL et NoSQL), il nécessite une syntaxe spéciale et ressemble un peu à une réflexion après coup.
• Garanties ACID et transactions distribuées. Bien que ces fonctionnalités puissent être très utiles pour certaines applications, elles réduisent également considérablement l'évolutivité au cas où vous n'en auriez pas besoin.
• Mise à l'échelle limitée. Bien que la mise à l'échelle (en ajoutant plus de mémoire ou de calcul à vos instances SQL Server) soit un moyen rapide et facile d'augmenter les performances, elle peut devenir prohibitive au-delà d'un certain point. La mise à l'échelle (en ajoutant plusieurs instances de SQL Server) est principalement limitée aux répliques en lecture seule.

Azure Cosmos DB Avantages

• Répartition mondiale. De nombreuses entreprises agissent aujourd'hui dans le monde entier. Leurs clients attendent les mêmes performances des applications, quel que soit leur emplacement. Cela rend le modèle de base de données SQL standard très inefficace. Avoir un nœud maître activé en écriture avec plusieurs répliques en lecture seule n'est pas suffisant pour des tâches telles que les flux de réseaux sociaux ou les flux de données IoT.
• Plusieurs niveaux de cohérence. D'autre part, ces applications n'ont généralement pas besoin des garanties de cohérence des bases de données traditionnelles. Ils peuvent s'appuyer sur des modèles de cohérence plus faibles tels qu'un préfixe cohérent ou même une cohérence éventuelle. Avoir la liberté de choisir le niveau de cohérence est un avantage majeur de Cosmos DB.
• Prise en charge de l'indexation automatique. Chaque conteneur a une politique d'indexation définie pour accélérer les requêtes. Par défaut, chaque propriété est indexée et les index de plage sont appliqués. C'est suffisant pour la plupart des cas d'utilisation. Cependant, des paramètres d'indexation avancés sont disponibles.
• Prise en charge de plusieurs langues prêtes à l'emploi. Des API prêtes à l'emploi sont disponibles pour .NET, Java, Python, Ruby et JavaScript. Pas besoin de couches ORM complexes.
• API multiples. Cosmos DB fournit sa propre API Core ainsi que plusieurs API de base de données alternatives (API Gremlin, API Cassandra, API MongoDB, API Table) qui facilitent la migration à partir d'autres bases de données NoSQL. Cela réduit le coût de la migration et la courbe d'apprentissage.

Inconvénients d'Azure Cosmos DB

• Plus difficile à comprendre pour les administrateurs de base de données traditionnels. Étant donné que Cosmos DB est une base de données NoSQL et ne fournit pas nécessairement de solides garanties ACID (selon la configuration), il est plus difficile à comprendre pour les administrateurs de base de données habitués à traiter avec des bases de données SQL traditionnelles.
• Migration complexe depuis SQL Server. La migration à partir d'une solution basée sur SQL Server peut s'avérer très coûteuse et, dans des cas extrêmes, peut nécessiter la réécriture de parties importantes de l'application. L'optimisation ultérieure prendra alors encore plus de temps. Je ne conseillerais de le faire que si les avantages de la mise à l'échelle mondiale l'emportent sur les efforts.
• Modèle de tarification difficile à comprendre. Le modèle de tarification est basé sur les unités de demande, ce qui peut ne pas être intuitif. Le calculateur de capacité Cosmos DB du portail peut vous aider à estimer les coûts, à condition que vous puissiez estimer certaines métriques clés. En général, Cosmos DB peut être assez cher.
• Cloud public uniquement. Le seul endroit où Cosmos DB est déployé est dans les centres de données de Microsoft. Actuellement, il n'existe aucune offre pour les solutions cloud hybrides ou sur site telles qu'Azure Arc.

Conclusion

Les deux produits ont leur place dans l'écosystème Azure. Bien qu'Azure SQL Database facilite la migration depuis votre solution SQL Server sur site et vous aide à tirer parti de vos connaissances SQL Server existantes, Cosmos DB a été conçu dès le départ pour une distribution mondiale et est entièrement géré.

Si je devais décider quelle base de données utiliser pour un nouveau projet, j'opterais certainement pour Cosmos DB, car j'aime tout simplement son évolutivité et sa flexibilité. En tant que service NoSQL, l'interaction avec la base de données semble tout simplement plus naturelle dans votre code d'application que de travailler pour un middleware ORM complexe requis pour les bases de données traditionnelles. De plus, le choix de plusieurs niveaux de cohérence permet de choisir très facilement le bon équilibre entre vitesse et cohérence.

Ma principale préoccupation avec Cosmos DB est sa courbe d'apprentissage abrupte pour les administrateurs habitués à gérer les bases de données SQL traditionnelles. La configuration de votre première base de données Cosmos DB semble écrasante. Vous devrez lire de nombreux documents ou regarder de nombreux didacticiels pour comprendre comment configurer le service afin de répondre à vos besoins spécifiques.

Cependant, je pense que cela s'améliorera avec le temps à mesure que le taux d'adoption augmentera. Cosmos DB a déjà parcouru un long chemin en peu de temps, et j'ai hâte de voir où nous allons ensuite.

Source : https://betterprogramming.pub/azure-sql-database-vs-cosmos-db-which-should-you-choose-cda17b60d6d2

#cosmosdb #azure #sql 

AzureSQLデータベースとAzureCosmosDB —どちらを選択する必要がありますか？

最近、アプリケーションの開発またはMicrosoft Azureへの移植を開始しましたか？もしそうなら、おそらくあなたが決定しなければならないことの1つは、使用したいデータベースソリューションです。Microsoftクラウドには複数のオプションがあり、最も人気のある2つはAzure SQLデータベース（およびその2つの兄弟、AzureSQLマネージドインスタンスとAzureVM上のSQLServer）とAzureCosmosDBです。

最近、私は自分のアプリケーションでこれら2つの選択肢を比較していました。私は読者と共有したいいくつかの洞察を得ました。まず、両方の製品を別々に見て、それらが提供する機能を確認しましょう。

AzureSQLデータベース

Azure SQLは、Azureで提供されるMicrosoftのSQLServerです。AzureSQLに関連する3つのサービスから選択できます。

• AzureSQLデータベース
• AzureSQLマネージドインスタンス
• AzureVM上のSQLServer

Azure SQL Databaseは、3つのうちで最も「マネージド」なサービスです。これは、SQLServerをすばやく簡単にセットアップできるPaaSオファリングです。バックアップ、更新、監視など、ほとんどの管理タスクが自動的に処理されます。また、基盤となるインフラストラクチャを管理する必要もありません。

構成可能なメモリとコンピューティングを備えた単一のデータベースオプション、複数のデータベース間でリソースを共有できるエラスティックプールオプション、用途に応じてリソースを動的に拡張できるサーバーレスオプションなど、複数のサービス層から選択できます。

AzureVM上のSQLServerを使用すると、プロビジョニングされた独自のAzure仮想マシンでSQLServerインスタンスを実行できます。これは、展開のあらゆる側面をほぼ完全に制御できることを意味します。これは、オンプレミスソリューションで実行するのに慣れているほとんどの管理タスクに注意する必要があることも意味します。

Azure SQLマネージドインスタンスは、これら2つのハイブリッドの一種です。一方では、オンプレミスのSQLServerデータベースをクラウドにシームレスに転送できます。一方、セキュリティの向上、自動パッチ適用、バージョン更新、自動バックアップなど、クラウドの多くの利点があります。

AzureSQLはSQLServerとほとんど互換性があるため、オンプレミス製品と同じトランザクション保証（ACID）も提供します。これらの強力な保証により、複数のサーバーインスタンスを追加することによるスケールアウトは、ほとんどの場合、読み取り専用レプリカに限定されます。これは、AzureSQLのジオレプリケーション機能にも当てはまります。

Azure SQL Databaseの料金は、必要なコンピューティングとメモリ（vCores）、および構成するローカルストレージとバックアップストレージに基づいています。全体的に、価格設定は理解しやすいようです。

Azure Cosmos DB

Cosmos DBは、Azure上のNoSQLオファリングです。これは、結果整合性の概念を完全に取り入れて、極端なスケーラビリティをサポートするようにゼロから設計されています。主なターゲットアプリケーションは、IoTとグローバル向けのクラウドアプリケーションです。この目的のために、Cosmos DBは、さまざまな整合性レベル、データアクセスメソッド（API）、およびスケーリングオプションを提供します。

Cosmos DBはNoSQLデータベースであるため、通常、アプリケーションでのデータの使用方法によく準拠しています。たとえば、「アイテム」をJSONドキュメントとしてデータベースに挿入でき、クエリの出力もJSONドキュメントになります。データベースとコンテナは、特定の追加機能を備えたアイテムの名前空間として使用されます。

極端な水平スケーリングをサポートするために、CosmosDBは複数のメカニズムを使用します。まず、Cosmos DBは、パーティションキーに従って各コンテナーをパーティション化します。これらのパーティションは、物理ノード全体に自動的に分散されます。さらに、データのグローバルな分散は、複数のAzureリージョンにデータをデプロイすることで実現されます。これにより、レイテンシが減少し、世界中で応答性が向上します。また、地域の停止時にフェイルオーバーを提供します。

当然のことながら、グローバルな配布には一貫性が犠牲になります。デフォルトで強力なACID保証を提供するSQLServerとは対照的に、Cosmos DBでは、それぞれが保証を提供する複数の整合性レベルから選択できます。これらの最も極端な結果整合性は、すべてのレプリカが将来のある時点で収束することを保証するだけです。

Cosmos DBの価格設定モデルは、リクエストユニット（RU）に基づいています。1RUは、1KBのポイント読み取りのコストです。それに応じて、クエリはより高価になります。リクエストユニットは十分に単純に見えますが、事前の経験がなければ、特定のデータアクセスパターンを考慮して使用量を見積もることは困難です。

長所と短所

両方の解決策を説明したので、どちらが自分に最も適しているかを尋ねることができますか？両方のデータベースの長所と短所について説明しましょう。

AzureSQLデータベースの長所

• 柔軟な展開オプション。フルマネージドサービスが必要な場合でも、AzureのVMでSQL Serverを実行するだけの場合でも、AzureSQLDatabaseで対応できます。
• SQL開発者に精通している。Azure SQL Databaseは、基本的にはよく知られているSQL ServerのAzure実装であるため、ほとんどのスキルはクラウド製品に直接移行します。
• カスタマイズ性。独自のSQLServerインスタンスを実行する場合は、すべての設定を制御できます。
• 透明性のある価格設定。料金は、必要なメモリ、コンピューティング、およびストレージリソースに基づいています。
• 移行。基盤となるエンジンが同じであるため、オンプレミスのSQLServerデータベースをAzureSQLに比較的簡単に移行できます。
• 安定性と信頼性。Microsoft SQL Serverは、最初は1989年にリリースされ、それ以来長い道のりを歩んできました。これは、成熟した、安定した、十分にテストされたデータベースエンジンです。

AzureSQLデータベースの短所

• スキーマを修正しました。一般に、SQLデータベースは、スキーマが固定されているため、頻繁に変更されるソフトウェア要件にはあまり適していません。スキーマの移行は管理が難しい場合があります。SQL Serverは現在JSONデータを処理できますが（したがって、SQLとNoSQLの間のギャップを埋める）、特別な構文が必要であり、少し後付けのように感じます。
• ACIDは、分散トランザクションを保証します。これらの機能は一部のアプリケーションでは非常に便利ですが、不要な場合はスケーラビリティが大幅に低下します。
• 限られたスケーリング。スケールアップ（SQL Serverインスタンスにメモリまたはコンピューティングを追加することによる）はパフォーマンスを向上させるための迅速かつ簡単な方法ですが、特定のポイントを超えると非常に高額になる可能性があります。スケールアウト（SQL Serverの複数のインスタンスを追加することによる）は、ほとんどの場合、読み取り専用レプリカに制限されています。

AzureCosmosDBの長所

• グローバルな配布。今日、多くの企業が世界中で活動しています。顧客は、場所に関係なく、アプリケーションに同じパフォーマンスを期待しています。これにより、標準のSQLデータベースモデルは非常に非効率になります。ソーシャルネットワークフィードやIoTデータストリームなどのタスクには、複数の読み取り専用レプリカを持つ1つの書き込み対応マスターノードを持つだけでは不十分です。
• 複数の整合性レベル。一方、これらのアプリケーションは通常、従来のデータベースの整合性保証を必要としません。一貫性のあるプレフィックスや結果整合性など、より弱い一貫性モデルに依存する可能性があります。整合性レベルを自由に選択できることは、CosmosDBの主な利点です。
• 自動インデックスのサポート。すべてのコンテナには、クエリを高速化するために設定されたインデックスポリシーがあります。デフォルトでは、すべてのプロパティにインデックスが付けられ、範囲インデックスが適用されます。ほとんどのユースケースではこれで十分です。ただし、高度なインデックス設定を使用できます。
• すぐに使用できる複数の言語のサポート。.NET、Java、Python、Ruby、およびJavaScriptで使用できる既製のAPIがあります。複雑なORMレイヤーは必要ありません。
• 複数のAPI。Cosmos DBは、独自のコアAPIと、他のNoSQLデータベースからの移行を支援する複数の代替データベースAPI（Gremlin API、Cassandra API、MongoDB API、Table API）を提供します。これにより、移行コストと学習曲線が低下します。

AzureCosmosDBの短所

• 従来のDB管理者にとっては理解が困難です。Cosmos DBはNoSQLデータベースであり、必ずしも強力なACID保証を提供するわけではないため（構成によって異なります）、従来のSQLデータベースの処理に慣れているDB管理者にとっては理解が困難です。
• SQLServerからの複雑な移行。SQL Serverベースのソリューションからの移行は非常にコストがかかることが判明する場合があり、極端な場合には、アプリケーションの主要部分を書き直す必要がある場合があります。その後の最適化には、さらに時間がかかります。グローバルスケーリングのメリットが努力を上回っている場合にのみ、これを行うことをお勧めします。
• 理解しにくい価格設定モデル。価格設定モデルは、直感的でない可能性のあるリクエストユニットに基づいています。ポータルのCosmosDBCapacity Calculatorは、特定の主要なメトリックを見積もることができれば、コストの見積もりに役立つ場合があります。一般に、CosmosDBは非常に高価な場合があります。
• パブリッククラウドのみ。Cosmos DBが展開される唯一の場所は、Microsoftのデータセンターです。現在、AzureArcなどのハイブリッドまたはオンプレミスのクラウドソリューションは提供されていません。

結論

どちらの製品も、Azureエコシステムに組み込まれています。Azure SQL Databaseは、オンプレミスのSQL Serverソリューションからの移行を容易にし、既存のSQL Serverの知識を活用するのに役立ちますが、Cosmos DBは、グローバルな配布用にゼロから設計され、完全に管理されています。

新しいプロジェクトに使用するデータベースを決定する必要がある場合は、Cosmos DBを使用します。これは、そのスケーラビリティと柔軟性が大好きだからです。NoSQLサービスとして、データベースとの対話は、従来のデータベースに必要な複雑なORMミドルウェアで作業するよりも、アプリケーションコードでより自然に感じられます。さらに、複数の整合性レベルを選択すると、速度と整合性の間の適切なバランスを非常に簡単に選択できます。

Cosmos DBに関する私の主な関心事は、従来のSQLデータベースの処理に慣れている管理者にとっての急な学習曲線です。最初のCosmosDBデータベースをセットアップするのは大変なことです。特定の要件を満たすようにサービスを設定する方法を理解するには、多くのドキュメントを読むか、多くのチュートリアルを見る必要があります。

ただし、採用率が上がるにつれて、時間の経過とともに改善されると思います。Cosmos DBは短期間ですでに長い道のりを歩んでおり、次の方向性を見るのが待ちきれません。

ソース：https ：//betterprogramming.pub/azure-sql-database-vs-cosmos-db-which-should-you-choose-cda17b60d6d2

#cosmosdb #azure #sql 

Azure SQL 数据库与 Azure Cosmos DB——你应该选择哪一个？

您最近是否开始开发或将应用程序移植到 Microsoft Azure？如果是这样，您可能必须决定的一件事是您要使用的数据库解决方案。Microsoft 云提供了多种选择，其中最流行的两个是 Azure SQL 数据库（及其两个兄弟，Azure SQL 托管实例和 Azure VM 上的 SQL Server）和 Azure Cosmos DB。

最近，我正在为我的应用程序比较这两种替代方案。我获得了一些我愿意与读者分享的见解。首先，让我们分别看看这两种产品，看看它们提供了哪些功能。

Azure SQL 数据库

Azure SQL 是 Microsoft 在 Azure 上提供的 SQL Server 产品。有三种与 Azure SQL 相关的服务可供选择：

• Azure SQL 数据库
• Azure SQL 托管实例
• Azure VM 上的 SQL Server

Azure SQL 数据库是三者中最“托管”的服务。它是一种 PaaS 产品，使您能够快速轻松地设置 SQL Server。大多数管理任务，包括备份、更新和监控，都由您完成。您也不需要管理底层基础架构。

有多个服务层可供选择，包括具有可配置内存和计算的单个数据库选项、使您能够在多个数据库之间共享资源的弹性池选项以及可以根据使用情况动态扩展资源的无服务器选项。

Azure VM 上的 SQL Server 仅使您能够在自己预配的 Azure 虚拟机上运行 SQL Server 实例。这意味着您几乎可以完全控制部署的各个方面。这也意味着您将需要关心您习惯于在本地解决方案上执行的大多数管理任务。

Azure SQL 托管实例是这两者之间的一种混合。一方面，它使您能够将本地 SQL Server 数据库无缝传输到云中。另一方面，它为您提供了云的许多优势，包括改进的安全性、自动修补、版本更新和自动备份。

由于 Azure SQL 主要与 SQL Server 兼容，因此它还提供与本地产品相同的事务保证 (ACID)。由于这些强有力的保证，通过添加多个服务器实例进行横向扩展主要限于只读副本。Azure SQL 的异地复制功能也是如此。

Azure SQL 数据库的定价基于你需要的计算和内存 (vCore) 以及你配置的本地存储和备份存储。总体而言，定价似乎很容易理解。

Azure Cosmos 数据库

Cosmos DB 是 Azure 上的 NoSQL 产品。它从头开始设计以支持极高的可扩展性，完全接受最终一致性的概念。主要目标应用程序是物联网和面向全球的云应用程序。为此，Cosmos DB 提供了不同的一致性级别、数据访问方法 (API) 以及扩展选项。

由于 Cosmos DB 是一个 NoSQL 数据库，它通常很好地符合应用程序使用数据的方式。例如，可以将“项目”作为 JSON 文档插入数据库，查询的输出也是 JSON 文档。数据库和容器用作具有某些附加功能的项目的命名空间。

为了支持极端水平扩展，Cosmos DB 使用了多种机制。首先，Cosmos DB 根据分区键对每个容器进行分区。这些分区自动分布在物理节点上。此外，通过跨多个 Azure 区域部署数据来实现数据的全球分布。这减少了延迟并提高了全球范围内的响应能力。它还在区域中断期间提供故障转移。

可以理解的是，全球分布是以牺牲一致性为代价的。与默认提供强 ACID 保证的 SQL Server 相比，Cosmos DB 允许您在多个一致性级别之间进行选择，每个级别都提供其保证。其中最极端的最终一致性只能保证所有副本将在未来某个时间点收敛。

Cosmos DB 的定价模型基于请求单位 (RU)。1RU 是 1KB 点读取的成本。查询相应地更昂贵。请求单元看起来很简单，但是在没有经验的情况下很难估计使用情况给定您的特定数据访问模式。

优点和缺点

描述了这两种解决方案后，您可能会问哪一种最适合您？让我们讨论一下这两个数据库的一些优点和缺点。

Azure SQL 数据库专家

• 灵活的部署选项。无论您想要完全托管的服务，还是只想在 Azure 的 VM 上运行 SQL Server，Azure SQL 数据库都能满足您的需求。
• 熟悉SQL开发人员。由于 Azure SQL 数据库本质上是众所周知的 SQL Server 的 Azure 实现，因此大多数技能直接转移到云产品中。
• 可定制性。如果您运行自己的 SQL Server 实例，则可以控制所有设置。
• 透明的定价。定价基于所需的内存、计算和存储资源。
• 移民。由于相同的底层引擎，将本地 SQL Server 数据库迁移到 Azure SQL 相对容易。
• 稳定性和可靠性。Microsoft SQL Server 最初于 1989 年发布，从那时起已经走过了漫长的道路。它是一个成熟、稳定且经过良好测试的数据库引擎。

Azure SQL 数据库缺点

• 固定架构。通常，SQL 数据库由于其固定模式不太适合频繁更改的软件需求。架构迁移可能难以管理。尽管 SQL Server 现在可以处理JSON 数据（从而缩小了 SQL 和 NoSQL 之间的差距），但它需要特殊的语法并且感觉有点像是事后才想到的。
• ACID 保证和分布式事务。虽然这些功能对某些应用程序非常有用，但如果您不需要它们，它们也会大大降低可伸缩性。
• 有限的缩放。虽然扩展（通过向 SQL Server 实例添加更多内存或计算）是提高性能的一种快速简便的方法，但超过某个点可能会变得非常昂贵。横向扩展（通过添加多个 SQL Server 实例）主要限于只读副本。

Azure Cosmos DB 专业人士

• 全球分布。如今，许多公司在全球范围内开展业务。他们的客户无论身在何处，都希望应用程序具有相同的性能。这使得标准的 SQL 数据库模型非常低效。拥有一个具有多个只读副本的可写主节点对于诸如社交网络馈送或物联网数据流之类的任务来说是不够的。
• 多个一致性级别。另一方面，这些应用程序通常不需要传统数据库的一致性保证。他们可以依赖较弱的一致性模型，例如一致的前缀甚至最终一致性。可以自由选择一致性级别是 Cosmos DB 的主要优势。
• 自动索引支持。每个容器都设置了索引策略以加快查询速度。默认情况下，每个属性都被索引并强制执行范围索引。这对于大多数用例来说已经足够了。但是，可以使用高级索引设置。
• 开箱即用支持多种语言。有现成的 API 可用于 .NET、Java、Python、Ruby 和 JavaScript。不需要复杂的 ORM 层。
• 多个 API。Cosmos DB 提供了自己的核心 API 以及多个替代数据库 API（Gremlin API、Cassandra API、MongoDB API、表 API），以帮助从其他 NoSQL 数据库迁移。这降低了迁移成本和学习曲线。

Azure Cosmos DB 缺点

• 对于传统的数据库管理员来说更难理解。由于 Cosmos DB 是一个 NoSQL 数据库，并且不一定提供强 ACID 保证（取决于配置），因此对于习惯于处理传统 SQL 数据库的数据库管理员来说，这很难理解。
• 从 SQL Server 进行复杂的迁移。从基于 SQL Server 的解决方案迁移可能证明成本非常高，在极端情况下可能需要重写应用程序的主要部分。随后的优化将占用更多时间。如果全球扩展的好处超过了努力，我只会建议这样做。
• 难以理解的定价模型。定价模型基于可能不直观的请求单位。如果您可以估计某些关键指标，则门户中的Cosmos DB 容量计算器可能有助于成本估计。一般来说，Cosmos DB 可能非常昂贵。
• 仅限公共云。部署 Cosmos DB 的唯一地方是 Microsoft 的数据中心。目前，没有提供混合或本地云解决方案，例如 Azure Arc。

结论

这两种产品都在 Azure 生态系统中占有一席之地。虽然 Azure SQL 数据库提供从本地 SQL Server 解决方案的轻松迁移并帮助您利用现有的 SQL Server 知识，但 Cosmos DB 是为全球分发而设计的，并且是完全托管的。

如果我必须决定将哪个数据库用于新项目，我肯定会选择 Cosmos DB，因为我只是喜欢它的可扩展性和灵活性。作为一项 NoSQL 服务，与数据库交互在您的应用程序代码中感觉比使用传统数据库所需的复杂 ORM 中间件更自然。此外，多个一致性级别的选择使得在速度和一致性之间选择适当的平衡变得非常容易。

我对 Cosmos DB 的主要担忧是，对于习惯于处理传统 SQL 数据库的管理员来说，它的学习曲线陡峭。设置您的第一个 Cosmos DB 数据库让人感觉不知所措。您将不得不阅读大量文档或观看大量教程，以了解如何设置服务以满足您的特定要求。

但是，我认为随着采用率的提高，这种情况会随着时间的推移而改善。Cosmos DB 已经在很短的时间内取得了长足的进步，我迫不及待地想看看我们接下来的发展方向。

来源：https ://betterprogramming.pub/azure-sql-database-vs-cosmos-db-which-should-you-choose-cda17b60d6d2

#cosmosdb #azure #sql 

Banco De Dados SQL Do Azure Vs. Azure Cosmos DB

Você começou recentemente a desenvolver ou portar um aplicativo para o Microsoft Azure? Nesse caso, uma das coisas que você provavelmente terá que decidir é a solução de banco de dados que deseja usar. A nuvem da Microsoft oferece várias opções, sendo as duas mais populares o Azure SQL Database (e seus dois irmãos, Azure SQL Managed Instances e SQL Server em VMs do Azure) e Azure Cosmos DB.

Recentemente, eu estava comparando essas duas alternativas para minha aplicação. Ganhei alguns insights que adoraria compartilhar com meus leitores. Primeiro, vamos analisar os dois produtos separadamente e ver quais recursos eles oferecem.

Banco de Dados SQL do Azure

Azure SQL é a oferta de SQL Server da Microsoft no Azure. Há três serviços relacionados ao Azure SQL para escolher:

• Banco de Dados SQL do Azure
• Instância Gerenciada de SQL do Azure
• SQL Server em VMs do Azure

O Banco de Dados SQL do Azure é o serviço mais “gerenciado” dos três. É uma oferta de PaaS que permite configurar o SQL Server de forma rápida e sem esforço. A maioria das tarefas de administração, incluindo backups, atualizações e monitoramento, são feitas para você. Você também não precisa gerenciar a infraestrutura subjacente.

Há várias camadas de serviço para escolher, incluindo uma única opção de banco de dados com memória e computação configuráveis, uma opção de pool elástico que permite compartilhar recursos entre vários bancos de dados, bem como uma opção sem servidor que pode dimensionar seus recursos dinamicamente dependendo do uso.

O SQL Server em VMs do Azure simplesmente permite que você execute uma instância do SQL Server em sua própria máquina virtual do Azure provisionada. Isso significa que você obtém controle quase total sobre todos os aspectos da implantação. Isso também significa que você precisará se preocupar com a maioria das tarefas de administração que está acostumado a executar em sua solução local.

A Instância Gerenciada de SQL do Azure é uma espécie de híbrido entre esses dois. Por um lado, ele permite que você transfira perfeitamente seu banco de dados local do SQL Server para a nuvem. Por outro lado, oferece muitas vantagens da nuvem, incluindo segurança aprimorada, correção automática, atualizações de versão e backups automatizados.

Como o Azure SQL é compatível principalmente com o SQL Server, ele também oferece as mesmas garantias transacionais (ACID) que o produto local. Devido a essas fortes garantias, o dimensionamento horizontal adicionando várias instâncias de servidor é limitado principalmente a réplicas somente leitura. Isso também vale para o recurso de replicação geográfica do Azure SQL.

O preço do Banco de Dados SQL do Azure é baseado na computação e na memória de que você precisa (vCores), bem como no armazenamento local e no armazenamento de backup que você configura. No geral, o preço parece fácil de entender.

Azure Cosmos DB

Cosmos DB é a oferta NoSQL no Azure. Ele foi projetado desde o início para suportar escalabilidade extrema, adotando totalmente o conceito de consistência eventual. Os principais aplicativos de destino são IoT e aplicativos de nuvem voltados para o mundo. Para isso, o Cosmos DB oferece diferentes níveis de consistência, métodos de acesso a dados (APIs) e opções de dimensionamento.

Como o Cosmos DB é um banco de dados NoSQL, geralmente está em conformidade com a forma como os dados são usados ​​pelo seu aplicativo. Por exemplo, um “item” pode ser inserido no banco de dados como um documento JSON e a saída de uma consulta também é um documento JSON. Bancos de dados e contêineres são usados ​​como namespaces sobre os itens com determinadas funções adicionais.

Para dar suporte ao dimensionamento horizontal extremo, o Cosmos DB usa vários mecanismos. Primeiro, o Cosmos DB particiona cada contêiner de acordo com uma chave de partição. Essas partições são distribuídas automaticamente entre nós físicos. Além disso, a distribuição global de dados é alcançada implantando seus dados em várias regiões do Azure. Isso diminui a latência e aumenta a capacidade de resposta em todo o mundo. Ele também fornece um failover durante interrupções regionais.

Compreensivelmente, a distribuição global vem à custa da consistência. Ao contrário do SQL Server, que fornece garantias ACID fortes por padrão, o Cosmos DB permite que você escolha entre vários níveis de consistência , cada um fornecendo suas garantias. A mais extrema delas, a consistência eventual, apenas garante que todas as réplicas convergirão em algum momento no futuro.

O modelo de preços do Cosmos DB é baseado em unidades de solicitação (RU). 1RU é o custo de uma leitura de ponto de 1 KB. As consultas são correspondentemente mais caras. As unidades de solicitação parecem bastante simples, mas é difícil estimar o uso considerando seus padrões específicos de acesso a dados sem experiência prévia.

Prós e contras

Tendo descrito ambas as soluções, você pode perguntar qual é a mais adequada para você? Vamos discutir alguns pontos fortes e fracos de ambos os bancos de dados.

Profissionais do Banco de Dados SQL do Azure

• Opções de implantação flexíveis. Se você deseja um serviço totalmente gerenciado ou simplesmente deseja executar o SQL Server nas VMs do Azure, o Banco de Dados SQL do Azure oferece cobertura.
• Familiarizado com desenvolvedores SQL. Como o Banco de Dados SQL do Azure é essencialmente a implementação do Azure do conhecido SQL Server, a maioria das habilidades é transferida diretamente para a oferta de nuvem.
• Personalização. Se você executar sua própria instância do SQL Server, terá controle sobre todas as configurações.
• Preços transparentes. O preço é baseado nos recursos necessários de memória, computação e armazenamento.
• Migração. Migração relativamente fácil de seus bancos de dados locais do SQL Server para o Azure SQL devido ao mesmo mecanismo subjacente.
• Estabilidade e confiabilidade. O Microsoft SQL Server foi lançado inicialmente em 1989 e percorreu um longo caminho desde então. É um mecanismo de banco de dados maduro, estável e bem testado.

Contras do Banco de Dados SQL do Azure

• Esquema fixo. Geralmente, os bancos de dados SQL são menos adequados para requisitos de software que mudam com frequência devido ao seu esquema fixo. A migração de esquema pode ser difícil de gerenciar. Embora o SQL Server possa trabalhar com dados JSON hoje em dia (fazendo a ponte entre SQL e NoSQL), ele requer uma sintaxe especial e parece um pouco uma reflexão tardia.
• Garantias ACID e transações distribuídas. Embora esses recursos possam ser muito úteis para alguns aplicativos, eles também reduzem drasticamente a escalabilidade caso você não precise deles.
• Escala limitada. Embora o aumento de escala (adicionando mais memória ou computação às instâncias do SQL Server) seja uma maneira rápida e fácil de aumentar o desempenho, pode se tornar proibitivamente caro além de um determinado ponto. O dimensionamento horizontal (adicionando várias instâncias do SQL Server) é limitado principalmente a réplicas somente leitura.

Profissionais do Azure Cosmos DB

• Distribuição global. Muitas empresas hoje atuam em todo o mundo. Seus clientes esperam o mesmo desempenho dos aplicativos, independentemente de onde estejam localizados. Isso torna o modelo de banco de dados SQL padrão muito ineficiente. Ter um nó mestre habilitado para gravação com várias réplicas somente leitura não é suficiente para tarefas como feeds de redes sociais ou fluxos de dados IoT.
• Vários níveis de consistência. Por outro lado, essas aplicações geralmente não precisam das garantias de consistência dos bancos de dados tradicionais. Eles podem contar com modelos de consistência mais fracos, como prefixo consistente ou até consistência eventual. Ter a liberdade de escolher o nível de consistência é um grande benefício do Cosmos DB.
• Suporte de indexação automática. Cada contêiner tem uma política de indexação definida para acelerar as consultas. Por padrão, todas as propriedades são indexadas e os índices de intervalo são aplicados. Isso é suficiente para a maioria dos casos de uso. No entanto, as configurações de indexação avançadas estão disponíveis.
• Suporte para vários idiomas pronto para uso. Existem APIs prontas disponíveis para .NET, Java, Python, Ruby e JavaScript. Não há necessidade de camadas ORM complexas.
• Várias APIs. O Cosmos DB fornece sua própria API Core, bem como várias APIs de banco de dados alternativas (API Gremlin, API Cassandra, API MongoDB, API de tabela) que ajudam na migração de outros bancos de dados NoSQL. Isso reduz o custo de migração e a curva de aprendizado.

Contras do Azure Cosmos DB

• Mais difícil de entender para administradores de banco de dados tradicionais. Como o Cosmos DB é um banco de dados NoSQL e não fornece necessariamente fortes garantias ACID (dependendo da configuração), é mais difícil de entender para administradores de banco de dados acostumados a lidar com bancos de dados SQL tradicionais.
• Migração complexa do SQL Server. A migração de uma solução baseada em SQL Server pode ser muito cara e, em casos extremos, pode exigir a reescrita de grandes partes do aplicativo. A otimização subsequente levará ainda mais tempo. Eu só aconselharia fazer isso se os benefícios da escala global superarem os esforços.
• Modelo de precificação difícil de entender. O modelo de preços é baseado em Unidades de Solicitação que podem não ser intuitivas. A Calculadora de Capacidade do Cosmos DB no portal pode ajudar com estimativas de custo, desde que você possa estimar determinadas métricas-chave. Em geral, o Cosmos DB pode ser bastante caro.
• Somente nuvem pública. O único local onde o Cosmos DB é implantado é nos datacenters da Microsoft. Atualmente, não há oferta para soluções de nuvem híbridas ou locais, como o Azure Arc.

Conclusão

Ambos os produtos têm um lugar no ecossistema do Azure. Embora o Banco de Dados SQL do Azure forneça uma migração fácil de sua solução SQL Server local e ajude você a aproveitar seu conhecimento existente do SQL Server, o Cosmos DB foi projetado desde o início para distribuição global e é totalmente gerenciado.

Se eu tivesse que decidir qual banco de dados usar para um novo projeto, certamente escolheria o Cosmos DB, pois simplesmente adoro sua escalabilidade e flexibilidade. Como um serviço NoSQL, interagir com o banco de dados simplesmente parece mais natural em seu código de aplicativo do que trabalhar para middleware ORM complexo necessário para bancos de dados tradicionais. Além disso, a escolha de vários níveis de consistência torna muito fácil escolher o equilíbrio certo entre velocidade e consistência.

Minha principal preocupação com o Cosmos DB é sua curva de aprendizado íngreme para administradores acostumados a lidar com bancos de dados SQL tradicionais. A configuração do seu primeiro banco de dados Cosmos DB parece esmagadora. Você terá que ler muita documentação ou assistir a muitos tutoriais para descobrir como configurar o serviço para atender aos seus requisitos específicos.

No entanto, acho que isso melhorará com o tempo à medida que a taxa de adoção aumentar. O Cosmos DB já percorreu um longo caminho em pouco tempo e mal posso esperar para ver para onde iremos a seguir.

Fonte: https://betterprogramming.pub/azure-sql-database-vs-cosmos-db-which-should-you-choose-cda17b60d6d2

#cosmosdb #azure #sql 

Cơ Sở Dữ Liệu Azure SQL So Với Cơ Sở Dữ Liệu Azure Cosmos

Gần đây bạn có bắt đầu phát triển hoặc chuyển một ứng dụng sang Microsoft Azure không? Nếu vậy, một trong những điều bạn có thể phải quyết định là giải pháp cơ sở dữ liệu bạn muốn sử dụng. Đám mây Microsoft cung cấp nhiều tùy chọn, với hai tùy chọn phổ biến nhất là Cơ sở dữ liệu Azure SQL (và hai anh em của nó, Azure SQL Managed Instances và SQL Server trên Azure VMs) và Azure Cosmos DB.

Gần đây, tôi đã so sánh hai lựa chọn thay thế này cho ứng dụng của mình. Tôi đã có được một số hiểu biết mà tôi muốn chia sẻ với độc giả của mình. Trước tiên, chúng ta hãy xem xét cả hai sản phẩm một cách riêng biệt và xem chúng cung cấp những tính năng nào.

Cơ sở dữ liệu Azure SQL

Azure SQL là SQL Server của Microsoft cung cấp trên Azure. Có ba dịch vụ liên quan đến Azure SQL để bạn lựa chọn:

• Cơ sở dữ liệu Azure SQL
• Phiên bản Azure SQL Managed
• Máy chủ SQL trên máy ảo Azure

Cơ sở dữ liệu Azure SQL là dịch vụ “được quản lý” nhiều nhất trong số ba dịch vụ. Nó là một PaaS cung cấp cho phép bạn thiết lập SQL Server nhanh chóng và dễ dàng. Hầu hết các tác vụ quản trị, bao gồm sao lưu, cập nhật và giám sát được thực hiện cho bạn. Bạn cũng không cần phải quản lý cơ sở hạ tầng bên dưới.

Có nhiều cấp dịch vụ để lựa chọn, bao gồm một tùy chọn cơ sở dữ liệu duy nhất với bộ nhớ có thể định cấu hình và máy tính, tùy chọn nhóm đàn hồi cho phép bạn chia sẻ tài nguyên giữa nhiều cơ sở dữ liệu cũng như tùy chọn không máy chủ có thể mở rộng tài nguyên của bạn một cách linh hoạt tùy thuộc vào việc sử dụng.

SQL Server trên Azure VMs chỉ cho phép bạn chạy phiên bản SQL Server trên máy ảo Azure được cung cấp của riêng bạn. Điều này có nghĩa là bạn có toàn quyền kiểm soát mọi khía cạnh của việc triển khai. Điều này cũng có nghĩa là bạn sẽ cần quan tâm đến hầu hết các tác vụ quản trị mà bạn đã quen thực hiện trên giải pháp tại chỗ của mình.

Azure SQL Managed Instance là một loại kết hợp giữa hai loại này. Một mặt, nó cho phép bạn chuyển cơ sở dữ liệu SQL Server tại chỗ của mình lên đám mây một cách liền mạch. Mặt khác, nó mang lại cho bạn nhiều lợi thế của đám mây, bao gồm cải thiện bảo mật, tự động vá lỗi, cập nhật phiên bản và sao lưu tự động.

Vì Azure SQL hầu hết tương thích với SQL Server, nó cũng cung cấp các đảm bảo giao dịch (ACID) giống như sản phẩm tại chỗ. Do những đảm bảo mạnh mẽ này, việc mở rộng quy mô bằng cách thêm nhiều phiên bản máy chủ hầu như chỉ giới hạn ở các bản sao chỉ đọc. Điều này cũng đúng với tính năng sao chép địa lý của Azure SQL.

Định giá cho Cơ sở dữ liệu Azure SQL dựa trên máy tính và bộ nhớ bạn yêu cầu (vCores) cũng như bộ nhớ cục bộ và bộ nhớ sao lưu mà bạn định cấu hình. Nhìn chung, giá cả có vẻ dễ hiểu.

Cơ sở dữ liệu Azure Cosmos

Cosmos DB là cung cấp NoSQL trên Azure. Nó được thiết kế từ đầu để hỗ trợ khả năng mở rộng cực cao, hoàn toàn bao hàm khái niệm về tính nhất quán cuối cùng. Các ứng dụng mục tiêu chính là IoT và các ứng dụng đám mây toàn cầu. Để đạt được điều này, Cosmos DB cung cấp các mức nhất quán khác nhau, các phương pháp truy cập dữ liệu (API) cũng như các tùy chọn mở rộng quy mô.

Vì Cosmos DB là một cơ sở dữ liệu NoSQL, nó thường tuân thủ tốt với cách dữ liệu được ứng dụng của bạn sử dụng. Ví dụ: một “item” có thể được chèn vào cơ sở dữ liệu dưới dạng tài liệu JSON và đầu ra của truy vấn cũng là tài liệu JSON. Cơ sở dữ liệu và vùng chứa được sử dụng làm không gian tên trên các mục có chức năng bổ sung nhất định.

Để hỗ trợ mở rộng quy mô theo chiều ngang, Cosmos DB sử dụng nhiều cơ chế. Đầu tiên, Cosmos DB phân vùng từng vùng chứa theo một khóa phân vùng. Các phân vùng này được tự động trải rộng trên các nút vật lý. Ngoài ra, phân phối dữ liệu toàn cầu đạt được bằng cách triển khai dữ liệu của bạn trên nhiều khu vực Azure. Điều này làm giảm độ trễ và tăng khả năng phản hồi trên toàn thế giới. Nó cũng cung cấp một chuyển đổi dự phòng trong thời gian mất điện khu vực.

Có thể hiểu, phân phối toàn cầu đi kèm với chi phí nhất quán. Trái ngược với SQL Server cung cấp bảo đảm ACID mạnh mẽ theo mặc định, Cosmos DB cho phép bạn chọn giữa nhiều mức nhất quán , mỗi mức cung cấp sự đảm bảo của nó. Điểm cực đoan nhất trong số này, tính nhất quán cuối cùng, chỉ đảm bảo rằng tất cả các bản sao sẽ hội tụ vào một thời điểm nào đó trong tương lai.

Mô hình định giá của Cosmos DB dựa trên đơn vị yêu cầu (RU). 1RU là chi phí của một lần đọc điểm 1KB. Các truy vấn tương ứng đắt hơn. Các đơn vị yêu cầu có vẻ đủ đơn giản, nhưng thật khó để ước tính mức sử dụng dựa trên các mẫu truy cập dữ liệu cụ thể của bạn nếu không có kinh nghiệm trước đó.

Ưu và nhược điểm

Sau khi mô tả cả hai giải pháp, bạn có thể hỏi giải pháp nào phù hợp nhất với bạn? Hãy để chúng tôi thảo luận về một số điểm mạnh và điểm yếu của cả hai cơ sở dữ liệu.

Ưu điểm Cơ sở dữ liệu Azure SQL

• Các tùy chọn triển khai linh hoạt. Cho dù bạn muốn một dịch vụ được quản lý hoàn toàn hay chỉ đơn giản là bạn muốn chạy SQL Server trên các máy ảo của Azure, Cơ sở dữ liệu Azure SQL sẽ giúp bạn.
• Quen thuộc với các nhà phát triển SQL. Vì Cơ sở dữ liệu Azure SQL về cơ bản là triển khai Azure của SQL Server nổi tiếng, hầu hết các kỹ năng đều chuyển trực tiếp sang dịch vụ đám mây.
• Khả năng tùy biến. Nếu bạn chạy phiên bản SQL Server của riêng mình, bạn có quyền kiểm soát mọi cài đặt.
• Định giá minh bạch. Định giá dựa trên tài nguyên bộ nhớ, máy tính và lưu trữ được yêu cầu.
• Di cư. Di chuyển tương đối dễ dàng cơ sở dữ liệu SQL Server tại chỗ của bạn sang Azure SQL do cùng một công cụ cơ bản.
• Tính ổn định và độ tin cậy. Microsoft SQL Server ban đầu được phát hành vào năm 1989 và đã trải qua một chặng đường dài kể từ đó. Nó là một công cụ cơ sở dữ liệu trưởng thành, ổn định và đã được thử nghiệm tốt.

Nhược điểm của cơ sở dữ liệu Azure SQL

• Lược đồ cố định. Nói chung, cơ sở dữ liệu SQL ít phù hợp hơn với các yêu cầu phần mềm thường xuyên thay đổi do lược đồ cố định của chúng. Việc di chuyển giản đồ có thể khó quản lý. Mặc dù SQL Server có thể hoạt động với dữ liệu JSON ngày nay (do đó thu hẹp khoảng cách giữa SQL và NoSQL), nó yêu cầu cú pháp đặc biệt và cảm thấy hơi giống như một suy nghĩ muộn màng.
• ACID đảm bảo và giao dịch phân tán. Mặc dù các tính năng này có thể rất hữu ích cho một số ứng dụng, nhưng chúng cũng làm giảm đáng kể khả năng mở rộng trong trường hợp bạn không cần đến chúng.
• Mở rộng quy mô hạn chế. Mặc dù mở rộng quy mô (bằng cách thêm nhiều bộ nhớ hoặc tính toán vào các phiên bản SQL Server của bạn) là một cách nhanh chóng và dễ dàng để tăng hiệu suất, nhưng nó có thể trở nên cực kỳ tốn kém ngoài một số điểm nhất định. Mở rộng quy mô (bằng cách thêm nhiều phiên bản của SQL Server) hầu như chỉ giới hạn ở các bản sao chỉ đọc.

Ưu điểm của Azure Cosmos DB

• Phân phối toàn cầu. Nhiều công ty ngày nay hoạt động trên toàn thế giới. Khách hàng của họ mong đợi hiệu suất tương tự từ các ứng dụng bất kể chúng được đặt ở đâu. Điều này làm cho mô hình cơ sở dữ liệu SQL tiêu chuẩn rất kém hiệu quả. Việc có một nút chính hỗ trợ ghi với nhiều bản sao chỉ đọc là không đủ cho các tác vụ như nguồn cấp dữ liệu mạng xã hội hoặc luồng dữ liệu IoT.
• Nhiều cấp độ nhất quán. Mặt khác, các ứng dụng này thường không cần sự đảm bảo nhất quán của cơ sở dữ liệu truyền thống. Họ có thể dựa vào các mô hình nhất quán yếu hơn như tiền tố nhất quán hoặc thậm chí nhất quán cuối cùng. Có quyền tự do lựa chọn mức độ nhất quán là lợi ích chính của Cosmos DB.
• Hỗ trợ lập chỉ mục tự động. Mỗi vùng chứa đều có chính sách lập chỉ mục được thiết lập để tăng tốc các truy vấn. Theo mặc định, mọi thuộc tính đều được lập chỉ mục và chỉ mục phạm vi được thực thi. Điều này là đủ cho hầu hết các trường hợp sử dụng. Tuy nhiên, cài đặt lập chỉ mục nâng cao có sẵn.
• Hỗ trợ nhiều ngôn ngữ khác nhau. Có sẵn các API được tạo sẵn cho .NET, Java, Python, Ruby và JavaScript. Không cần các lớp ORM phức tạp.
• Nhiều API. Cosmos DB cung cấp API lõi của riêng mình cũng như nhiều API cơ sở dữ liệu thay thế (API Gremlin, API Cassandra, API MongoDB, API bảng) giúp di chuyển từ các cơ sở dữ liệu NoSQL khác. Điều này làm giảm chi phí di chuyển và đường cong học tập.

Nhược điểm của Azure Cosmos DB

• Khó hiểu hơn đối với quản trị viên DB truyền thống. Vì Cosmos DB là một cơ sở dữ liệu NoSQL và không nhất thiết phải cung cấp đảm bảo ACID mạnh (tùy thuộc vào cấu hình), nên khó hiểu hơn đối với các quản trị viên DB quen xử lý cơ sở dữ liệu SQL truyền thống.
• Di chuyển phức tạp từ SQL Server. Việc di chuyển từ một giải pháp dựa trên SQL Server có thể rất tốn kém và trong những trường hợp cực đoan có thể yêu cầu viết lại các phần chính của ứng dụng. Việc tối ưu hóa tiếp theo sẽ mất nhiều thời gian hơn. Tôi chỉ khuyên bạn nên làm điều này nếu lợi ích của việc mở rộng quy mô toàn cầu lớn hơn những nỗ lực.
• Mô hình định giá khó hiểu. Mô hình định giá dựa trên Đơn vị yêu cầu có thể không trực quan. Máy tính công suất Cosmos DB trong cổng có thể giúp ước tính chi phí với điều kiện bạn có thể ước tính một số chỉ số chính nhất định. Nói chung, Cosmos DB có thể khá đắt.
• Chỉ dành cho đám mây công cộng. Nơi duy nhất mà Cosmos DB được triển khai là trong các trung tâm dữ liệu của Microsoft. Hiện tại, không có cung cấp cho các giải pháp đám mây kết hợp hoặc tại chỗ như Azure Arc.

Sự kết luận

Cả hai sản phẩm đều có một vị trí trong hệ sinh thái Azure. Trong khi Cơ sở dữ liệu Azure SQL cung cấp khả năng di chuyển dễ dàng từ giải pháp SQL Server tại chỗ của bạn và giúp bạn tận dụng kiến ​​thức SQL Server hiện có của mình, Cosmos DB được thiết kế từ đầu để phân phối toàn cầu và được quản lý hoàn toàn.

Nếu tôi phải quyết định sử dụng cơ sở dữ liệu nào cho một dự án mới, tôi chắc chắn sẽ sử dụng Cosmos DB, vì tôi chỉ đơn giản là yêu thích khả năng mở rộng và tính linh hoạt của nó. Là một dịch vụ NoSQL, việc tương tác với cơ sở dữ liệu chỉ đơn giản là tạo cảm giác tự nhiên hơn trong mã ứng dụng của bạn so với làm việc cho phần mềm trung gian ORM phức tạp cần thiết cho cơ sở dữ liệu truyền thống. Hơn nữa, việc lựa chọn nhiều mức độ nhất quán giúp bạn rất dễ dàng lựa chọn mức cân bằng phù hợp giữa tốc độ và tính nhất quán.

Mối quan tâm chính của tôi với Cosmos DB là đường cong học tập dốc của nó dành cho các quản trị viên đã từng làm việc với cơ sở dữ liệu SQL truyền thống. Việc thiết lập cơ sở dữ liệu Cosmos DB đầu tiên của bạn khiến bạn cảm thấy choáng ngợp. Bạn sẽ phải đọc qua nhiều tài liệu hoặc xem nhiều hướng dẫn để tìm ra cách thiết lập dịch vụ để đáp ứng các yêu cầu cụ thể của bạn.

Tuy nhiên, tôi nghĩ rằng điều này sẽ được cải thiện theo thời gian khi tỷ lệ chấp nhận tăng lên. Cosmos DB đã đi được một chặng đường dài trong một thời gian ngắn và tôi rất nóng lòng muốn xem chúng ta sẽ đi đến đâu tiếp theo.

Nguồn: https://betterprogramming.pub/azure-sql-database-vs-cosmos-db-which-should-you-choose-cda17b60d6d2

#cosmosdb #azure #sql 

PnPPowerShellを使用したSharePointOnlineでのアプリのみの認証

Azure AD Appのみの認証は、M365サービスへの認証と、データの読み取り、データのアップロード、自動化スクリプトを介したバックエンドジョブの実行などの操作に使用されています。Microsoftは、Azure ADに登録されているアプリケーションに証明書ベースの認証を使用して、M365または任意のクラウドサービスに対して認証することをお勧めします。CBAは、ユーザーのIDを検証するための非常に堅牢で安全なメカニズムです。 

この記事では、私が最近遭遇したユースケースについて説明したいと思います。以前は、SharePoint App Only認証を使用しています。これはACS（Azure Controlサービス）の概念であり、サイトコレクションの管理者はサイトコレクションに/_layouts/appregnew.aspxを追加することで、クライアントIDとクライアントシークレットを作成できます。アプリケーションで。ただし、このACSアプリのみのアクセストークン方式を使用する場合の問題はほとんどありません。

• 認証は安全ではありません。MSFTは、AzureADアプリのみの認証に切り替えることをお勧めします。
• アプリケーションが複数のサイトコレクションと通信するようにする場合は、複数のクライアントIDとシークレットを作成する必要があり、処理が面倒になります。

ACSトークンベースの認証の詳細については、参照セクションを参照してください。

幸いなことに、Azure ADアプリでは、SharePointのAPIアクセス許可に「Sites.Selected」という新しいアクセス許可が追加されました。これにより、AzureADアプリは単一のクライアントと証明書の詳細を使用して複数のサイトコレクションに対して認証できます。 

証明書を使用したこのAzureADアプリのみの認証に進む前に、Azure ADの証明書ベースの認証（別名CBA）とは何かを理解しようとします。AzureADには2種類のCBAがあります。 

1. フェデレーションADFSを使用した証明書ベースの認証
2. AzureAD証明書ベースの認証

フェデレーションADFSを使用した証明書ベースの認証

以前は、CBAを実装するために、ADFSサービスをユーザーとAzureADの間にデプロイする必要がありました。ADFSを使用するCBAは、X.509証明書を使用してAzureADに対して認証します。

• ここで、ユーザーは自分の資格情報とデバイスにインストールされた証明書を使用してアプリケーションに署名します。
• ADFSはユーザーの資格情報と証明書を検証し、成功するとアクセストークンをユーザーに渡してアプリケーションにアクセスします。

AzureAD証明書ベースの認証

Azure AD CBAである最新バージョンでは、ADFSの構成と展開は必要ありません。ユーザーはAzureADと直接対話し、アプリケーションに対して認証できます。

ADFSおよびAzureADCBAを使用したCBAの詳細については、参照セクションに記載されている記事を参照してください。

前提条件

• PnP.Powershellバージョン1.10.0。このバージョンでは、CBAを使用した認証が更新されていることに注意してください。

• PowerShellバージョン5.1以降
• PowerShellコマンドの実行に使用されるアカウントには、「グローバル管理者」権限が必要です。

AzureADアプリを作成する

次に、APIアクセス許可「サイト」を使用してAzureADアプリを作成する手順を実行します。タイプ「アプリケーション」の「選択済み」。次に、このAzure ADアプリを使用して、複数のサイトコレクションに対して認証します。記事を正しく実行するには、最新のPnPPowershellバージョンがインストールされている必要があります。

ステップ1

管理者としてPowerShellISEまたはコマンドウィンドウを開きます。

ステップ2

以下のPSコマンドを実行してアプリケーションを登録します。以下のコマンドを実行しているアカウントに「グローバル管理者」権限があることを確認してください。アカウントでMFA（Multi-Factor Authentication Enabled）がある場合は、プロンプトに従います

Register-PnPAzureADApp -ApplicationName SPSitesSelected -Tenant contosodev.onmicrosoft.com -Store CurrentUser -SharePointApplicationPermissions "Sites.Selected" -Interactive

ステップ3

認証が成功すると、必要なアーティファクトをチェックして同意フローを開始するために60秒待つことを示す以下のメッセージが表示されます。

ステップ4

アプリを登録してから、証明書と指紋を作成するために、もう一度認証するように求められます。プロンプトに従います

ステップ5

これで、以下のように認証が成功すると同意がポップアップ表示されます。アプリ名（この場合はSPSites Selected）と、承認およびキャンセルするオプションが表示されます。

[アプリ情報]をクリックして、アプリの詳細を確認することもできます。

ステップ6

[同意する]をクリックして同意することに同意すると、コマンド出力ウィンドウから次の情報が表示されます。

次の値があります、

• Pfxファイル：証明書に関連付けられた公開鍵と秘密鍵の両方の情報が含まれています。これは組織外で共有しないでください。
• Cerファイル：公開鍵とデバイス（この場合はサーバー）に関する情報が含まれています。これは通常、パートナーと交換されます。
• 指紋：アプリケーションへの認証に使用される証明書に関連付けられた安全なキー。
• Base64Encoded：これはASCII文字列形式の証明書情報です。

クライアントID、指紋、およびPfxファイルとCerファイルの場所のみをメモする必要があります。

上記の手順は、AzureADアプリケーションが「Sites.Selected」である必要なアクセス許可で作成されていることを確認します。これは、特定のサイトに対してのみ認証するようにAzureADアプリを構成できるようになったことを意味します。

AzureADアプリへのアクセスを許可する

ここで、Azure ADアプリへのアクセスを許可するには、次の一連のコマンドを実行します。

ステップ1

グローバル管理者の資格情報を持つPnPPowerShellモジュールを使用して、テナントのSharePoint管理者URLにログインします。

Connect-PnPOnline -Url "https://contoso-admin.sharepoint.com" -Interactive

ステップ2

認証時に、PnP管理シェルが実行できる権限に関する次の情報を取得します。

ここでは、組織に代わって同意するか、チェックを外したままにすることができます。[組織を代表して同意する]をオンにした場合、他のユーザーは同意を求められません。

ステップ3

次のコマンドを実行して、アプリに権限を付与します。アプリに付与できる権限は、「読み取り」または「書き込み」の2セットのみであることに注意してください。

Grant-PnPAzureADAppSitePermission -AppId 'YOUR APP ID HERE' -DisplayName 'APP DISPLAY NAME HERE' -Site 'https://contosodev.sharepoint.com/sites/CBADemo1' -Permissions Write

検証

ステップ1

権限が付与されているサイトに接続して、アプリへのアクセスを検証します。問題なくコンテンツが表示されるはずです。この場合、以前の接続が存在する場合は、以前のPnP接続から切断します。

Disconnect-PnPOnline

ステップ2

以下のコマンドを入力して、他にPnP接続が存在しないことを確認します。

Get-PnPConnection

「現在の接続にはSharePointコンテキストがありません」というエラーが表示されるはずです。

ステップ3

次に、AzureADアプリのクレデンシャルを使用してSharePointサイトに接続します。

Connect-PnPOnline -Url "https://contosodev.sharepoint.com/sites/CBADemo2" -ClientId "AZURE AD APP ID" -Thumbprint "CERT THUMP PRINT" -Tenant "YOUR TENANT DOMAIN"

アプリID（クライアントID）とフィンガープリントの値は、[AzureADアプリの作成]セクションの手順6で生成されることに注意してください。Azure ADポータルにログインし、[エンタープライズアプリケーション]でアプリを確認することで、AzureADから詳細を取得することもできます。

同様に、テナントドメインは、クイック起動から[Azure Active Directory]をクリックして、[プライマリドメイン]の値を探すことで取得できます。

ステップ4

次に、以下のコマンドを実行して、アプリが接続されているサイトを確認します。

Get-PnPSite

ステップ5

次に、以下のコマンドを実行して、このサイトコレクション内のすべてのリストのリストを取得します。

Get-PnPList

AzureADアプリがアクセスする必要のある他のサイトコレクションに対しても同じコマンドを実行できます。

ステップ6

アクセスが許可されていないサイトに接続して、アプリへのアクセスを検証します。403forbiddenエラーが表示されるはずです。

Connect-PnPOnline -Url "https://contosodev.sharepoint.com/sites/M365POC" -ClientId "YOUR CLIENT ID" -Thumbprint "CERT THUMP PRINT" -Tenant "contosodev.onmicrosoft.com"

クライアントIDと証明書のサンププリントを使用してサイトに接続しているときにエラーがスローされないことに気付いたかもしれませんが、サイトの詳細またはリストのコンテンツを取得するときにエラーがスローされます。

完全なスクリプト

#Creating Azure AD App with Certificate Thumbprint.
Register-PnPAzureADApp -ApplicationName SPSitesSelected -Tenant contosodev.onmicrosoft.com -Store CurrentUser -SharePointApplicationPermissions "Sites.Selected" -Interactive
#Connecting to SharePoint online Admin center using Global Admin Credentials
Connect-PnPOnline -Url "https://contosodev-admin.sharepoint.com" -Interactive
#Granting Access to Azure AD App for specific sites
Grant-PnPAzureADAppSitePermission -AppId 'bf8f7d56-c37f-44d6-abcb-670832e49b9c' -DisplayName 'SPSitesSelected' -Site 'https://contosodev.sharepoint.com/sites/CBADemo1' -Permissions Write
Grant-PnPAzureADAppSitePermission -AppId 'bf8f7d56-c37f-44d6-abcb-670832e49b9c' -DisplayName 'SPSitesSelected' -Site 'https://contosodev.sharepoint.com/sites/CBADemo2' -Permissions Write
#Disconnecting the previous connections
Disconnect-PnPOnline
#Validating the connection
Get-PnPConnection
#Connecting to SPO site using Azure AD App
Connect-PnPOnline -Url "https://contosodev.sharepoint.com/sites/CBADemo1" -ClientId "bf8f7d56-c37f-44d6-abcb-670832e49b9c" -Thumbprint "6A506565EABCD759C204C8517955301420A0C02D" -Tenant "contosodev.onmicrosoft.com"
#Gettting site details
Get-PnPSite
#Getting the list content
Get-PnPList
#Disconnecting from the Azure AD App connection
Disconnect-PnPOnline
#Connecting to SPO site using Azure Ad App with other site where access is not being granted.
Connect-PnPOnline -Url "https://contosodev.sharepoint.com/sites/M365POC" -ClientId "bf8f7d56-c37f-44d6-abcb-670832e49b9c" -Thumbprint "6A506565EABCD759C204C8517955301420A0C02D" -Tenant "contosodev.onmicrosoft.com"
#Get the site details
Get-PnPSite
#Get list content for site
Get-PnPList

結論

したがって、この記事では、

• AzureAD証明書ベースの認証とは何ですか
• さまざまな種類の認証
• PnPモジュールを使用して、「Sites.Selected」APIアクセス許可を持つAzureADアプリを生成します。
• Azure ADアプリへのアクセスを許可してから、アクセスを検証します。

参考文献

• https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-certificate-based-authentication
• https://4sysops.com/archives/azure-ad-certificate-based-user-authentication/
• https://docs.microsoft.com/en-us/azure/active-directory/authentication/active-directory-certificate-based-authentication-get-started
• https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs
• https://lazyadmin.nl/powershell/install-azure-ad-module/
• https://www.leonarmston.com/2022/01/pnp-powershell-csom-now-works-with-sharepoint-sites-selected-permission-using-azure-ad-app/

 このストーリーは、もともとhttps://www.c-sharpcorner.com/article/certificate-based-authentication-to-connect-to-sharepoint-online-sites/で公開されました。

#authentic #sharepoint #azure 

Autenticación Solo De Aplicaciones En SharePoint online Mediante PnP

La autenticación solo de aplicaciones de Azure AD se usa para autenticarse en los servicios de M365 y realizar algunas operaciones, como leer los datos, cargar los datos o realizar algunos trabajos de back-end a través de scripts de automatización. Microsoft recomienda utilizar la autenticación basada en certificados para sus aplicaciones registradas en Azure AD para autenticarse en el M365 o en cualquier servicio en la nube. CBA es un mecanismo extremadamente robusto y seguro para validar la identidad del usuario. 

En este artículo, quiero hablar sobre el caso de uso que encontré recientemente. Anteriormente, estaba usando la autenticación de solo aplicación de SharePoint, que es el concepto de ACS (servicios de control de Azure), donde el administrador de la colección de sitios puede crear un ID de cliente y un secreto de cliente agregando /_layouts/appregnew.aspx en la colección de sitios y usando las credenciales del cliente. en aplicación. Sin embargo, hay algunos problemas al usar este método de token de acceso de solo aplicación de ACS.

• La autenticación no es segura. MSFT recomienda cambiar a la autenticación de solo aplicación de Azure AD.
• Si desea que su aplicación se comunique con múltiples colecciones de sitios, es necesario crear múltiples ID de cliente y secretos, lo que se vuelve engorroso de manejar.

Puede consultar más información sobre la autenticación basada en token de ACS en la sección de referencias.

La buena noticia es que en la aplicación Azure AD, los permisos de API para SharePoint vienen con nuevos permisos llamados "Sitios.Seleccionados", que permitirán que su aplicación Azure AD se autentique en varias colecciones de sitios utilizando un solo cliente y detalles del certificado. 

Antes de pasar a esta autenticación solo de aplicaciones de Azure AD mediante certificados, intentaremos comprender qué es la autenticación basada en certificados (también conocida como CBA) en Azure AD. Hay 2 tipos de CBA en Azure AD. 

1. Autenticación basada en certificados con AD FS federado
2. Autenticación basada en certificados de Azure AD

Autenticación basada en certificados con AD FS federado

Anteriormente, para implementar el CBA, los servicios de ADFS deben implementarse entre los usuarios y Azure AD. CBA con ADFS usa certificados X.509 para autenticarse en Azure AD.

• Aquí el usuario inicia sesión en la aplicación con sus credenciales y también con el certificado instalado en sus dispositivos.
• ADFS valida las credenciales y el certificado del usuario y, en caso de éxito, pasa tokens de acceso al usuario para acceder a las aplicaciones.

Autenticación basada en certificados de Azure AD

La última versión, que es Azure AD CBA, no necesita configuración ni implementación de AD FS. Los usuarios pueden interactuar directamente con Azure AD y autenticarse en las aplicaciones.

Para obtener más detalles sobre CBA con AD FS y Azure AD CBA, puede consultar los artículos mencionados en la sección de referencias.

requisitos previos

• PnP.Powershell versión 1.10.0. Tenga en cuenta que la autenticación mediante CBA se actualiza en esta versión.

• PowerShell versión 5.1 o posterior
• La cuenta utilizada para ejecutar los comandos de PowerShell debe tener derechos de "Administrador global".

Crear una aplicación de Azure AD

Ahora seguiremos los pasos para crear la aplicación Azure AD, con permisos de API "Sitios. Seleccionado” de tipo “Aplicación”. Luego use esta aplicación de Azure AD para autenticarse en varias colecciones de sitios. Para poder seguir correctamente el artículo, es necesario tener instalada la última versión de PnP Powershell.

Paso 1

Abra PowerShell ISE o las ventanas de comandos como administrador.

Paso 2

Registre la aplicación ejecutando el siguiente comando PS. Asegúrese de que la cuenta que ejecuta los siguientes comandos tenga derechos de 'Administrador global'. Siga las indicaciones si la cuenta tiene MFA (autenticación multifactor habilitada)

Register-PnPAzureADApp -ApplicationName SPSitesSelected -Tenant contosodev.onmicrosoft.com -Store CurrentUser -SharePointApplicationPermissions "Sites.Selected" -Interactive

Paso 3

En una autenticación exitosa, recibirá el siguiente mensaje que dice que debe esperar 60 segundos para verificar los artefactos requeridos e iniciar el flujo de consentimiento.

Paso 4

Se le pedirá que se autentique una vez más para registrar la aplicación y luego para crear un certificado y una huella digital. Siga las instrucciones de nuevo

Paso 5

Ahora tendrá una ventana emergente de consentimiento en una autenticación exitosa similar a la siguiente. Muestra el nombre de la aplicación (en este caso, SPSites seleccionado) y opciones para Aceptar y cancelar.

También puede verificar los detalles de la aplicación haciendo clic en 'Información de la aplicación'.

Paso 6

Después de aceptar el consentimiento haciendo clic en 'Aceptar', debería ver la siguiente información en la ventana de salida del comando.

Tendrás los siguientes valores,

• Archivo Pfx: incluye información de clave tanto pública como privada asociada al certificado. Esto no debe compartirse fuera de su organización.
• Archivo cer: tiene clave pública y alguna información sobre el dispositivo (en este caso el servidor). Esto normalmente se intercambia con los socios.
• Huella digital: una clave segura asociada con el certificado que se utiliza para autenticarse en la aplicación.
• Base64Encoded: esta es la información del certificado en formato de cadena ASCII.

Debe anotar solo el ID del cliente, la huella digital y la ubicación de los archivos Pfx y Cer.

Los pasos anteriores confirman que la aplicación de Azure AD se crea con los permisos necesarios, que es "Sitios.Seleccionados". Esto significa que la aplicación de Azure AD ahora se puede configurar para autenticarse solo en sitios específicos.

Concesión de acceso a la aplicación Azure AD

Ahora, para otorgar acceso a la aplicación Azure AD, ejecute el siguiente conjunto de comandos.

Paso 1

Inicie sesión en la URL de administración de SharePoint para su arrendatario mediante el módulo PnP PowerShell con credenciales de administrador global.

Connect-PnPOnline -Url "https://contoso-admin.sharepoint.com" -Interactive

Paso 2

En la autenticación, obtendrá la siguiente información, sobre los permisos sobre lo que podría hacer el shell de administración de PnP.

Aquí puede dar su consentimiento en nombre de la organización o dejarlo sin marcar. Si marcó 'Consentimiento en nombre de su organización', no se solicitará el consentimiento de ningún otro usuario.

Paso 3

Otorgue el permiso a la aplicación ejecutando el siguiente comando. Tenga en cuenta que solo hay 2 conjuntos de permisos que puede otorgar a la aplicación, que es 'Lectura' o 'Escritura'.

Grant-PnPAzureADAppSitePermission -AppId 'YOUR APP ID HERE' -DisplayName 'APP DISPLAY NAME HERE' -Site 'https://contosodev.sharepoint.com/sites/CBADemo1' -Permissions Write

Validación

Paso 1

Valide el acceso a la aplicación conectándose a sitios que tengan permisos. Debería ver el contenido sin ningún problema. En este caso, desconéctese de las conexiones PnP anteriores si existen conexiones anteriores.

Disconnect-PnPOnline

Paso 2

Valide que no exista otra conexión PnP escribiendo el siguiente comando.

Get-PnPConnection

Debería ver el error que dice "La conexión actual no tiene contexto de SharePoint".

Paso 3

Ahora conéctese al sitio de SharePoint usando las credenciales de la aplicación Azure AD.

Connect-PnPOnline -Url "https://contosodev.sharepoint.com/sites/CBADemo2" -ClientId "AZURE AD APP ID" -Thumbprint "CERT THUMP PRINT" -Tenant "YOUR TENANT DOMAIN"

Tenga en cuenta que los valores de ID de aplicación (ID de cliente) y Huella digital se generan en el Paso 6 en la sección "Crear aplicación de Azure AD". También puede obtener los detalles de su Azure AD iniciando sesión en Azure AD Portal y revisando su aplicación en 'Aplicaciones empresariales'.

De manera similar, el dominio del arrendatario se puede obtener haciendo clic en 'Azure Active Directory' desde el inicio rápido y buscando el valor 'Dominio principal'.

Paso 4

Ahora verifique a qué sitio está conectada la aplicación ejecutando el siguiente comando.

Get-PnPSite

Paso 5

Ahora obtenga la lista de todas las listas en esta colección de sitios ejecutando el siguiente comando.

Get-PnPList

Puede ejecutar los mismos comandos para cualquier otra colección de sitios a la que necesite acceder la aplicación Azure AD.

Paso 6

Valide el acceso a la aplicación conectándose a sitios a los que no se les otorga acceso. Debería ver el error 403 prohibido.

Connect-PnPOnline -Url "https://contosodev.sharepoint.com/sites/M365POC" -ClientId "YOUR CLIENT ID" -Thumbprint "CERT THUMP PRINT" -Tenant "contosodev.onmicrosoft.com"

Es posible que haya notado que no arroja ningún error al conectarse al sitio utilizando la ID del cliente y la impresión del certificado, sin embargo, arroja un error al obtener los detalles del sitio o el contenido de la lista.

Guión completo

#Creating Azure AD App with Certificate Thumbprint.
Register-PnPAzureADApp -ApplicationName SPSitesSelected -Tenant contosodev.onmicrosoft.com -Store CurrentUser -SharePointApplicationPermissions "Sites.Selected" -Interactive
#Connecting to SharePoint online Admin center using Global Admin Credentials
Connect-PnPOnline -Url "https://contosodev-admin.sharepoint.com" -Interactive
#Granting Access to Azure AD App for specific sites
Grant-PnPAzureADAppSitePermission -AppId 'bf8f7d56-c37f-44d6-abcb-670832e49b9c' -DisplayName 'SPSitesSelected' -Site 'https://contosodev.sharepoint.com/sites/CBADemo1' -Permissions Write
Grant-PnPAzureADAppSitePermission -AppId 'bf8f7d56-c37f-44d6-abcb-670832e49b9c' -DisplayName 'SPSitesSelected' -Site 'https://contosodev.sharepoint.com/sites/CBADemo2' -Permissions Write
#Disconnecting the previous connections
Disconnect-PnPOnline
#Validating the connection
Get-PnPConnection
#Connecting to SPO site using Azure AD App
Connect-PnPOnline -Url "https://contosodev.sharepoint.com/sites/CBADemo1" -ClientId "bf8f7d56-c37f-44d6-abcb-670832e49b9c" -Thumbprint "6A506565EABCD759C204C8517955301420A0C02D" -Tenant "contosodev.onmicrosoft.com"
#Gettting site details
Get-PnPSite
#Getting the list content
Get-PnPList
#Disconnecting from the Azure AD App connection
Disconnect-PnPOnline
#Connecting to SPO site using Azure Ad App with other site where access is not being granted.
Connect-PnPOnline -Url "https://contosodev.sharepoint.com/sites/M365POC" -ClientId "bf8f7d56-c37f-44d6-abcb-670832e49b9c" -Thumbprint "6A506565EABCD759C204C8517955301420A0C02D" -Tenant "contosodev.onmicrosoft.com"
#Get the site details
Get-PnPSite
#Get list content for site
Get-PnPList

Conclusión

Por lo tanto, en este artículo, hemos aprendido sobre

• ¿Qué es la autenticación basada en certificados de Azure AD y
• los diferentes tipos de autenticación
• utilizando el módulo PnP para generar la aplicación Azure AD con los permisos de API 'Sitios.Seleccionados'.
• Otorgar acceso a la aplicación Azure AD y luego validar el acceso.

Referencias

• https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-certificate-based-authentication
• https://4sysops.com/archives/azure-ad-certificate-based-user-authentication/
• https://docs.microsoft.com/en-us/azure/active-directory/authentication/active-directory-certificate-based-authentication-get-started
• https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs
• https://lazyadmin.nl/powershell/install-azure-ad-module/
• https://www.leonarmston.com/2022/01/pnp-powershell-csom-now-works-with-sharepoint-sites-selected-permission-using-azure-ad-app/

 Esta historia se publicó originalmente en https://www.c-sharpcorner.com/article/certificate-based-authentication-to-connect-to-sharepoint-online-sites/

#authentic #sharepoint #azure 

Advanced Analytics Tutorial Using Apache Spark in Azure Databricks

In this session you will learn the fundamentals of how to apply advanced analytics using Apache spark in Azure databricks. We will focus on how to build and deploy a machine learning model, then I have a look at how you can get started with graph based processing, using graph frames in Apache spark. The combination of big data, machine learning and graph based processing, helps to fully realise the full spectrum of advanced analytics.

You will learn the fundamentals of Spark and how it is enabled on Databricks. Then we will look at how you get started with Machine Learning and Graph based processing

You will be able to begin to work with Machine Learning & Advanced Analytics in Spark.

Spark is one of the most desirable skills on the market. Integrating with big data pipelines is fundamental to the success of Machine Learning with Big Data.

#azure #analytics #apachespark 

Azure Cosmos DB SQL API

Azure Cosmos DB SQL API is sometimes called the "core" API for the database. It is often the most frequently used. It allows documents to be stored in database collections as semi-structured data and queried using a SQL. There are limits to this, but still, it's a nice option for creating a database that needs to store data where schemas and joins are less important.

#azure #api #sql 

Azure Serverless Conf at C# Corner (3 Hours)

No matter where you are located, we want you to join us for the free, virtual developer event focused on building event-driven apps using Azure Serverless technologies. These technologies include Functions, Cosmos DB, Azure SQL DB, and Logic Apps. We look forward to unplugging with you, learning from experts, and connecting with the community. See you on Learn TV!

#csharp #serverless #azure 

Azure-sdk-tools-xplat: Microsoft Azure Cross Platform Command Line

Microsoft Azure Xplat-CLI for Windows, Mac and Linux 

This project provides a cross-platform command line interface for developers and IT administrators to develop, deploy and manage Microsoft Azure applications.

Features

• Accounts
  • Azure Active Directory authentication for Organizational ID
  • Download and import Azure publish settings
  • List imported Azure subscriptions
  • Select current subscription
  • Manage Azure environments
  • Create and manage affinity groups
  • Export management certificate
• Storage
  • Create and manage Storage Accounts
  • Create and manage container, blob and ACL
• Websites
  • Create and manage Microsoft Azure websites
  • Download site log files and get real time log streaming
  • Manage Deployments
  • Configure GitHub integration
  • Create, manage and swap slots
  • Create and manage WebJobs
• Virtual machines
  • Create and manage Windows and Linux Virtual machines
  • Create and manage VM endpoints
  • Create and manage Virtual Machine Images
  • Create and manage certificates
  • CloudInit for Ubuntu VM
  • Create and manage Docker host virtual machines
• Network
  • Import and export network configuration
  • Create and manage virtual network
  • Create and manage DNS server
• Mobile Services
  • Create and manage Mobile Services
  • Manage tables, scripts, and configuration
  • Access logs
  • Access data
• Service Bus
  • Create and manage Service Bus namespaces
• SQL Database
  • Create and manage SQL Servers, Firewall rules and Databases
• Resource Manager
  • Manage resource groups and deployments
  • Query and download gallery templates
  • Manage individual resources

Installation

Install from npm

You can install the azure-cli npm package directly.

npm install -g azure-cli

Pre-compiled installers

• Windows
• Mac
• Linux

Download Source Code

To get the source code of the SDK via git just type:

git clone https://github.com/Azure/azure-sdk-tools-xplat.git
cd ./azure-sdk-tools-xplat
npm install

Configure auto-complete

Auto-complete is supported for Mac and Linux.

To enable it in zsh, run:

echo '. <(azure --completion)' >> .zshrc

To enable it in bash, run:

azure --completion >> ~/azure.completion.sh
echo 'source ~/azure.completion.sh' >> .bash_profile

Get Started

In general, following are the steps:

• Get yourself authenticated with Microsoft Azure. For details, please check out this article.
  • Option 1: Login with your Organizational account. Azure Active Directory authentication is used in this case. No management certificate is needed. Note: Microsoft account is not supported in this approach right now. You can create an Organizational account from the Azure portal for free.
  • Option 2: Download and import a publish settings file which contains a management certificate.
• Use the commands

The first step can be different for different environment you are targeting. Following are detail instructions for each supported environment.

Microsoft Azure

If you use both mechanisms on the same subscription, Azure Active Directory authentication always wins. If you want to go back to management certificate authentication, please use azure logout, which will remove the Azure Active Directory information and bring management certificate authentication back in.

Login directly from xplat-cli (Azure Active Directory authentication)

# This will prompt for your password in the console
azure login -u <your organizational ID email address>

# use the commands to manage your services/applications
azure site create --location "West US" mywebsite

Use publish settings file (Management certificate authentication)

# Download a file which contains the publish settings information of your subscription.
# This will open a browser window and ask you to log in to get the file.
azure account download

# Import the file you just downloaded.
# Notice that the file contains credential of your subscription so you don't want to make it public
# (like check in to source control, etc.).
azure account import <file location>

# Use the commands to manage your services/applications
azure site create --location "West US" mywebsite

2 Modes

Starting from 0.8.0, we are adding a separate mode for Resource Manager. You can use the following command to switch between the

• Service management: commands using the Azure service management API
• Resource manager: commands using the Azure Resource Manager API

They are not designed to work together.

azure config mode asm # service management
azure config mode arm # resource manager

For more details on the commands, please see the command line tool reference and this How to Guide

Docker

Usage is same as standard vm create.

azure vm docker create [options] <dns-name> <image> <user-name> [password]

This command only supports Ubuntu 14.04 based images. Docker is configured on the VM using HTTPS as described here: http://docs.docker.io/articles/https/ By default, certificates are put in ~/.docker, and Docker is configured to run on port 4243. These can be configured using new options:

-dp, --docker-port [port]              Port to use for docker [4243]
-dc, --docker-cert-dir [dir]           Directory containing docker certs [.docker/]

After the VM is created. It can be used as a Docker host with the -H option or DOCKER_HOST environment variable.

docker --tls -H tcp://<my-host>.cloudapp.net:4243 run

Note: To run docker commands on windows make sure ssl agent is installed.

Running Tests

See this page for instructions that describe how to run the test suite.

Learn More

For documentation on how to host Node.js applications on Microsoft Azure, please see the Microsoft Azure Node.js Developer Center.

For more extensive documentation on the new cross platform CLI tool for Mac and Linux, please see this reference and this How to Guide

Contribute Code or Provide Feedback

If you would like to become an active contributor to this project please follow the instructions provided in Microsoft Azure Projects Contribution Guidelines.

If you encounter any bugs with the library please file an issue in the Issues section of the project.

Author: orangemocha
Source Code: https://github.com/orangemocha/azure-sdk-tools-xplat 
License: Apache-2.0 license

#node #nodejs #azure #linux