devopsy.kinsta.cloud

Category: Infrastructure/Networking

Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

LinkedIn

Apple
San Diego, California
Site Reliability Engineer (SRE) – Video
$115,000 to $217,500

SimplyHired

ScientiaMobile
Reston, Virginia
Senior DevOps Engineer
$110,000 to $150,000

Monster.com

Larsen & Toubro Infotech Ltd.
Farmington, Connecticut
DevOps Engineer
$110,000 to $130,000

Indeed.com

TherapyNotes.com
Remote
Senior DevOps Engineer
$105,000 to $155,000

Dice.com

MRoads
Dallas, Texas
Platform Engineer – SRE
$100,000 to $120,000

February 6, 2023
Microsoft Outage Outrage: Was it BGP or DNS?

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: All of Microsoft’s cloud services go down, everywhere except China. Redmond’s IaaS, PaaS and SaaS—including GitHub—were dead for several hours, and are still running unreliably—despite Microsoft saying it’s fixed the problem. (more…)

January 25, 2023
State of DevOps Report Finds a Rise in Platform Engineering

The speed of software development velocity is increasing, and to enable this, platform engineering is emerging to evolve the DevOps practice. Interest in platform engineering is rising—so much so that Puppet emphasized platform engineering in its 2023 State of DevOps Report.

A whopping 94% of respondents agreed that platform engineering is helping their organizations better realize the benefits of DevOps. The move toward platform engineering has increased over time, bringing benefits such as increased release velocity, reliability and efficiency.

Below, we’ll highlight some of the key takeaways from the report. We’ll define what platform engineering is and highlight its benefits. We’ll also consider obstacles on the path to embracing a platform-based development culture.

Platform Engineering Supplants DevOps

DevOps has been in use for a decade or more at most institutions, maturing steadily with new automation and infrastructure abstraction. The latest evolution of DevOps is a practice known as platform engineering—51% of organizations have already adopted this practice within the last three years and 93% said it’s a step in the right direction.

Platform engineering is the discipline of designing and building self-service capabilities to minimize cognitive load for developers and to enable fast-flow software delivery.

In essence, platform engineering is the process of creating standardized, self-service infrastructure that helps developers get up and running quickly. These self-service platforms typically handle capabilities like deployment (43%), operation of infrastructure (43%), monitoring production applications (42%) and security and compliance (42%).

These shared internal platforms are maintained by a central platform team that embraces a product mindset to iterate the technology based on user feedback.

State of Platform Engineering

Platform engineering is relatively new— 27% of platform teams have formed within the last two to three years. Notably, big tech companies hopped on the bandwagon years ago, and non-tech companies are now following. Regardless, 70% believed their timing was “just right.”

The goals of a platform engineering team are numerous. According to the Puppet report, 54% said problem-solving is the top goal. This is followed by educating and empowering developer teams (47%), setting best practices (46%) and optimizing iteration (44%). A platform engineering team’s scope of work is primarily focused on automating workflows and building and managing infrastructure.

The ‘correct’ number of internal platforms is a moving target. The majority of organizations (57%) have between two and four platforms, and 30% have five or more internal self-service platforms. This demonstrates that although platform engineering is somewhat centralized, it’s also flexible to the needs of an organization.

Benefits and Hurdles

So, what are some benefits as opposed to traditional DevOps? Well, the most common benefit is improved system reliability, at 60%. This tracks, as a standardized platform could reduce human error and missteps in the development workflow. Following this benefit is improving efficiency (59%), speeding up delivery time (58%) and improving workflow and process standards (57%).

The most common driver of adoption is increasing the speed of delivery. Slight more than half of respondents (51%) said development speed has somewhat increased since the inception of the platform team, and 42% say it’s increased by “a great deal.” Other top drivers include the need to scale, free up engineering time, control infrastructure spending and avoid duplication across teams. Those with more mature adoption tend to be more satisfied with the result, indicating that results increased over time.

Of course, no new technological introduction comes without its hurdles, and platform engineering is not immune from certain pain points. For example, 34% said that cycle time is slower than expected. This might be due to nascent industry adoption and a lack of best practices.

