Category: Cloud

What is Orleans?

Building cloud-native applications can be a challenging and complicated task. Cloud-native apps must be designed to handle elasticity, resiliency, distributed infrastructure, and other concerns. Developers often rely on frameworks to provide abstractions over these internal implementation details, so they can focus on building business features. Orleans is a robust framework for building scalable, distributed, cloud-native applications. Orleans runs cross-platform anywhere that .NET is supported and integrates well with other platform features.

Orleans simplifies the process of building distributed, scalable applications. There are several key concepts to understand in order to work with Orleans effectively.

The virtual actor model

Orleans is built around the “actor model”, which is an established design pattern that has existed since the 1970s. The actor model is a pattern that stores pieces of state data and corresponding behavior in lightweight, immutable objects called actors. Actors communicate with each other using asynchronous messages. Orleans manages and simplifies much of the parallel communication required by distributed apps for you. Orleans invented the virtual actor model, where actors exist perpetually whenever they’re needed. This architecture lends itself well to cloud-native applications, which require distributed and resilient state and parallel operations.

Grains

Grains are the most essential primitives and building blocks of Orleans applications. They represent actors in the Actor model and define the state data and behavior of entities you define, such as shopping cart or product. Grains are each identified and tracked through user-defined keys and can be accessed by other grains and clients.

Grains are stored in silos, which you explore later. Grains that are currently active and in use by your application will remain in memory, while inactive grains can be persisted to your desired storage. A grain becomes active again when it’s needed or requested by the app. Grains have a managed life cycle, which means the Orleans runtime handles activating, deactivating, storing, and locating grains as needed by the application. Developers don’t have to worry about managing these concerns themselves and can write code that assumes a grain is available in memory.

grain-lifecycle

Silos

Silos are responsible for storing grains and are another core building block of Orleans. A silo can contain one or more grains; a group of silos is known as a cluster. The cluster coordinates work between silos, allowing communication with grains as though they were all available in a single process. You can organize your data by storing different types of grains in different silos. Your application can retrieve individual grains without having to worry about the details of how they’re managed within the cluster.

silos

Other features of Orleans

Orleans supports plenty of other features for more specific or advanced scenarios.

Streams: Streams help developers process sets of data in near-real-time. Like other features of Orleans, streams are managed by the runtime and available on demand. They’re loosely coupled and can apply various queue technologies, such as Azure Event Hubs.

Timers and Reminders: Orleans supports scheduling operations for grains. You can ensure that various actions are completed at a given time even on inactive grains.

Versioning: Grains can be versioned to account for changes in your application. Orleans will handle mapping and managing different implementations of your versioned grains across your silos and clusters.

ACID transactions: Grains can have transactional state and support ACID transaction features.

These capabilities can be explored as you start to build more complex apps. Next post you’ll explore the basics of how Orleans works.

Azure Monitor Overview

Azure Monitor helps you maximize the availability and performance of your applications and services.

Overview

The following diagram is a high-level view of Azure Monitor.

  • At the center of the diagram, you’ll find the data stores for metrics and logs and changes. These data stores are the fundamental types of data used by Azure Monitor.
  • On the left are the sources of monitoring data that populate the data stores.
  • On the right are the different functions that Azure Monitor performs with this collected data. This diagram includes such actions as analysis, alerting, and integration such as streaming to external systems.

 

 

What data does Azure Monitor collect?

Metrics, logs, and distributed traces are commonly referred to as the three pillars of observability.

Pillar Description
Metrics Metrics are numerical values that describe some aspect of a system at a particular point in time. They’re collected at regular intervals and are identified with a timestamp, a name, a value, and one or more defining labels.
Logs Logs are events that occurred within the system. They can contain different kinds of data and may be structured or free-form text with a timestamp.
Distributed traces Traces are series of related events that follow a user request through a distributed system.
Changes Changes are a series of events that occur in your Azure application and resources. Change Analysis tracks changes and is a subscription-level observability tool that’s built on the power of Azure Resource Graph.

Insights and curated visualizations

Some Azure resource providers have a “curated visualization”, which provide a customized monitoring experience for that particular service or set of services.

Larger, scalable, curated visualizations are known as “insights” and marked with that name in the documentation and the Azure portal. Examples of insights include Application Insights, Container Insights, and VM Insights.

