Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.
A Pod contains one or more containers. Containers are grouped into Pods so Kubernetes can provide services that are not supported in containers. For example, Pods provide shared storage/network resources, and a specification for how to run the containers. Docker is the most commonly known runtime, but it can be other types.
In short, Pods enable you to manage several tightly coupled application containers as a single unit.
Kubernetes can run Windows. So the command to manage Pods running Windows are the same as those running Linux. But you should know that you define Windows or Linux when you create the cluster.
In this article, you learn about how Pods work, how you can have multiple containers in a Pod, the lifecycle of a Pod, how Kubernetes handles networking with a Pod, and how to define a Pod using a PodTemplate in a Deployment, Job, or other Kubernetes resource.
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.