Just under one-third (32%) also noticed resistance to platform team adoption, and 32% reported a lack of communication around changes. Organizations will likely have to increase transparency and reduce siloing to encourage productive platform adoption that satisfies the needs of various stakeholders.

According to the report, product management skills can help realize these goals. Some of the most fundamental product management skills here include strong communication skills (61%), problem-solving expertise (60%) and the ability to foster collaboration (54%). Many companies will also have to convince senior management to invest in platform engineering—nearly half agreed that senior management doesn’t yet understand its value.

Future Outlook

Confidence around platform engineering is increasing, especially for teams with mature DevOps approaches. As a result, the practice will likely gain more traction in the coming year—71% of respondents reported their firm plans to hire people with platform engineering experience over the next 12 months.

Over the next year, organizations that adopt the practice will want to increase awareness of platform capabilities and set expectations across the organization. This will also include setting governance policies and satisfying the needs of specific developers, departments and the organization as a whole.

Above, we’ve scratched the surface of the current state of platform engineering, its benefits and its pain points. For plenty of other insights, you can pick up a copy of The State of DevOps Report 2023: Platform Engineering Edition from Puppet by Perforce here.

January 18, 2023
Why Can’t We Be Friends? Improving Developer-Tester Alignment

Sometimes coding can be such an art form that it deserves to be a masterpiece in a museum. Developers are proud of their code—at least until the so-called art critics (aka testers) step in with their critiques. And then the rapport can swiftly become as messy as a painter’s palette. You have probably seen this scenario play out time and again at your organization. In the mad dash of a software release, the relationship between developers and testers can quickly become stressful and strained. And while your teams know about helpful tools that can streamline collaboration, you may not be aware of other steps you can take that go beyond the screen to ensure an even better developer-tester relationship.

Full disclosure: At my organization, we’re in the software testing business and we’re not playing favorites when it comes to testers versus developers. We’ve just learned a thing or two about what makes a happy collaboration for all the parties involved. And we’ve seen that organizations that improved their developer-tester alignment not only accelerate a smoother release cycle but also leave no hard feelings on the table for the next time.

Leave the Keyboard, Take the Cannoli

Developers and testers will find that if they move their interactions away from the keyboard, they’ll discover that sweet spot of improved communication and transparency. Whether at your daily standup, over a cup of coffee or by simply picking up the phone, spending a few minutes chatting can address miscommunications before they become major problems that can delay your release.

If something seems off, bring it up as early as possible. Take, for example, the classic case of missed requirements. One of our customers recently shared a story with us that really hit home. At the top of the sprint, a particular user story included only seven acceptance criteria–which caught the attention of one of the developers. He pointed it out in a conversation with the testers and business analysts on the project. Together, the group identified four additional acceptance criteria missed during the initial scoping.

Without that conversation, the team would have assumed those seven acceptance criteria were the only ones that tests needed to be written against. A number of defects would have slipped into production, and it wouldn’t have been the software developers’ or the testers’ fault. Instead, the testing team realized significant gaps in test coverage and their test plan grew from seven to 40 test cases.

The takeaway? Make sure that developers, testers and business owners are clear on how business requirements align with what software developers plan to build, as well as how testers plan to test against them. Have this conversation before the sprint begins—and don’t forget the cannoli.

You Complete Me: In-App Test Management

“I love documenting test plans in spreadsheets!” said no one, ever. All that manual work just takes time, introduces errors and leads to frustrations among developers and testers who have to go digging for the information they need. Adding a Jira app, for example, for test management can be the key to completing the alignment between teams.

In-app test management gives both teams real-time data for decision-making and collaboration with built-in reporting on testing. That means that software testers can fully plan, design, track, and analyze testing activity within the same workflows that developers and testers are already using. For developers, there’s no need to ask testers for status updates or results. And testers can quickly see how tests align to requirements, which helps them brainstorm additional tests and provides developers better context and information to develop around.

The cherry on top? The entire team can maintain true traceability between requirements and test coverage, which both minimizes finger-pointing and ensures that everyone has a clear picture of what’s required before the release is ready to ship.

There’s an Awful Lot you can Tell About a Person by Their Software

