devopsy.kinsta.cloud

Tag: Puppet

  • Survey Surfaces Substantial Platform Engineering Gains

    Survey Surfaces Substantial Platform Engineering Gains

    A global survey of 500 application development and deployment professionals finds that while 43% work for organizations that have had a platform team in place for three to five years, there doesn’t appear to be much consistency regarding where that team reports within an organization.

    The survey, conducted by Puppet by Perforce, a provider of an automation framework, found that among organizations that have platform teams, well over half (58%) operate within the context of a larger DevOps or infrastructure management organization, compared to 40% that have their own dedicated leadership.

    David Sandilands, a principal solutions architect for Puppet by Perforce, said the survey makes it clear that platform engineering, in general, is not a new concept, but it’s clear more organizations are trying to reduce the level of toil currently associated with building and deploying applications.

    Regardless of where platform teams reside in an organization, nearly two-thirds of respondents (65%) said they are important to their organizations and would receive continued funding. The primary purpose for forming these teams is to increase productivity (58%) and automate standardized processes (51%), the survey finds. Top goals for platform engineering teams are to solve problems (30%), enforce security processes (27%) and accelerate transitions to cloud-native computing environments (26%). A full 70% said security was built into their platforms from the start.

    That suggests that, in addition to assuming responsibility for traditional DevOps workflows, many platform teams are now also being asked to ensure DevSecOps best practices are followed at a time when application security requirements are becoming more stringent, noted Sandilands.

    More than three quarters (76%) also reported that they had deployed two or more self-service portals, with 27% having deployed five or more.

    Only 22%, however, said they have deployed applications on Kubernetes in a production environment, with just under half (46%) reporting they have no current plans to deploy a cloud-native computing platform, which are widely seen to be challenging to deploy and maintain.

    Overall, the survey makes it clear the primary focus is to ensure platforms continue to evolve as developer requirements continue to evolve, said Sandilands. Platform teams are not necessarily trying to dictate what tools should be used; instead, they are finding ways to automate processes that are increasing the level of friction developers encounter, he added.

    In the longer term, advances in artificial intelligence (AI) will make it simpler to achieve that goal using natural language interfaces that DevOps teams can more easily invoke, noted Sandilands.

    Each organization will need to decide for itself whether platform engineering makes sense as a methodology for managing DevOps at scale, but as application development and deployment continues to evolve, more nuanced approaches will be required. In general, organizations are trying to strike a balance between empowering developers and the need to streamline backend processes to increase productivity while also simplifying compliance and improving security.

    The challenge, of course, is enticing developers to buy into that concept rather than using their expertise to resist platform teams that might, from their perspective, limit their prerogatives in ways that ultimately stifle innovation.

  • Internal Developer Platform (IDP) Reference Architectures

    Internal Developer Platform (IDP) Reference Architectures

    If you’ve been following the DevOps space recently, you’ve probably noticed the excitement brewing around platform engineering. Despite uncertainty in other areas of tech, it seems like platform engineering is poised for growth—Gartner even expects that by 2026, 80% of software engineering organizations will have established platform teams.

    The platform engineering idea hinges on an internal tooling system known as an internal developer platform (IDP), which platform teams own and operate and is exposed to developers to improve their efficiency, satisfaction and release fluidity. IDPs have been the talk of the town. But what does an IDP actually look like? What sort of components are they usually composed of?

    Well, at PlatformCon 2023, McKinsey representatives shared a reference architecture for building out IDPs. This framework was modeled after hundreds of internal platforms and could be a helpful benchmark for other organizations as they begin developing and standardizing their internal developer platforms.

    Below, we’ll examine the sample IDP reference architecture and its components. We’ll also have a refresher on the platform engineering concept and offer some expert tips on overcoming potential obstacles while implementing platform engineering and IDPs.

    Why Engineer Internal Platforms, Why Now?

    First, for those new to the idea, let’s explain what platform engineering is. I’ve previously defined platform engineering as “maintaining an internal self-service platform that serves the needs of developer consumers.” The practice doesn’t necessarily supplant DevOps, rather, the experts I’ve spoken to view it as the next evolution.

    This trend is essentially a response to developers overseeing more and more aspects of software life cycle management. Complexity in enterprise-level software delivery workflows has escalated in the last decade, leading to what The State of Platform Engineering Report describes as “increased cognitive load on engineers.” This is negative, as it could lead to shadow operations and burnout.

    The fact is, most developers require the same sort of technologies, which could be standardized across the board. For instance, take the consolidation around containers and Kubernetes, infrastructure-as-code and the need to implement similar build configurations and security policies across applications.

    By outsourcing the maintenance of tools for shipping and running cloud-native applications to a common platform, you take the burden off developers and free them up to code. Also, by centralizing DevOps tooling, you can enforce more governance and build out internal standards. Which should help reusability and overall deployment agility … at least, that’s the promise of it all. 😉

    Sample IDP Reference Architectures

    So, let’s turn to some real-world examples to see how this is being implemented. Mike Gatto, senior DevOps engineer, McKinsey, shared an internal platform reference architecture for AWS-specific environments:

    McKinsey’s Internal Developer Platform reference architecture

    As you can see, the architecture is divided into these subgroups. At a high level, they perform the following functions:

    • Developer control plane: This is the version control, where developers publish their code. They provide a workload specification (in McKinsey’s case, a Score file) that codifies specific configurations.
    • Integration and delivery: This includes the CI pipeline to build application code into a container and publish it to a registry. This notifies the platform orchestrator to initiate a build. Then, resources are provisioned. This area also includes a CD pipeline and infrastructure control plane.
    • Monitoring and logging: This plane includes tools for observability, analytics, and application performance monitoring.
    • Security plane: This area includes tools for secrets management, policies, and security vetting.
    • Resource plane: This plane encompasses cluster management, database tools, networking, and messaging architectures.

    “By separating developer and platform team concerns and allowing them to control the respective areas they’re experienced in separately, without requiring too much overlap,” said Gatto, “we’re making deployments more compliant and better aligned with client initiatives.”

    Humanitec has also created internal developer platform reference architectures for GCP and Azure, displayed below.

    IDP Reference Architecture for GCP
    IDP Reference Architecture for Azure

    PlatformEngineering.org has also expanded McKinsey’s original IDP reference architecture with a tooling landscape that adopts the same umbrella subgroupings but includes other pluggable tools.

    The Internal Developer Platform tooling landscape

    Roadblocks to Developer Platforms

    Starting from a blueprint could be a big help to rapidly construct IDPs. Yet, there will still be some potential roadblocks associated with adopting an internal developer experience platform. One of them is creating common platforms that actually cater well to all environments.

    “You can not and should not try to please everybody,” said Kaspar von Grünberg, CEO and co-founder of Humanitech. “Platform engineering is an 80/20 game.”

    “Platform organizations often face a lot of pressure when it comes to meeting demands for building more services that are both agile and agnostic to cloud and data center environments,” said Venkat Ramakrishnan, VP, product management and engineering, Portworx by Pure Storage. “At the same time, almost all platform engineering teams are understaffed while facing the need to support large application development initiatives and developer teams twice their size.”

    Tips to Get Platform Engineering On Track

    Reference architectures for various clouds could help cater IDPs to different scenarios. But outside of that, it will take a product mindset approach to strategically accept feedback and iterate the platform. This will involve doubling down on developer experience and adopting cloud-native foundations that can scale.

    “Platform engineering teams must consider adopting Kubernetes as it enables them to manage and deploy applications in production at scale, without having to manage applications at the individual level,” added Ramakrishnan. “Additionally, it may not be realistic to expand platform engineering teams alongside growing platforms, so teams should also consider leveraging automation and self-service capabilities to help them better manage projects at scale.”

    Is ‘You Build It, You Run It’ Dead?

    The idea of ‘you build it, you run it’ is starting to look a little antiquated next to the new and shiny platform model. It’s tough to say, but I’ll be keeping an eye on this area to see if all the effort to standardize the internal engineering approach pays off!

  • State of DevOps Report Finds a Rise in Platform Engineering

    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.

  • Russian Dev Exodus | Puppet IPO FAIL | Intel 18A Ahead of Sched.

    Russian Dev Exodus | Puppet IPO FAIL | Intel 18A Ahead of Sched.

    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: More than 100,000 tech workers leave Russia, Perforce buys Puppet, and Intel moves faster than planned. (more…)

  • Puppet Survey Suggests DevOps Adoption is Stagnant

    Puppet Survey Suggests DevOps Adoption is Stagnant

    Puppet today published an annual State of DevOps report that suggests overall adoption of DevOps practices has stagnated.

    The survey of 2,650 IT, development and information security professionals finds 83% are implementing DevOps practices, to a degree. However, only 18% of respondents are working for organizations that have highly evolved, automated DevOps processes in place. More than three-quarters of respondents (78%) are somewhere along the path toward achieving that goal.

    A full 90% of highly evolved DevOps teams have automated most repetitive tasks compared to only 67% of mid-level organizations, the survey found. In addition, 91% of highly evolved teams report a clear understanding of their responsibilities.

    Not surprisingly, the biggest hurdles identified are more cultural than technical. The most common culture blockers at mid-level organizations include a culture that discourages risk (21%), unclear responsibilities (20%), deprioritizing fast flow optimization (18%) and insufficient feedback loops (17%). In contrast, less than 2% of highly evolved organizations report resistance to DevOps from the executive level, the Puppet report found.

    Nigel Kersten, a field CTO at Puppet, said during an online panel that, after more than a decade of DevOps advocacy, people continue to be the biggest limiting factor when it comes to adoption. Specifically, from a compensation perspective, many IT operations personnel tend to feel undervalued compared to developers, noted Kersten.

    Another challenge enterprises encounter is trying to balance the need to create a standardized IT environment that can be managed and secured consistently and the desire of DevOps teams to embrace new tools as they see fit. Senior IT executives often tend to make platform decisions based on cost criteria that don’t always account for the need to enable agile development methodologies. Most of those platforms are designed to be managed by an IT administrator using a graphical tool rather than via a command line interface (CLI) and application programming interfaces (APIs) that appeal to DevOps teams.

    As a result, individual pockets of DevOps teams that select and maintain a platform of their choosing are emerging within enterprise IT organizations. Those teams often view their chosen platform as a better alternative for advancing developer productivity. Finding and retaining site reliability engineers (SREs), for example, to manage those DevOps platforms is a major challenge for most enterprise IT organizations. Most IT administrators lack the programming skills needed to become an SRE, and it’s not clear how many IT administers are inclined to acquire those skills.

    Conversely, it’s not clear how many programmers want to programmatically manage IT infrastructure at the expense of time they would otherwise devote to writing code. Organizations that can only hire a limited number of developers may not want to shift responsibility for managing IT operations to the proverbial left simply because they need more code to be written faster. Finding and retaining developers, in many cases, is just as much a challenge as hiring and retaining SREs.

    Advances in automation and artificial intelligence (AI) should make it easier for organizations to embrace DevOps best practices in the months and years ahead. However, it should be apparent to all that adoption of those best practices across an entire enterprise still requires a significant amount of time and effort, and will for many years to come.

  • Despite the Pandemic, DevOps Salaries Rose in 2020

    Despite the Pandemic, DevOps Salaries Rose in 2020

    Puppet today published the results of an annual global DevOps survey that found, despite the downturn in the global economy brought on by the COVID-19 pandemic, most DevOps professionals saw their salaries rise in 2020.

    However, for the first time since Puppet started collecting this data, DevOps professionals working in the life sciences, health care and pharmaceutical sectors, on average, made more than those working in the financial services sector. Not surprisingly, the report also found that DevOps professionals working in the U.S. made more than their global counterparts.

    Nearly two-thirds of respondents in the life sciences, health care and pharmaceutical sectors earn more than $100,000. That compares to 53% in the financial services sector and 45% of those working for technology companies.

    The survey was based on responses from 2,243 DevOps professionals, and noted that organizations with highly evolved DevOps practices pay better than those that are less evolved. Among respondents working at highly evolved companies, 80% earn $75,000 per year or more. That compares to 57% that earn as much at less evolved companies. Much of that discrepancy is attributable to DevOps managers that make much more at highly evolved companies compared to their counterparts at less-evolved companies, the report noted. Two‑thirds of practitioners make less than $100,000 per year, the survey found. In general, respondents working at companies with revenue over $1 billion had the highest percentage of those earning $150,000 to $250,000 (22%).

    The largest percentage increases in salaries among DevOps professionals occurred in Japan and the United Kingdom (UK). Salaries, on average, did not rise in Singapore, Germany, New Zealand and Australia. In the U.S., the demographic that saw the most growth was among DevOps professionals earning between $150,000 to $250,000, most of whom are managers. More than half of all DevOps managers in the U.S. fall within this salary range, the report noted.

    The Puppet report also noted that DevOps professionals working in dedicated engineering and application development tend to make more than those that are part of a larger IT team. A third of respondents in engineering or development report salaries over $125,000 per year, compared to 22% percent in IT and 15% percent in information security.

    The Puppet report also showed a divergence between what men and women earn as salary ranges increase. For both men and women earning up to $75,000 a year, salaries are similar. Between $100,000 and $125,000, women actually earn more. However, at $125,000, men (28%) earn more than women (17%). The survey, however, does not mention the experience levels of any respondents.

    It’s also not clear whether the higher salaries among DevOps professionals found in the life sciences, health care and pharmaceutical sectors represent a fundamental shift, or is an aberration based on the amount of COVID-19 research being conducted.

    Alanna Brown, a senior director of marketing for Puppet, said the one thing that COVID-19 has changed forever is that competition for DevOps expertise is now global. Organizations are no longer limiting themselves to hiring individuals within 50 miles of their office. In fact, DevOps professionals that have shown they can successfully work remotely will, in the months and years ahead, be in greater demand than those that have only worked in an office setting, Brown predicted. Organizations of all sizes are trying to reduce their commercial real estate expenses, Brown added.

    In the meantime, the most important thing for IT professionals is to stay relevant. Site reliability engineers (SREs) with certified programming skills will make more than a traditional IT administrator. It’s up to each IT professional to make sure they have the skills that are highest in demand at a time when many IT functions are being ruthless automated by increasing numbers of DevOps professionals.

  • Puppet Adds DevOps Consulting Practice

    Puppet Adds DevOps Consulting Practice

    Puppet has launched a DevOps consulting service that promises to help organizations implement best practices that will ultimately make their IT organizations more efficient.

    Nigel Kersten, field CTO, Puppet, said the Scaling DevOps Service is especially focused on improving workflows among organizations that have already started down the DevOps path.

    Most IT organizations that embrace DevOps eventually encounter bottlenecks that conspire to limit the rate at which they can build and deploy applications. Puppet will make available DevOps experts capable of assessing DevOps workflows as part of an effort to reduce operational friction, said Kersten.

    Those consultants can also identify integration opportunities that might further streamline workflows, in addition to providing an overall assessment of an organization’s DevOps maturity based on a model Puppet developed.

    Kersten said in many cases, enterprise IT organizations, especially, are trying to adapt DevOps principles that were originally created for small startup companies, with mixed success. Puppet consultants, using observations gleaned from their own engagements with customers that have embraced its tools for automating the management of IT, are often in a better position to identify ways to optimize DevOps workflows across larger IT organizations, Kersten said.

    It’s also easy for large enterprise IT organizations to misinterpret how one DevOps principle or another should actually be implemented, Kersten said.

    DevOps consulting, of course, has become a cottage industry within the IT services sector over the last decade. Now, almost every systems integrator has a DevOps practice. Most of those practices are focused on enabling organizations to embrace DevOps, versus helping organizations optimize workflows after they have already begun the transition, said Kersten.

    It’s not clear to what degree organizations that have not embraced Puppet’s automation framework will embrace consulting services based on a DevOps model created by observing Puppet’s customers. However, it’s apparent many IT organizations have inconsistently implemented DevOps practices across various departments. In many cases, bottlenecks that result in various departments within a larger IT organization are being addressed using a set of manual processes that have been created as a workaround to a specific problem.

    Of course, optimizing DevSecOps best processes is only going to become more challenging as emergent technologies such as containers, Kubernetes clusters and serverless computing frameworks are added to the IT mix. More challenging still, many organizations are now trying to shift responsibility for security further left as part of a DevSecOps workflow.

    Many IT teams are, naturally, resistant to paying for advice, while others routinely hire small armies of consultants in the hope that ideas and concepts that have worked well elsewhere can make their IT teams more efficient. Regardless of the approach pursued, IT leaders need to remember that DevOps is a continuous journey. Every time a new platform is added to an IT environment, a DevOps workflow will need to evolve. The real issue IT leaders need to come to terms with is how long it will take for their internal teams to adapt, whether it’s via the school of hard knocks or relying on external expertise that has handled most of the issues an internal IT team is likely to encounter.

  • Puppet Enters Compliance Partnership with Center for Internet Security (CIS)

    Puppet doubles down on compliance with new relationship

    PORTLAND, Ore., Aug. 18, 2020 — Puppet, the industry standard for infrastructure automation, today announced a partnership with the Center for Internet Security, Inc. (CIS®). By formally partnering with CIS, Puppet is able to harness the power of CIS’s global community of security and compliance professionals to build better solutions for customers.

    “CIS literally wrote the rule book on compliance – their Benchmarks have become industry standard for compliance across the IT industry,” said Yvonne Wassenaar, CEO of Puppet. “With this partnership, we’ll be able to unite CIS’s extensive body of knowledge with Puppet’s deep IT and automation expertise, making it easier for our customers to achieve the enforcement of compliance they need across their increasingly complex infrastructure environments.”

    Most companies — from financial firms to healthcare institutions — must adhere to certain regulatory standards, but it can be difficult to keep up with the ever-increasing amount of rules and regulations needed to stay compliant. IT teams need better and faster ways to ensure compliance without requiring multiple different tools, solutions, or manual effort.

    In May, Puppet announced a service offering aimed at alleviating this compliance pain point, ensuring that customers are equipped to pass audits quickly through the enforcement of CIS Benchmarks, CIS’s best practices for securing IT systems and data.

    According to a report from Ponemon Institute, “the average cost for organizations that experience non-compliance problems is $14.82 million, a 45 percent increase from 2011.” However, companies that incorporate automation and continuous compliance policies into their infrastructure can save thousands of dollars and countless hours by reducing the complexities of audits, as well as hardening their systems against exploits and vulnerabilities. By leveraging CIS Benchmarks, Puppet is able to provide an end-to-end compliance solution for customers that enforces CIS standards across all systems and addresses gaps as they are identified.

    “We are excited to work closely with Puppet to bring compliance best practices and CIS Benchmarks to its large customer base while also advancing our mission to make the connected world a safer place,” said Curt Dukes, CIS Executive Vice President & General Manager, Security Best Practices. “This partnership reinforces our commitment to helping others improve their compliance and overall security posture.”

    Additional Resources

    Learn more about Puppet

    Follow Puppet on Twitter and LinkedIn

    Read our blog

    About Puppet

    Puppet makes infrastructure actionable, scalable and intelligent. From the data center to the cloud, Puppet helps enterprises modernize and manage their infrastructure to deliver innovation and efficiency through continuous automation. More than 40,000 organizations — including more than 80 percent of the Global 5000 — have benefited from Puppet’s open source and commercial solutions to ensure business continuity, optimize costs, boost compliance and ensure security – all while accelerating the adoption of DevOps practices and delivery of self-service. Headquartered in Portland, Oregon, Puppet is a privately held company with offices in London, Belfast, Singapore and Sydney. Learn more at puppet.com.

    About The Center for Internet Security

    The Center for Internet Security, Inc. (CIS®) makes the connected world a safer place for people, businesses, and governments. We are a community-driven nonprofit, responsible for the CIS Controls® and CIS Benchmarks™, globally recognized best practices for securing IT systems and data. We lead a global community of IT professionals to continuously refine these standards to proactively safeguard against emerging threats. Our CIS Hardened Images® provide secure, on-demand, scalable computing environments in the cloud. CIS is home to the Multi-State Information Sharing and Analysis Center® (MS-ISAC®), the trusted resource for cyber threat prevention, protection, response, and recovery for U.S. State, Local, Tribal, and Territorial (SLTT) government entities, and the Elections Infrastructure Information Sharing and Analysis Center® (EI-ISAC®), which supports the cybersecurity needs of U.S. elections offices. To learn more, visit CISecurity.org or follow us on Twitter: @CISecurity.

  • Puppet Brings Orchestration to IT Automation

    Puppet Brings Orchestration to IT Automation

    Puppet today unveiled its summer release of Puppet Enterprise that promises to make it easier for DevOps teams to construct automated workflows within a Puppet console.

    DevOps teams can now mix and match thousands of declarative state-based modules available on Puppet Forge repository to compose and orchestrate workflows.

    At the same time, Puppet has added out-of-the-box guided patch management workflows that replace standalone patch management tools with orchestrated workflows. That capability is based on a Relay tool that Puppet launched earlier this year.

    Finally, Puppet is now also including an upgrade pre-check module that assesses and identifies potential risks along with surfacing what changes should be made before running an upgrade.

    Puppet CTO Deepak Giridharagopal said in the wake of the economic downturn brought on by the COVID-19 pandemic, more IT teams will need to rely heavily on automation. Most IT teams either will remain the same size or be downsized. The IT environment, however, will continue to grow more complex. The only way to enable IT teams to do more with less is to automate more rote tasks, he said.

    Automation is not likely to replace the need for IT administrators, added Giridharagopal. Rather, investments in automation will augment those teams in a way that enables IT teams to scale.

    In fact, Giridharagopal said, resistance to IT automation is declining as IT teams continue to appreciate the scope of the challenge they now face as IT environments not only continue to expand but also become more heterogeneous. Most business leaders now expect smaller IT teams to be able to automate a wide range of tasks as part of their overall strategy, he noted.

    Longer-term, Giridharagopal said IT organizations will also discover that many rote tasks will be performed more consistently once automated. Patches, for example, are not always applied as quickly or as often as they should be simply because there isn’t enough time for the IT team to manually install them.

    The latest update to Puppet Enterprise comes on the heels of a $40 million investment made in Puppet led by BlackRock, a private equity firm. As more IT teams recognize the need to automate tasks, competition to automate those tasks has intensified among providers of frameworks.

    It’s not clear how deeply and how many IT tasks can be automated. The more standardized an IT environment is, the easier it becomes to automate. Additionally, the amount of time an IT organization devotes to writing scripts to automate tasks should be reduced sharply. Instead, IT teams will increasingly employ a mix of modules that already exist to address a broad range of use cases. The challenge going forward isn’t so much finding the right IT automation tool, but rather constructing an IT environment that lends itself to being automated.