Threat vulnerability management, and managing your attack surface, are critical in the battle against cyberattacks. At some point before an successful attack, the internal process to manage threats and prevent access to sensitive data failed. How could they have done things differently? Were they just managing too much, too often, without the resources they needed?

The definition of a platform engineer can be slippery. Ask several IT professionals “What does a platform engineer do?” and you might get several different answers. One platform engineer might be at the intersection of DevOps, AppSec, architecture, and SRE, while another might broadly support infrastructure for all developers in their organization. (Sometimes, in less successful teams, they’re essentially a DevOps engineer with a fancy title.)

Migrating to the cloud, in whole or in part, can be tempting for organizations of all sizes. The cloud offers agility, potential cost savings, and scalability — all without a commitment to physical devices. But what about the risk? Migrating to the cloud can be a complicated undertaking with the potential for missteps and hidden expenses. You’ll need to take a careful look at why you want to migrate to the cloud, as well as do the work researching cloud vendors and migration approaches.

Welcome to Day 1 of the software development life cycle — what now? We’ve already covered Day 0 server provisioning, and you should be ready to start writing code that will support your DevOps initiatives and make your life easier …or are you? Put some of our wisdom and experience at work for Day 1 of the software life cycle, and make sure you’re fully prepared to handle common pitfalls and problems that can become ongoing issues for Day 2.

Bad news: Configuration drift is going to happen no matter what you do. It’s very easy to miss, caused by some innocuous mistake or patch and buried in paper trails that don’t exist. By the time you’ve found which configurations have drifted, it usually means something’s already going wrong. But here’s the good news: You and your precious configurations don’t have to take it lying down.

What is continuous delivery? And what are the benefits of the continuous delivery pipeline? This strategy has evolved in a world where platform engineering is on the rise and more and more organizations rely on automation through code to achieve their goals. Times have changed. Most organizations now rely on continuous delivery as an essential part of their development pipelines.

You’re scaling your IT infrastructure so you can do more – deploying across clouds and data center, adding servers, coding like crazy. Great! But how do you keep it all from falling apart? Policy as code is an approach to managing IT that strategically leverages infrastructure as code (IaC) and compliance as code to manage consistent policies across complex IT environments. Sounds perfect, right?

Let’s take a deeper dive into Day 0 configuration for server provisioning — it’s the foundational step for making sure your goals are met and you are set up for future success on Day 1 and 2.

Since its passing in 2002, the Sarbanes-Oxley Act (SOX) has become one of the leading regulatory compliance requirements for U.S. companies. It’s synonymous with corporate governance and financial reporting standards for publicly traded companies. Companies spend millions of dollars and thousands of hours ensuring SOX compliance. Scrutiny is high for organizations subject to it, and the penalties can be crushing.

IT ops is often so focused on solving problems that it can be easy to miss how IT ops contributes to an organization’s overall success, even if you’ve been in IT for a long time. When things get tossed over the wall from development to ops, anyone not in IT ops starts to ask, “What is IT ops?” and “What does IT operations do?” So let’s set the record straight.