As Mama always said, shoes tell where someone is going and where they’ve been (mic drop, Forrest). By talking the talk and walking the walk in a counterpart’s shoes, developers and testers can better understand each other’s worlds. In-app test management can give developers a window into the tester’s thought process, because it shows them not only test status but also how a tester arrived at a particular defect. After gaining this familiarity, developers may be more open to inviting testers to sit in on traditionally dev-focused activities.

Take unit testing or code reviews, for example. Most QA teams tend to steer clear. But by joining in, testers can ask questions and grasp which pieces will be validated at the unit, integration, and functional levels. A bonus is that testers get an inside look at the codebase, helping them develop more technical knowledge, as well as collaborate with developers on how the unit tests they plan to run–gasp!–fit into the overall picture of quality and release readiness.

Remember, the true purpose of QA is to provide information that verifies that the application works well enough to be put in front of customers. By understanding the testing that’s going on at the unit level, QA can be more efficient by focusing on what’s not being covered in unit tests.

The result? A more cohesive, effective test plan and a release that the whole team–developers, testers and business owners–can be proud of. In other words, a release masterpiece.

January 18, 2023
Devs Increasingly Rely on IaC to Manage Multiple Clouds

A survey of more than 300 DevOps professionals conducted by Firefly, a provider of a platform for automating cloud provisioning, found that more than a third of organizations (36%) have allocated the equivalent of two or more full-time engineers per month to writing infrastructure-as-code (IaC) templates.

A full 82% are also deploying the templates within the context of a DevOps pipeline, with 68% reporting more than half of their cloud instances are now managed using IaC tools, according to the survey. A total of 27% reported they are now managing every aspect of IT as code.

The challenge is that 61% of respondents also admitted they can’t automatically detect configuration drift over time, with more than a third (35%) spending days or weeks remediating IaC templates. Well over half of respondents (56%) said they are also retrofitting existing cloud instances using IaC tools.

Cindy Blake, vice president of marketing for Firefly, said this issue is likely to become more challenging to address as the number of clouds in use continues to increase. The survey found 44% of respondents already use multiple cloud providers. Overall, 42% reported having more than 10 cloud accounts.

The top IaC benefits identified by survey respondents are improved efficiency (75%), increased reliability (55%) and easier compliance (52%) and simpler troubleshooting (49%).

Not surprisingly, the survey identified knowledge (46%) followed closely by complexity (43%) as the top challenges organizations face when using code to manage cloud infrastructure. Factors increasing complexity included cost and complexity (70%), followed by security (61%).

In addition, only 14% of respondents reported that all their engineers are IaC literate. More than a third (36%) said they only have one IaC-literate engineer. As a result, many organizations are now attempting to navigate IaC bottleneck issues that could be alleviated if they relied more on automation that can be integrated within a continuous integration/continuous delivery (CI/CD) platform, noted Blake. She added that many organizations are already allocating too much engineering time to manually writing IaC templates.

Those manual efforts often result in misconfigurations that are easily exploited by cybercriminals, added Blake. Many developers using IaC tools such as Terraform have had little to no cybersecurity training, so the odds they will make a mistake are high.

At a time when more organizations are focused on the productivity of DevOps teams and ensuring the integrity of software supply chains, there is a clear need to automate processes that increasingly span multiple clouds. More organizations than ever are employing multiple clouds to ensure application availability in the wake of a series of outages over the past few years, Blake said.

Regardless of the motivation, multi-cloud computing is here to stay. Developers opt for different clouds based on the performance capabilities they can provide for various classes of workloads. There may be one cloud platform that runs the bulk of the workloads, but the number of organizations that have standardized on a single cloud are comparatively few. The issue is finding the best way to manage multiple clouds that doesn’t require as much manual effort so organizations can reduce the total cost of managing IT environments.

January 11, 2023
Intel Expands Scope of oneAPI Initiative

Intel has expanded its effort to drive adoption of a set of open compilers, libraries, analysis and porting tools and frameworks for artificial intelligence (AI) applications, collectively made available via a oneAPI initiative, to include support for its latest generation of processors.

The oneAPI initiative was launched more than three years ago to create a set of multi-architecture tools for building applications that could be deployed on any CPUs, graphical processor units (GPUs) and field programmable gate arrays (FPGAs). Processors that now support oneAPI include forthcoming 4th Gen Intel Xeon Scalable processors, Intel Xeon CPU Max Series and Intel Data Center GPUs.