Modern Cloud Security Layer [Explain]

Healthcare organizations store personal and potentially sensitive customer data. Financial institutions store account numbers, balances, and transaction history. Retailers store purchase history, account information, and demographic details of customers. A security incident might expose this sensitive data, which might cause personal embarrassment or financial harm. How do you ensure the integrity of their data and ensure that your systems are secure?

In this article, you’ll learn about the important elements of the security pillar.

What is security?

Security is ultimately about protecting the data that your organization uses, stores, and transmits. The data that your organization stores or handles is at the heart of your securable assets. This data might be sensitive data about customers, financial information about your organization, or critical line-of-business data that supports your organization. Securing the infrastructure on which the data exists, along with the identities used to access it, is also critically important.

Your data might be subject to additional legal and regulatory requirements, depending on where you’re located, the type of data you’re storing, or the industry in which your application operates.

For instance, in the healthcare industry in the United States, there’s a law called the Health Insurance Portability and Accountability Act (HIPAA). In the financial industry, the Payment Card Industry Data Security Standard is concerned with the handling of credit card data. Organizations that store data that’s in scope for these laws and standards are required to ensure that certain safeguards are in place for the protection of that data. In Europe, the General Data Protection Regulation (GDPR) lays out the rules of how personal data is protected, and defines individuals’ rights related to stored data. Some countries require that certain types of data do not leave their borders.

When a security breach occurs, there can be substantial impacts to the finances and reputation of both organizations and customers. This breaks down the trust that customers are willing to instill in your organization, and can affect the organization’s long-term health.

Defense in depth

A multilayered approach to securing your environment will increase the security posture of your environment. Commonly known as defense in depth, we can break down the layers as follows:

  • Data
  • Applications
  • VM/compute
  • Networking
  • Perimeter
  • Policies and access
  • Physical security

Each layer focuses on a different area where attacks can happen, and creates a depth of protection if one layer fails or is bypassed by an attacker. If you were to focus on just one layer, an attacker would have unfettered access to your environment if they got through this layer.

Addressing security in layers increases the work an attacker must do to gain access to your systems and data. Each layer will have different security controls, technologies, and capabilities that will apply. When you’re identifying the protections to put in place, cost is often of concern. You’ll need to balance cost with business requirements and overall risk to the business.

cloud-security-layers

No single security system, control, or technology will fully protect your architecture. Security is more than just technology; it’s also about people and processes. Creating an environment that looks holistically at security and makes it a requirement by default will help ensure that your organization is as secure as possible.

Protect from common attacks

At each layer, there are some common attacks that you’ll want to protect against. The following list isn’t all-inclusive, but it can give you an idea of how each layer can be attacked and what types of protections you might need.

  • Data layer: Exposing an encryption key or using weak encryption can leave your data vulnerable if unauthorized access occurs.
  • Application layer: Malicious code injection and execution are the hallmarks of application-layer attacks. Common attacks include SQL injection and cross-site scripting (XSS).
  • VM/compute layer: Malware is a common method of attacking an app hosting environment, which involves executing malicious code to compromise a system. After malware is present on a system, further attacks that lead to credential exposure and lateral movement throughout the environment can occur.
  • Networking layer: Unnecessary open ports to the internet are a common method of attack. These might include leaving SSH or RDP open to virtual machines. When these protocols are open, they can allow brute-force attacks against your systems as attackers attempt to gain access.
  • Perimeter layer: Denial-of-service (DoS) attacks often happen at this layer. These attacks try to overwhelm network resources, forcing them to go offline or making them incapable of responding to legitimate requests.
  • Policies and access layer: This layer is where authentication occurs for your application. This layer might include modern authentication protocols such as OpenID Connect, OAuth, or Kerberos-based authentication such as Active Directory. The exposure of credentials is a risk at this layer, and it’s important to limit the permissions of identities. You also want to have monitoring in place to look for possible compromised accounts, such as logins coming from unusual places.
  • Physical layer: Unauthorized access to facilities through methods, such as door drafting and theft of security badges, can happen at this layer.

Shared security responsibility

Revisiting the model of shared responsibility, we can reframe this in the context of security. Depending on the type of service you select, some security protections will be built in to the service, while others will remain your responsibility. Careful evaluation of the services and technologies that you select will be necessary, to ensure that you’re providing the proper security controls for your architecture.