Deployment Scripts in ARM Templates

Deployment Scripts in ARM Templates

I’ve been authoring ARM templates since Azure moved from the Service Manager model to the Resource Manager model, and I never regretted it.

We are starting with a bit of a history lesson. For some of us, this might seem like ancient history when counting in cloud years but bear with me.

When Azure first launched back in 2008, the underlying operating system was called Red Dog or RD in short, and it was Platform as a Service only. Yeah, your read right, only PaaS, no IaaS, or any other services you have right now; and it was very much agreeable. New, obscure, but interesting.

Continue reading
Azure Image Builder – Build and Maintain golden images with ease

Azure Image Builder – Build and Maintain golden images with ease

If you’re an on-premises person and start now with the cloud, you might be familiar with golden images. You know the benefits of having golden images, and you even have a couple of best-practices around your belt.

To recap what a golden image is, it’s a pre-configured template that you use to deploy hundreds of user systems, deploy standardized server configurations, and so on. Golden images usually get called master images, base images, or clones. The idea of a golden image is to provide you with a consistent deployment experience while saving time and reducing user-induced errors.

So can we use the knowledge we gained on-premises with golden images inside the cloud? Yes, of course! In Azure, you even have multiple ways of creating these golden images.

Today we’re going to talk about a managed service called Azure Image Builder, which allows us to implement a “DevOps” way of managing system images.

Continue reading
KEDA 2.0 – An update from KEDA 1.0

KEDA 2.0 – An update from KEDA 1.0

In a previous blog post – Serverless anywhere with Kubernetes – I wrote how you could write serverless code and run it in a container wherever you want without any vendor lock-in.

KEDA (Kubernetes-based Event-Driven Autoscaling) is an opensource project built by Microsoft in collaboration with Red Hat, which provides event-driven autoscaling to containers running on an AKS (Azure Kubernetes Service), EKS ( Elastic Kubernetes Service), GKE (Google Kubernetes Engine) or on-premises Kubernetes clusters 

KEDA allows for fine-grained autoscaling (including to/from zero) for event-driven Kubernetes workloads. KEDA serves as a Kubernetes Metrics Server and allows users to define autoscaling rules using a dedicated Kubernetes custom resource definition. Most of the time, we scale systems (manually or automatically) using some metrics that get triggered.

For example, if CPU > 60% for 5 minutes, scale our app service out to a second instance. By the time we’ve raised the trigger and completed the scale-out, the burst of traffic/events has passed. KEDA, on the other hand, exposes rich events data like Azure Message Queue length to the horizontal pod auto-scaler so that it can manage the scale-out for us. Once one or more pods have been deployed to meet the event demands, events (or messages) can be consumed directly from the source, which in our example is the Azure Queue.

Quote from Serverless anywhere with Kubernetes
Continue reading
Password-less Authentication with FIDO2 in Azure or other Microsoft services

Password-less Authentication with FIDO2 in Azure or other Microsoft services

As a security-conscious person, I try all the time to find new ways to enhance my security posture in ways where I get the best of both worlds without adding too much complexity. That means that I want to have the latest and greatest security measures implemented without having a very complex infrastructure which, in the end, it might end up as a single point of failure. 

In some ways, you might consider me more of a paranoid person rather than a security-conscious person. My whole home has layers over security layers implemented where you might say that I harbor military secrets.

Continue reading

Azure Private Link – What is it and how to use it

Accessing Azure PaaS services has never easier.

Azure Private link is a relatively new service that allows the users to connect to a PaaS service privately using an IP address.

You might say that this feature existed for ages with Service Endpoints which injected the PaaS service in a virtual network and allowed private connectivity towards the service without it being exposed on the internet. The main difference between the two is that Service Endpoints only injects the service in the Virtual Network and cuts off the internet connection while Private Link is a service that attaches a private IP that exists in your virtual network and you can access it using that RFC1918 IP address.

As I mentioned, before Private Link we had Azure Service Endpoints which injected the PaaS service in the delegated subnet and then the Azure gateway cut off any internet traffic towards it.

Continue reading

Governance & Security in Azure – The untold truth

Moving to the cloud is “easy”; Managing it is another ordeal.

I’m going to start with a disclaimer; This post focuses on achieving governance and security in Azure; This doesn’t mean that what I’m going to write here cannot apply to AWS or Google, they have other technologies that can help you achieve full governance;

Let’s continue.

CONTINUE READING
Azure SQL Databases – DTU or vCore

Azure SQL Databases – DTU or vCore

DTU or vCore? That is the question.

When they first came as an offering a long time ago, Azure SQL Databases always had a mystery attached to them regarding the performance tier you should use.

DTU

Database Throughput Unit or DTU is a way to describe the relative capacity of a performance SKU of Basic, Standard, and Premium databases. DTUs are based on a measure of CPU, memory, I/O reads, and writes. When you want to increase the “power” a database, you just increase the number of DTUs that are allocated to that database. A 100 DTU DB is much more powerful than a 50 DTU one.

CONTINUE READING
Serverless anywhere with Kubernetes

Serverless anywhere with Kubernetes

KEDA (Kubernetes-based Event-Driven Autoscaling) is an opensource project built by Microsoft in collaboration with Red Hat, which provides event-driven autoscaling to containers running on an AKS (Azure Kubernetes Service), EKS ( Elastic Kubernetes Service), GKE (Google Kubernetes Engine) or on-premises Kubernetes clusters 😉

KEDA allows for fine-grained autoscaling (including to/from zero) for event-driven Kubernetes workloads. KEDA serves as a Kubernetes Metrics Server and allows users to define autoscaling rules using a dedicated Kubernetes custom resource definition. Most of the time, we scale systems (manually or automatically) using some metrics that get triggered.

For example, if CPU > 60% for 5 minutes, scale our app service out to a second instance. By the time we’ve raised the trigger and completed the scale-out, the burst of traffic/events has passed. KEDA, on the other hand, exposes rich events data like Azure Message Queue length to the horizontal pod auto-scaler so that it can manage the scale-out for us. Once one or more pods have been deployed to meet the event demands, events (or messages) can be consumed directly from the source, which in our example is the Azure Queue.

CONTINUE READING

Azure Security Center – Scan your container images for vulnerabilities

Do you deploy your apps in containers? Do you scan them for security vulnerabilities? No? You should.

Containers are all the rave this year and will continue in the following years; The problem that we’re going to face really soon (honeymoon effect) with the boom of containers is that security is still important even here.

What? Security around containers? “Containers are immutable and secure and don’t have moving parts and…”

Compared to a regular VM, yes containers are much more secure because they have a lower footprint but that doesn’t mean you shouldn’t care about security. You can hack a container as simple as a simple VM. You’re running Apache, NGINX, Node? If you’re running old versions that have vulnerabilities, guess what, they can be exploited 🙂

(more…)
Container security in the Cloud. A state of uncertainty.

Container security in the Cloud. A state of uncertainty.

Thinking that you managed to escape security? Guess again.

In this post, I will focus on containers with Azure Kubernetes in mind but these examples apply to all the worlds out there -EKS, GKE, and on-premises.

Containers gained popularity because they made publishing and updating applications a straightforward process. You can go from build to release very fast with little overhead, whether it’s the cloud or on-premises, but there’s still more to do.

The adoption of containers in recent years has skyrocketed in such a way that we see enterprises in banking, public sector, and health looking into or are already deploying containers. The main difference here would be that these companies have a more extensive list of security requirements and they need to be applied to everything. Containers included.

CONTINUE READING

Privacy Preference Center

    Pin It on Pinterest