James Reinders, chief evangelist of Intel Software Products, said there is now a clear need for open tools and frameworks that provide equal access to multiple classes of processors. As part of that effort, the latest 2023 version of oneAPI, for example, adds support for plug-ins for Nvidia and AMD GPUs developed by Codeplay, a unit of Intel, to simplify writing SYCL code in a way that makes code portable across additional processor architectures.

There is also a CUDA-to-SYCL code migration capability that supports more than 100 CUDA application programming interfaces (APIs) using the Intel DPC++ Compatibility Tool based on an open source SYCLomatic project. Intel is also providing tools to identify imbalances at scale using Intel VTune Profiler, and an Intel Advisor tool now provides automated roofline analysis for Intel Data Center GPU Max Series to identify root causes of memory, cache or compute bottlenecks along with insights for optimizing data transfer costs involving CPU-to-GPU offloading.

As IT continues to evolve, it will become more routine for developers to invoke heterogeneous classes of processors within the same application, but it’s been challenging to convince providers of other types of processors to support the oneAPI initiative, noted Reinders. Processor providers have historically relied on compilers and libraries to lock developers into specific classes of processors.

However, it’s becoming more common for developers to build applications that invoke multiple types of processors. The Intel oneAPI initiative is intended to simplify access to heterogeneous processors, also known as XPUs. That’s critical, because the pace of processor innovation has accelerated to the point where developers need to be able to invoke additional capabilities without waiting for specific compilers and libraries to be updated by multiple providers. Once oneAPI is more widely adopted, it then becomes possible to significantly lower the cost of application development and deployment, noted Reinders.

It’s not clear whether the oneAPI initiative will become more widely adopted, either under the auspices of Intel or by some type of industry consortium that provides a neutral venue for building a common set of compilers and libraries. The one thing that is certain is that DevOps teams are vested in trying to standardize compilers and libraries across as many platforms as possible. The challenge, of course, is making sure developers only invoke compilers and libraries that can span multiple classes of processors versus ones that may have been optimized for a specific type of processor architecture.

January 5, 2023
Best of 2022: SRE Vs. Platform Engineering: What’s the Difference?
As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

Site reliability engineering (SRE) teams and platform engineering teams share similar goals—like maximizing automation and reducing toil—and similar methodologies. But they have different priorities, and use somewhat different tools to achieve them.

What are SREs? What are platform engineers? How is each role similar and different? This article will answer all your questions.

Responsibilities of SREs and Platform Engineers

The main responsibility of site reliability engineers is ensuring that IT systems are reliable, which means that the systems meet performance requirements. Part of their job includes working with developers and IT operations teams to maximize the reliability of applications as they move down the software delivery pipeline.

Meanwhile, platform engineers focus on managing and optimizing the software delivery process. You could think of this role as one that translates DevOps principles into practice by finding ways to implement continuous delivery, continuous improvement and other DevOps priorities.

Thus, both SREs and platform engineers play a role in managing the software delivery process and finding ways to make it as smooth and efficient as possible. They also share a common enemy—toil—in the sense that both groups seek to avoid manual, inefficient processes by automating as much as possible. SREs automate complex incident response operations using tools, for example, while platform engineers might deploy methods like GitOps to automate some aspects of software delivery.

Differences Between SRE and Platform Engineering

That said, SRE and platform engineering are distinct roles. The key differences boil down to:
- Goals: The main job of SREs is maximizing reliability, which is different from optimizing the speed and efficiency of software delivery operations. Theoretically, you could have a highly reliable system even if your software delivery chain is manual and slow.
- Scope of role: Software delivery operations are the main focus of platform engineers. SREs care about software delivery, too, because the way applications are created plays a role in reliability and fixing issues. But SREs also have many other responsibilities, like incident response and helping to manage infrastructure, which fall beyond the scope of software delivery.
- Tools: SREs rely on tools that help them discover and solve various types of reliability issues. In contrast, platform engineers leverage tools like source code managers and continuous integration (CI) servers to help automate software delivery.
So, although SREs and platform engineers may use similar methodologies and possess similar skills, their day-to-day operations tend to look quite different.

Should You Pursue an SRE or Platform Engineer Career?

