When you create, update, and delete resources in Azure you are using the Azure Resource Manager (ARM). Azure Resource Manager provides access control, tagging, auditing of your resources.
In this article, you use the portal, PowerShell, the Azure Command Line Interface (CLI) to create, manage access and delete resources. Links are provided in the reference section of this chapter for you to learn how to manage resources using the REST API.
You create resources in either an imperative way by describing each of the steps and feature with scripts. In a following post, you will learn how to create resources using a declarative syntax with an ARM template to describe the features and properties.
You can get started in Azure. But soon it becomes time to build your subscriptions for your enterprise. For example, giving unrestricted access to developers can make your devs very agile, but it can also lead to unintended cost consequences. In addition, you will want to have requirements to demonstrate compliance for security, monitoring, and resource access control.
In this article we help organize some thoughts around the strategy and plan for building out your cloud, including a plan that you can put into Azure DevOps.
Azure Content Delivery Network (CDN) is designed to send audio, video, applications, images, and other files faster and more reliably to customers using servers that are closest to each user. If you want to put binary files and blobs closer to your user, then CDN can be the right solution.
The CDN caches publicly available objects at strategically placed locations to provide maximum bandwidth for delivering content to users.
Essentially, when a user wants some content, the first user gets the data from the source server. When you use a CDN, that data is then cached at a site near the user. So subsequent users can get the data from the cache instead of going all the way back to the source server. For example, if a picture stored in a blob is in a European data center in Azure, a user in Portland Oregon would be able to access the file from a server set up in Seattle, making your image load much faster.
Azure Redis Cache helps your application become more responsive even as user load increases and leverages the low latency, high-throughput capabilities of the Redis engine. This separate distributed cache layer allows your data tier to scale independently for more efficient use of compute resources in your application layer.
Microsoft Azure Redis Cache is based on this cache and store. It gives you access to a secure, dedicated Redis cache, managed by Microsoft, providing the best of both worlds: the rich features and ecosystem of Redis, and reliable hosting and monitoring by Microsoft.
Azure Redis Cache leverages Redis authentication and also supports SSL connections to Redis.
The purpose of this article is to help you decide if Azure Redis is the right technology for your project. The Azure documentation is pretty good to help you get started, but is spread all over the place, so this article focuses on the steps to get started, and gives you a peek into what your code looks like. (If you are like me, you can often tell if the technology is a good fit by seeing code.)
Microsoft Azure Cache is a family of distributed, in-memory, scalable solutions that enable you to build highly scalable and responsive applications by providing super-fast access to your data. But what do you choose?
This post provides you with an overview of the options you have when you are considering caching technologies.
Microsoft Azure Cache is available in the following offerings.
In this post, you will learn the design methodology, walk through a step by step scenario where the client and server trade information to perform a set of actions, and you will learn more about the SOA design patterns.
In the previous posts, you learned how to design your RESTful API. In this post, you will learn about the best practices of versioning, analytics, how to set up your API root, what your consumers are expecting for results, why and how filtering should work, and caching.
In the post Designing Your RESTful API Part 1: The Nouns, you learned the importance of resources, request headers, and the request body when you defined your RESTful API. In this post, you will learn about the five or so request verbs and what is send back to the client in the response body and the response status code.
Everything is a resource in REST. As you learned in Choosing Between RESTful Web Service, SOAP, Representational State Transfer (REST) is an architecture style or design pattern for creating web services which allow anything connected to a network to something else on the network using Hypertext Transfer Protocol (HTTP).
In this post, you will learn the how to define your resource identifier. In the following post, you will learn how to use the HTTP verbs and response codes. And along the way you will learn many of the principles of a good RESTful API.
Let me second what As Thomas Hunter II writes:
The easier your API is to consume, the more people that will consume it.