DevOps — the marriage of the development and operations departments within a software organization — and Agile methodology have been mentioned alongside cloud computing for years now, and with good reason. Using Agile in the cloud is a classic pairing that goes together like peanut butter and jelly or macaroni and cheese…okay, let me go grab a snack before this simile gets me drooling.
But seriously, even if Agile and cloud technology aren’t as tasty as PB&J, they can still have you smacking your lips in satisfaction as you react to business problems with technology solutions in a much faster and more reliable manner.
Here’s why Agile software development practices work so well when you’re working with cloud infrastructure, even if you aren’t a software development company.
As you transition towards CloudOps, DevOps, DevSecOps, and general continual iteration and continuous improvement type IT management strategies, there are a number of common mistakes you’ll want to avoid.
DevOps at all costs is not going to provide any additional business value. Nor is it likely to be great for your IT team morale. Make sure you keep in mind these three common DevOps pitfalls as you evangelize and adopt DevOps practices throughout your IT department or larger organization.
It is generally understood, with broad industry concurrence, that an InfoSec skills gap exists and presents a significant challenge for those of us responsible for managing risk within an organization. To close the skills gap, an organization must first understand the competencies required by security teams in their pursuit of information technology risk management.
Information security consists of three core archetypes: builders, breakers, and defenders. It is through recruiting and building the skills of these archetypes that the foundations of highly functional security teams are formed.
When using Microsoft technologies in your enterprise IT stack, you have a few native options for systems monitoring and alerts. Two recent product developments — folding Operations Management Suite (OMS) functionality into Azure Monitor, as well as the release of the new SCOM 2019 — have reignited the debate to determine whether Azure Monitor can entirely replace the long standing, good-old SCOM (System Center Operations Manager).
In a way, I feel this comparison is a bit unfair, like comparing apples with oranges. Ultimately the two products can work together and overlap in order to eliminate monitoring gaps in your environment. So which monitoring solution would work the best for your enterprise? Let’s try to figure out!
When you enter data into Beekeeper Patching Automation, you use the UI to add servers groups, Windows Failover Clusters, and Exchange DAGs. Then, you assign validation tasks to these server groups or clusters. To create the execution job, you assign the server groups or clusters to a schedule. This can be time consuming.
I have created PowerShell scripts to do these tasks. In a series of blog posts, I will share these PowerShell scripts and go over their usage.
The first PowerShell script will export servers from an SCCM collection into a CSV. Then another script will import that CSV to create the appropriate Application groups, Windows Failover Clusters, or Exchange DAGs.
Whatever your cloud or virtualization platform of choice, you can implement tags on your resources in order to easily apply configuration changes or search by group.
As multi-cloud environments continue to become more and more popular and your virtual servers, storage, and associated components sprawl across various providers, efficient governance becomes even more critical.
By implementing a cloud resource tagging policy, you lay the groundwork to consistently apply automated or manual actions relating to allocation, reporting, chargeback, compliance, security, patching, software installation, and even decommissioning or scaling resources when required.
Alert Rules in Azure are a tool to let you know when some condition of your choice has occurred within any given component of your Azure infrastructure. In other words, they alert you to potential problems so you can remedy them before anything serious goes wrong.
Have you ever had the tedious task of creating multiple alerts for all of the resources in your subscription? Let me tell you, it is really time consuming to create them from scratch one by one.
I have a PowerShell Script that can Target and Create specific metric alerts for the resources you define inside of the script, making it much simpler to create a large amount of alerts at one time.
Skip down to the script if you’re familiar with Alerts already. If you aren’t here’s an overview on how they work.
One key concept to master when dealing with cloud, containerized, or otherwise software-defined infrastructure is Infrastructure as Code. This may seem strange at first. After all, your code runs on top of infrastructure, right?
Infrastructure as code (IaC) works in practice by managing your computing resources — virtual machines, storage, networking, and all the associated policies for security and such — in the same manner as you treat your code. This packages everything necessary for your application, from the code and assets to the underlying infrastructure itself, together into what works functionally as a single deployment.
Just as DevOps combined development and operations into one entity, IaC combines code and infrastructure as one.
Many customers frequently ask the question whether or not it is possible to fetch a report of up-time of a service being monitored with SCOM. Usually, the answer is – not out of the box. However, you can achieve this using a simple workaround.
One way of doing it is to author your own service monitor, but that involves considerable amount of knowledge and experience of management packs and the underlying coding. It usually takes a lot of time as well. Not everyone has the right knowledge or the time to spend on this so I thought I’d share a quick trick I do to measure uptime of a service and also be able to present it to the concerned parties in the form of a report.
Sometimes you want to trigger a specific action when something is detected by one of your alert rules inside of Azure. If you want to immediately remediate the specific issue you are facing normally you would have to login to the machine once you receive the alert, but by using an Azure Automation account you don’t have to take any additional steps to fix whatever threw the alert — just create your script and leave it to run whenever the alert is triggered. As simple as that.
This works perfectly when you need to resolve a common issue with a trusty PowerShell script that you have often used. This method will save you time and effort; you can rest assured that the issue is being taken care of with the help of a Custom Script Extension.
Running a custom script on a specific machine when an alert is triggered in Log Analytics is quite easy. Here are the following steps you need to follow to achieve this.