Given the skills overlap between SRE and platform engineering, some engineers are a good fit for either role. But which one is better, from a career perspective?

Salary-wise, there’s not a whole lot of difference. Glassdoor pegs the average salary of platform engineers at about $115,000 compared to $127,000 for SREs. SREs may earn a little more (and it’s worth noting that SRE salaries can vary widely), but the difference in pay is not as great as that between, say, IT operations engineers (who make a mere $77,000, according to Glassdoor) and SREs.

The roles are also similar in terms of demand. Unlike software engineering or even DevOps engineering, SRE and platform engineering are both roles that have begun to become popular only in recent years. SRE as a concept has been around for a while—it originated at Google in the early 2000s—but it wasn’t until recently that most companies began seeking SREs for their teams. Likewise, platform engineering didn’t become a thing until the advent of microservices and cloud-native everything pushed companies to devote more engineering resources to manage their increasingly complex software delivery processes.

What this means is that, at least for now, it’s easy to find jobs in SRE and platform engineering as long as you have the right skills. Many companies are eager to hire for both types of roles.

Choosing the role that is right for you, then, depends mostly on your preferences and how you like to work. The life of a platform engineer is likely to be somewhat more predictable than that of an SRE because platform engineers don’t have to take the lead in managing incidents when something breaks at 2:00 a.m. On the other hand, SREs enjoy a more diverse set of responsibilities, which can make the job more exciting—especially if software delivery tools like Git or Jenkins don’t make you excited to get out of bed in the morning.

Conclusion

Platform engineers and SREs play central roles in automating complex processes and eliminating toil. But they tackle these issues from different angles and they use different tools. The right role for you depends on what you enjoy doing most.
December 22, 2022
Opvizor Extends Monitoring Reach to the Cloud

Opvizor, a unit of Codenotary, has extended its monitoring capabilities to cloud computing environments starting with support for Amazon Web Services (AWS) and Microsoft Azure.

Codenotary CTO Dennis Zimmer said Opvizor aggregates data to provide a more efficient approach to applying analytics to surface performance and risk issues.

Previously, Opvizor was optimized for instances of VMware vSphere running in an on-premises IT environment. Now the unit of Codenotary, a provider of a service for generating software bills of materials (SBOMs), is extending those monitoring capabilities to the cloud.

That transition comes as many organizations are looking to strike a balance between monitoring pre-defined metrics and observability platforms that make it possible to surface unknown potential issues that could adversely affect IT environments.
It’s still early days as far as observability is concerned, so Opvizor is focused on meeting most IT teams where they are today as they further embrace cloud computing, said Zimmer.

Observability, in general, promises to query not just logs and metrics but also distributed traces that are applied to specific processes. In that way, observability allows organizations to detect patterns that have not been predefined. In effect, an observability platform makes it simpler to debug application environments where the number of dependencies that exist between services are becoming too complex to track manually, much less decipher. Without the aid of an observability platform it can take weeks to discover the exact cause of an application’s performance degradation.

Of course, those applications will need to be instrumented using agent software capable of generating the data observability platforms require. Fortunately, open source projects such as OpenTelemetry are helping to drive down the total cost of instrumentation.

However, in the absence of observability, most IT teams will rely on existing monitoring tools. Opvizor is making a case for centralizing monitoring across multiple platforms to reduce costs, noted Zimmer.

Heading into 2023, each IT team will need to decide how and when to rely on traditional monitoring tools versus observability platforms. Many observability platform providers are justifying the acquisition of a new platform based on cost and the ability to eliminate the need for multiple monitoring tools. However, it remains to be seen whether IT organizations will prefer to employ both monitoring tools to track predefined metrics alongside observability platforms.

Regardless of approach, the reality is that IT environments are becoming more complex to manage. In addition to running workloads in multiple cloud platforms and on-premises IT environments, organizations are deploying emerging cloud-native applications based on containers alongside existing monolithic applications deployed on legacy virtual machines. As workloads are deployed on multiple platforms, the total cost of IT starts to rise. One way to contain those costs is to standardize on a set of tools that can be applied to multiple platforms.

The pressure to rationalize toolsets only increases during any period of economic uncertainty. The challenge, of course, is convincing one team to give up their preferred tool in favor of another to reduce costs.

