Microsoft Azure is the public cloud computing platform by Microsoft which offers software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS). It comprises more than 600 cloud services and supports varied operating systems, databases, and developer tools. And, even better, Splunk On-Call integrates with Microsoft Azure to help on-call teams improve incident response for Azure-based environments.
DevOps-oriented engineers live at the intersection of IT operations and software development – understanding much of what it takes to maintain IT infrastructure while also being able to write code and deploy new services. DevOps-minded teams not only create services – but they also maintain them. A DevOps structure forces teams to take accountability for their applications and infrastructure instead of allowing developers to throw code over the proverbial wall to IT operations.
Continuous integration (CI) makes the cycle from design to code to building artifacts seamless and consistent. Continuous delivery (CD) makes delivery of that artifact to an environment the same every time. But, what about the actual environment the artifact is running in? Is it the same every time? That’s a hard thing to guarantee — unless you take advantage of an Infrastructure-as-Code (IaC) approach. This post explains how to use Infrastructure-as-Code to improve CI/CD.
Because DevOps practices can bring great speed and reliability to the software delivery lifecycle, release management can seem daunting. But, the improved visibility and collaboration brought about by DevOps can also help with the release management process. While the general concept of release management doesn’t really change between ITIL (IT Infrastructure Library) and DevOps, there are a few ways that the process differs.
Over the past few years, cloud computing has enabled agile, dynamic management of software and hardware components, on-demand. Nowadays, we can define our desired infrastructure in as little as a few lines of code, and we can provision real servers on cloud providers like AWS or Azure. Terraform is an open-source infrastructure-as-code (IaC) tool that has become the de facto solution for provisioning one aspect of those components.
With cloud computing, containers, virtualization and the move to software-defined infrastructure, your cloud infrastructure monitoring is consistently evolving. New challenges can impact the reliability of business services where network performance is a significant subset. Your network is filled with a multitude of hosts, distributed services, and containers. It’s hard to monitor the health of these ephemeral cloud infrastructure components. How is their behavior affecting your applications?
We’ve had a busy week in the Splunk Partnerverse! In addition to the new Splunk Partnerverse Program announced last week, we also shared some significant partnership news with one of our longest-standing partners, Accenture.
For you, one or more of these statements (and / or challenges) likely apply to you, and the organization for which you work. Which of these are you hearing or saying? Splunk can help you with these in many ways. Today, I am highlighting one way to address many of these statements, specifically with the Content Pack for Splunk Observability Cloud.
With the demand to meet service level agreements (SLAs), any on-call SRE can tell you that incidents always happen at the wrong time. Things break when you least expect them to (on a date, about to beat a new level in a video game, pizza delivery just arrived, asleep at 3am). During these inopportune moments, you want to make sure it's easy to get the data you need, no matter which device is nearby.
As the world increasingly works, buys, and communicates through native mobile apps. In 2020 there were 218 billion new app installs globally, 13.4 billion from the US alone. The challenge, while iOS and Android applications make up significant portions of user traffic and business, engineering teams and monitoring tools are split between mobile app and backend developers; this creates siloed visibility on how changes to the app or backend components impact each other, and end user experience.