December 20, 2022
EU Data Privacy: Try Again | SkyPilot: Choose Cheapest Cloud | WFH: Better Meetings

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: EU-U.S. Data Privacy Framework reemerges, Berkeley brings cloud selection box, and proof that remote work is good work. (more…)

December 15, 2022
5 Tips to Consider When Introducing Infrastructure Automation

Although we discuss infrastructure automation often, the fact is that a lot of manual processes still exist throughout DevOps. Whether it’s rewriting scripts to spin up new servers, updating cloud-native policies or configuring computing environments, manual toil is an all-too-common reality. To make matters worse, engineers commonly create lengthy scripts that work in isolation but are too bulky to be reusable by other developers working with slightly different constraints.

More infrastructure automation is the key to increasing deployment agility, but setting aside time to automate your daily workflow can easily take a back burner, especially when developers are already behind on their long list of to-dos. So, for the time-pressed, where should they start? What exactly should be automated? And how can we effectively reuse and share automation to help other areas of the business?

I recently connected with John Laffey, technical product marketing director, Puppet. Laffey has thirty years’ worth of tech support and engineering operations knowledge under his belt and was “doing DevOps before it was called DevOps.” He shared with me five helpful tips to think about when introducing more infrastructure automation into your workflows. Below, we’ll expand on each of those points and consider other best practices around automation as the industry moves toward platform engineering.

1. Automate Things That Interrupt Your Day

First, Laffey recommended starting with the things that are easy to fix. These are the tedious actions that interrupt your day. Perhaps a disk runs out of space and troubleshooting takes 15 or 20 minutes. Minor interruptions like this might seem like part of the job, but they definitely add up over time.

2. Automate Things You Can Reuse

Secondly, try not to automate things for an ultra-specific purpose, said Laffey. Instead, focus on building automation that is more generic and can have more value to others. This follows the DevOps mantra of teamwork and collaboration. One-off automation that is too verbose or specific to a certain condition won’t apply well across groups.

3. Automate Stuff That Doesn’t Change Much

Next, automate the infrastructure that isn’t prone to change. These are fairly reliable things that you’re sure will be part of your systems for the foreseeable future. Because if a component does end up having to be updated often, supporting the automation could be more hassle than it’s worth. “Don’t trade fixing problems for fixing automation,” said Laffey.

4. Start Small

Here’s some sage advice applicable to most new projects with a big scope—start small. Laffey recommended starting by automating the easy stuff that has proven immediate value. These tasks should be modular and do one specific thing, like rebooting a machine or draining a log file. “Automate things in chunks that you can put into a toolchain.”

Too often, teams try to automate everything all at once. But by taking big bites, you can quickly get off track and potentially add to technical debt. If you keep things modular, you’ll find it easier to change and reuse this automation.

5. Share and Be Open

This last tidbit is more of a cultural change—don’t code so that you’re the only one who knows about it! Sometimes, engineers don’t necessarily want the world to know about the automation they create. They might worry about automating their job away. Yet, Laffey said, these worries are misplaced. There will always be more work to do, and automating toil away can free up time to help you focus on more exciting projects.

So, Laffey encouraged DevOps and SREs to be open about the automation they create. Ensure they’re well documented and stored in a centralized repository to allow other departments to reuse your code. This can avoid the duplication of having five different versions of the same script written in different languages within the same organization!

Next Step: Move From Scripts to Industry-Standard Tooling

It can be challenging to argue for investing time and energy into infrastructure automation, especially when engineers are hard-pressed to keep the lights on. Yet, small gains in automation can make huge waves in the long term.

Eventually, said Laffey, you’ll want to move away from using scripts within your toolchain, which he describes as a low-end DevOps maturity. But as you update your process, you’ll want to replace these scripts with more modern industry-standard tools like Terraform or Puppet’s DSL. He recommended slowly revamping scripts in a toolchain as you update them one by one. “Start where you are and avoid a monolithic approach.”

In essence, platform engineering, Laffey explained, is wrapping DevOps principles at a higher level to make them more efficient. And we will likely see an increased emphasis on infrastructure automation as platform engineering gains more mindshare. “It’s going to become a necessity.”

December 12, 2022