Category: DevOps Toolbox

  • AppDynamics Taps into SAP Applications

    AppDynamics Taps into SAP Applications

    Application performance management (APM) is starting to be  employed more widely as more organizations embrace digital business transformation. As the number of digital business processes spanning multiple applications increases, so does the need to understand what’s occurring inside both greenfield and legacy applications. In fact, at the heart of many of those digital business processes are enterprise resource planning (ERP) and customer relationship management (CRM) applications from SAP. To make it possible to gain insights into those applications AppDynamics, a unit of Cisco Systems, announced today it is making available AppDynamics for SAP.

    Jonah Kowall, vice president of market development and insights at AppDynamics, said his company is now able to support ABAP, the proprietary language SAP developed to build its applications. That language also has been employed extensively by IT organizations to customize those applications.

    SAP currently is trying to transition its customers to building custom applications on a cloud framework based on the Cloud Foundry platform-as-a-service (PaaS) environment. Most of those applications are be written in Java or the new Jakarta platform that replaces Java. SAP has also provided a software development kit and application programming interfaces (APIs) for tapping into S/4 HANA ERP applications.

    But there is a massive installed based of ABAP applications running in enterprise IT environments. Much of that code is now being integrated with other applications as part of a larger digital business transformation initiative.

    Kowall said those extensions are now driving organizations to apply an agent for the AppDynamics APM to custom applications written in ABAP. Historically, enterprise IT organizations only applied APM to their most critical applications. But as organizations move to digitize business processes, they now need to able to track transactions spanning multiple applications. Given the reliance many organizations have on SAP applications, it’s inevitable those transactions will involve SAP applications that were customized using ABAP.

    In addition, Kowall noted that being able to discover precisely where those custom applications are involved in any transaction is pivotal when it comes to upgrading to the SAP S/4 HANA applications, which are based on the SAP in-memory database, or lifting and shifting a legacy SAP application into the cloud.

    Kowall said organizations that have used ABAP to customize SAP applications now will have visibility down to the code level, including queries being made to the underlying database. From a DevOps perspective, that capability will go a long way to breaking down yet another silo in the enterprise. AppDynamics expects the first order of business for many organizations will be simply to create a performance baseline for their ABAP applications, which in many cases are likely to be an eye-opening experience, he said.

    The focus on digital business transformation is likely to spur adoption of DevOps processes over a much broader swath of the enterprise. Rather than simply apply DevOps processes to new applications, many organizations soon will extend DevOps into the realm of legacy application environments as well. That may take some time to play out, given the scope of the cultural changes involved. But at this point, those changes are now all but inevitable.

    — Mike Vizard

  • The Past, Present and Future of DevOps Infrastructure

    The Past, Present and Future of DevOps Infrastructure

    Infrastructure automation enables organizations to set up operating frameworks that allow smooth functionality with enhanced usage, minimal scope for error and faster deployment of code. The process of infrastructure automation eases development and operations processes by introducing good deployment practices such as computerized testing and versioning.

    The need for automation was realized when the demand for deploying error-free applications at a faster rate increased. Additionally, competition from similar businesses forced organizations to look for a way to bridge the gaps between development and operations to deploy applications that would serve their business needs.

    The Challenge of Implementing DevOps Practice

    The following challenges present a roadblock in bringing out the best results of DevOps practices:

    1. The disparate work cultures of the development and operations teams.
    2. Non-involvement of DBAs in release cycles.
    3. Failure in deployment of error-free codes.

    The Emergence of DevOps

    The introduction of DevOps practices resolved a lot of problems in terms of increasing business operations efficiency. It created a common operating framework where disparate teams including development and operations teams can work together and deliver applications faster that will, in turn, result in effective business operations and an increase in ROI.

    Adopting DevOps involves:

    1. DevOps experts outlining of traceable metrics for creating a roadmap by visualizing the desired outcome.
    2. Creating a pilot framework that will include the tools of both development and operations teams further integrating these existing tools with the DevOps experts’ robust ecosystem,
    3. Analyzing, designing, constructing, automating and implementing the network based on the metrics and resources collated.

    DevOps Tools:

    The DevOps infrastructure automation process uses several tools that define and drive the success of the implementation process. Here is a short overview of some of the more well-known and widely used tools.

    • Jenkins – A Java-based continuous integration (CI) tool contributes to the faster delivery of applications. Jenkins must be aligned with a version control system such as GitHub or SVN. Whenever the code repository receives a new code, a Jenkins server builds and tests the new code and informs the team about results and any changes. Over time, Jenkins has moved from being just a CI tool to being used as an orchestration tool that builds pipelines for application provisioning and deployment.
    • Chef – A ruby-based configuration management tool, Chef includes cookbooks that code infrastructure in domain service language (DSL) in combination with a little bit of programming. Chef creates virtual machines and customizes them in accordance with the rules listed in the cookbooks. An agent residing on all the servers that need configuration extracts the cookbooks from the chef master and runs them on the server to get the desired results.
    • Puppet – Also, a ruby-based configuration management tool, Puppet was developed with system administrators in mind. A configuration code is written using Puppet DSLs and is wrapped in modules. Puppet performs a similar function to Chef but, unlike Puppet, Chef is a developer-focused tool. It runs a puppet agent on all servers that require configuration and extracts the compiled module from the puppet server and installs required software packages as prescribed by the module.
    • Ansible – An agentless configuration management and orchestration tool, Ansible can be used for cloud computing. Ansible has configuration modules called “Playbooks,” which are written in YAML format and are easy to compose in comparison with other configuration management tools.
    • Docker – Docker, a process-level virtualization tool, creates isolated environments for applications known as containers. These containers can be transferred to any other system without making any application changes. Docker has evolved as the next step in virtualization. It is beginning to become a favorite of many DevOps practitioners and leading cloud experts.

    The Future of DevOps Infrastructure Automation

    A lot of organizations are beginning to benefit from the implementation of DevOps infrastructure automation. And with the pace at which the demand for DevOps services is increasing, infrastructure automation has a long way to go.

    As per statistics, by bringing DevOps practices into the picture, organizations can benefit by deploying code up to 30X more frequently and reduce the deployment failure to less than 50 percent.

    — Veritis

  • More App Dev Models Increase DevOps Pressure

    More App Dev Models Increase DevOps Pressure

    A bifurcation in types of developers will become more pronounced in the years ahead as more application code moves to the network edge. As that transition continues occurring, the pressure on IT operations to be able to be able to flexibly manage different classes of applications by embracing DevOps processes will correspondingly increase.

    Mike Piech, vice president and general manager of middleware for Red Hat, said applications running on internet of things (IoT) devices and smartphones present developers with a finite amount of compute resources that require them to have advanced skills. Conversely, back-end applications can now take advantage of multiple layers of abstraction, including (soon) serverless computing frameworks based on event-driven architectures that make potentially unlimited compute resources available. The availability of all those compute resources, however, encourages developers of back-end services and applications to be less disciplined when writing applications.

    The good news is that it’s getting easier to right-size applications using trial and error methods versus having to commit to a specific computing architecture up front, said Piech. If something doesn’t work as well as it should, modular approaches to microservices make it possible to more easily move application code to where it should best optimally reside. Rather than focusing on the rigor of the underlying architecture, developers are free to experiment with different tools and languages more now than any time in the history of IT, he said.

    In fact, Piech speculated that many graphical user interfaces will continue to run locally while accessing a wide variety of back-end services via application programming interfaces (APIs). That approach essentially creates a new form of hybrid computing wherein developers no longer need to think much about the runtime environment, he noted.

    However, all that freedom tends to put a lot more pressure on the IT operations team. As the types and classes of applications continues to evolve, Piech said it’s only a matter of time before more organizations move further down the DevOps path. Adoption of DevOps processes across organizations has been somewhat uneven. But as developers experiment with different computing models, the expectation is that operating teams will be flexible enough to dynamically make the appropriate adjustments, he said.

    Longer term, middleware and databases will eventually be deconstructed into sets of microservices that developers can call when needed. Today, IT operations teams make available monolithic application servers and databases. Many of those databases and application servers are starting to be encapsulated in Docker containers as part of a first step toward lifting and shifting applications into the cloud before transitioning to more agile microservices-based frameworks, Piech said.

    In some cases, those services will be accessed directly via a platform-as-a-service (PaaS) environment or a serverless computing framework. Piech said Red Hat expects serverless computing frameworks based on event-driven architectures will be used mainly to provide bursting capabilities as a complement to long-running stateful applications that typically consume a fixed amount of IT infrastructure resources. It’s probable stateless applications that run intermittently also will find their way on to serverless computing frameworks. Red Hat has thrown its support behind the open source OpenWhisk serverless computing framework.

    There clearly will be many more types of distributed applications running across the enterprise. IT operations teams may not have much control over what types of applications run where and when. But they will be expected to be able to deploy and manage them all, regardless.

    — Mike Vizard

  • From One-Size-Fits-All to Custom-Fit for IT Ops

    From One-Size-Fits-All to Custom-Fit for IT Ops

    The downfall of the all-in-one IT management suite and the rise of the customized IT Ops toolchain

    Here is how enterprise IT Ops used to work: you would make your choice among the Big Four vendors and buy in (quite literally!) to their strategy. This meant a suite of products that came preintegrated (more or less) out of the box, and—at least on the sales proposal—covered all of an IT organization’s needs across a huge spectrum of activities.

    selection of tools hanging ready to use
    Photo by Barn Images on Unsplash

    Broadly speaking, each of the Big Four’s suites included some flavor of the following: monitoring, ticketing, configuration management and asset tracking and automation and orchestration. Some vendors were stronger in one area than in another, but unless you had pretty specific needs, each vendor could be your one-stop shop.

    Development and improvement inside these suites was mainly incremental and occurred at a fairly leisurely pace. Meanwhile, startups with bright ideas would come along occasionally and challenge the incumbents in specific areas, only to be bought by one of the mega-vendors if they showed enough promise.

    There was a symbiotic relationship between vendor and IT buyer, as IT professionals built decades-long careers as experts in this or that vendor’s technology stack, with the wall of framed certifications to prove it. CIOs were reassured by the fact that there was a readily available pool of experts to hire, and continued reinvesting in the next iteration of their chosen vendor’s stack.

    The Old Model No Longer Fits Modern IT

    In the last decade or so, this comfortable status quo has broken down. The cracks were already showing before then, but only the most agile and forward-thinking organizations were moving fast enough to trip over them. As more and more businesses began to expect greater and greater responsiveness and speed from their IT departments, the huge sprawling suites of the mega-vendors were no longer able to keep up with the required rate of change. Leisurely 18-month release cycles no longer cut it in an agile world, where that time span may encompass several entire strategies.

    In the old world, to call something “best of breed” was a sniffy dismissal of a one-trick pony, as opposed to the more supposedly versatile offerings of the Big Four. In the new world, it became obvious that aside from a handful of tentpole products that were genuinely good and fit for purpose, most of the individual components of the big suites was distinctly unexciting. Worse, the main value proposition of the suites—that they came preintegrated out of the box—started to break down as well. Many IT professionals were still fiercely loyal to individual products, but they became more willing to pick and choose, rather than buying into the whole vision.

    In parallel, the rise of simple integrations—primarily REST APIs—made it easier than ever before to connect disparate solutions together into a single IT Ops toolchain. Worse (from the point of view of the incumbent vendors), sometimes it was easier to connect modern point solutions than their own component pieces, weighted down by the baggage of decades on the market.

    How to Deliver the Flexibility and Agility the Business Expects?

    These days, it is becoming commonly accepted even among the most staid and risk-averse organizations that the way to go is no longer to align to a single IT vendor and trust them to deliver on their vision, but rather to design custom-fit, multisolution toolchains, including home-grown, open source and commercial tools.

    agile jump
    Photo by Max Bender on Unsplash

    But what to do if you find yourself dealing with the consequences of this sort of IT monoculture?

    Look Back At How You Got Here

    The first step is to re-evaluate past buying decisions and strategic alignment. It is very important to do this without assigning blame; it was a different time, and those choices may well have been the right ones for the prevailing environment at the time, when integration between tools from different vendors was legitimately difficult.

    Don’t Just Throw Everything Out

    In many environments, too, the correct solution may well not be a clean sweep. One or more of those tentpole products that kept the overall suite looking good past its sell-by date may well still be perfectly fit for purpose and not worth the hassle of swapping out. However, other components are probably legitimately lagging behind the state of the art, in which case it is worth replacing them with something more fit for purpose.

    Count Costs – All Costs

    Include cost in these calculations, but remember to include all costs. Maybe you or a predecessor signed a big enterprise license agreement (ELA), so Product X is “free” in that context. But what does it cost to keep Product X running, in terms of ancillary licenses, hardware requirements and, last but not least, skill and effort on the part of the IT administrators? I don’t want to name specific products or vendors as examples, to avoid the discussion devolving into particulars, but it’s worth bearing in mind that many legacy products have shallow talent pools—not that many people are available on the market, and many of those people are coming to the ends of their careers, which makes them both expensive and reluctant to change employers. Instead, up-and-coming technologies often have much deeper and wider talent pools, with many more experienced specialists available at all salary and skill levels. If you don’t believe me, try hiring half a dozen COBOL programmers and half a dozen Node.js coders, and then we’ll talk …

    IT Ops hard at work
    Photo by Giu Vicente on Unsplash

    Your IT Ops Toolchain, For Your IT Ops Needs

    Moving from one of the big all-in-one suites to an assemblage of different tools, all flying in loose formation, is not easily done. Any technology transition of this sort is a Project with a capital P, and needs to be planned and managed with due care and attention. However, there is a large payoff at the end in terms of increased agility and flexibility within IT Ops. In turn, this affords IT the ability to offer their business counterparts the sort of responsive and even proactive IT support that moves IT from being a cost center, on a par with Facilities, to a strategic differentiator that enables new business initiatives.

    Business as usual doesn’t cut it any more, and assumptions that used to be valid have fallen apart. Decisions based on those assumptions need to be re-evaluated. New, more flexible approaches will set up IT Ops for success in the newly flexible world we are already living in.

    — Dominic Wellington

  • Red Hat Aims to Push IT Management to the Cloud

    Red Hat Aims to Push IT Management to the Cloud

    Red Hat at the Red Hat Summit 2018 conference this week showed a technology preview of an instance of Red Hat Insights, a predictive analytics IT management application capable of identifying operations issues before they become a problem, running as a software-as-a-service (SaaS) application.

    The instance of Red Hat Insights will be extended to apply analytics to any infrastructure platform. Red Hat plans to eventually make the rest of its IT management portfolio available as a cloud service.

    Joe Fitzgerald, vice president and general manager for management at Red Hat, said the goal is to enable management of virtual machines, container, infrastructure-as-a-service and physical servers all from a single pane of glass.

    Cost analytics also will be embedded in those services, adds Fitzgerald. Cost is now a much bigger issue because cloud service providers bill customers based on actual consumption. Previously, a virtual machine left running on an on-premises server might result in someone being yelled at, but no additional cost, notes Fitzgerald. Now, however, if an IT organization doesn’t turn off those virtual machines, it will end up paying more.

    Fitzgerald noted that management of IT operations is becoming increasingly automated. Red Hat is now adding integrations with the agentless Ansible framework it acquired in 2015 at rate of 50 a week. There already  are 1,600 integrations with Ansible. He said the fact that Ansible presents IT operations teams with a declarative approach to automating IT using YAML files makes IT automation much more accessible. Other frameworks require IT operations teams to learn how to program, which becomes a significant barrier to adoption, but YAML files allow IT operations teams to make use of familiar shell scripts.

    Many organizations now are moving up the IT management curve as applications become more distributed, Fitzgerald said. Every platform they have comes with its own management tools. But the need for a control plane through which multiple platforms can be centrally managed is now becoming more evident, he said, especially as IT organizations realize they will be running many different types of platforms for many years to come.

    Other benefits to shifting IT management into the cloud is that the move eliminates the need to deploy a local server just to run IT management software and all updates to the IT management platform are provided by the applications provider.

    Obviously, Red Hat is not the only IT vendor building a centralized, cloud-based approach to managing distributed computing environments. But as Ansible becomes more widely adopted, the opportunity arises for Red Hat to engage in a broader IT management conversation with IT organizations.

    Most enterprise IT organizations are rapidly approaching something of an IT management crisis. Each platform adopted creates yet another silo that makes adopting integrated DevOps processes even more challenging. While most organizations are not likely to abandon the management tools from the vendors that built those platforms, IT organizations are demanding thet underlying infrastructure exposes an application programming interface (API). In fact, it’s the proliferation of all that software-defined infrastructure that now makes it feasible to centralize the management of IT in the cloud.

    — Mike Vizard

  • Oracle Adds Low-Code Tool to Autonomous Platform

    Oracle Adds Low-Code Tool to Autonomous Platform

    Oracle this week extended the scope of the cloud services it manages on behalf of customers to include a low-code application development platform based on the company’s Visual Builder development tools.

    Jeff Price, vice president of product Management at Oracle, said Oracle Autonomous Visual Builder (VB) Cloud makes it possible to employ a tool based on JavaScript to build applications that might be written, for example, in Java or, going forward, Jakarta EE. Autonomous Visual Builder Cloud is available via a managed service that can easily integrated with a variety of back-end services managed by Oracle or running on-premises.

    To complement that effort, Oracle also announced the availability of Oracle Autonomous Analytics Cloud and Oracle Autonomous Integration Cloud. Oracle Autonomous Visual Builder comes with tools for accessing back-end services, while Oracle Autonomous Integration Cloud provides a raft of additional connectors for accessing a wide variety of other Oracle and third-party services, Price said.

    Oracle also committed to delivering additional autonomous services later this year to address mobile and chatbots, data integration, blockchain, security and management and additional database workloads such as online transaction processing (OLTP). Those services will complement existing Oracle autonomous database and platform-as-a-service (PaaS) environments.

    Price said interest in low-code development tools is accelerating as organizations look to extend business processes that have been automated using either packaged applications running on-premises or in a software-as-a-service (SaaS) application. Rather than trying to achieve that goal using low-level application programming interfaces (APIs) that are fragile, Price said low-code tools such as Oracle VB make it simpler for even citizen developers to construct applications leveraging code developed by professional developers.

    Organizations need to decide for themselves when to customize those application environments versus taking advantage of them in a turnkey manner, Price said. Organizations tend to heavily customize customer experience and customer relationship management (CRM) applications, while relying on best practices that have been coded into enterprise resource planning (ERP) applications. Oracle is changing the way it supports those applications—base-level support for these applications is now free, but Oracle will continue to charge for premium services.

    The need to customize applications at scale is driving many more traditional enterprise IT organizations to adopt DevOps processes that now need to span multiple IT environments, Price said. He added Oracle now provides integration with multiple continuous integration/continuous deployment (CI/CD) platforms to facilitate that transition.

    As Oracle assumes more responsibility for managing the underlying platforms, organizations in theory should be able to devote more resources to developing applications. To achieve that goal, however, many of them will need to figure out how to extend their DevOps processes to include Oracle as a managed service provider.

    Oracle also provides access to unmanaged infrastructure-as-a-service (IaaS) and (PaaS) services in much the same way Amazon Web Services (AWS) and Microsoft do. Oracle has been late to the cloud game, but this week announced a slew of new cloud customers, including Atomitech Inc., Edith Cowan University, Future Robot, Barrick Gold Corporation, C’s NEXT, Colegio de Bachilleres, Contribute NV, DP World Ltd., Dubai Airport Freezone Authority, Emirates Flight Catering, Hytera Communications Ltd., Ildong Pharmaceutical Co. Ltd., Konyang University, Land O’Lakes Inc., Leshan City Commercial Bank, McDermott, MCore Group, New Hope Liuhe Co. Ltd., Promata, Stallion Oilfield, Ornua Co-Operative, RecVue, Saga d.o.o Beograd, TCI, TaskUs, University of Wisconsin Hospital and Clinics Authority, and Zeneral Heatpump Industry Co. Ltd. All told, Oracle claims to be processing 55 billion transactions a day on its cloud.

    It may take a while for Oracle to catch up to AWS. But if it doesn’t achieve that goal it won’t be for a lack of development tools.

    — Mike Vizard

  • Google Looks to Simplify Building of Workflows

    Google Looks to Simplify Building of Workflows

    Google this week launched the beta of Cloud Composer, a managed Apache Airflow service for building workflows that promises to simplify management of integrated DevOps processes. Apache Airflow is an incubation project being developed under the auspices of the Apache Software Foundation that enables IT teams to programmatically author, schedule and monitor workflows using directed acyclic graphs (DAGs) that visualize pipelines running in production, monitor their progress and can be used to troubleshoot issues.

    James Malone, a product manager for Google Cloud, said Cloud Composer leverages Apache Airflow to not only make it simpler to manage workflows, but also port them between various public and private clouds, including on-premises IT environments.

    Cloud Composer also includes the Google Developer Console and Cloud software development kit (SDK), a cloud identity-aware proxy, Stackdriver logging and monitoring, identity access management (IAM) and Python support, along with simplified DAG management and streamlined Airflow runtime.

    Google plans to add support for autoscaling and availability in additional Google Cloud regions over time, Malone said, as well as integrate Google Composer with Kubernetes to extend the reach of Apache Airflow workflows to containers.

    Pricing for Cloud Composer is consumption-based as measured by vCPU/hour, GB/month and GB transferred/month.

    Malone said Cloud Composer will play a critical role in enabling DevOps teams to construct pipelines spanning hybrid cloud computing environments. Today IT administrators regularly make use of text editors or scripts they write to automate a process. But it’s difficult for those scripts to be shared between multiple IT administrators. Cloud Composer and Apache Airflow make it easier to share workflows that automate processes across DevOps teams. Just as importantly, those workflows will be accessible to IT administrators who don’t have the programming skills required to develop a script.

    Those workflows will also play a critical role in unifying DevOps and DataOps processes around a common set of continuous integration/continuous deployment (CI/CD) processes, Malone added.

    Most organizations today are managing multiple clouds in isolation from one another. But as organizations look to build applications faster, they want to be able to deploy those applications on the most optimal platform available without having to develop a unique set of pipelines for each cloud environment. Having an application locked into a specific cloud platform not only is economically unacceptable, it’s also fundamentally inefficient from an application development and deployment perspective.

    Apache Airflow is not the only tool that can be employed to construct pipelines. But Malone noted that because it is an open source Apache project, organizations can be assured that workflows they develop can run anywhere now and into the future. Google chose Apache Airflow to build Cloud Composer largely because an active development community is emerging around this open source project, he said.

    The way IT platforms are managed is transforming rapidly. The days when servers and applications where managed in isolation are over. IT administrators are being asked to manage fleets of server and storage systems running more applications than ever. The tools required to achieve that goal are thankfully now becoming a lot more accessible to everyone in IT.

    — Mike Vizard

  • Dell EMC Bets on Machine Learning to Drive IT Agility

    Dell EMC Bets on Machine Learning to Drive IT Agility

    Dell Technologies announced it is infusing machine learning algorithms across its portfolio of server and storage infrastructure to optimize the performance of each individual application using artificial intelligence (AI).

    At the Dell Technologies World 2018 conference, the Dell EMC arm of Dell Technologies announced it has joined the Intel AI Builders program. Dell EMC and Intel will enable customers to benchmark Deep Learning and high-performance computing (HPC) workloads running on Intel Xeon Scalable processors and Intel field programmable gate arrays (FPGAs) integrated in the company’s PowerEdge R740 servers at the Dell EMC Innovation Lab and the Dell EMC customer Solution Centers.

    Dell EMC also unveiled Dell EMC PowerMax, an NVMe-based storage array that takes advantage of an embedded machine learning engine into the storage operating system to optimize I/O performance. Dell EMC said that engine is capable of making 6 billion decisions related to optimizing 40 million data sets a day.

    Finally, Dell also announced Dell Precision Optimizer software that compares the behavior of each application deployed on a Dell workstation against a machine learning model that automatically optimizes system settings. According to the company, Dell Precision Optimizer can improve workstation application performance band delivery up to 394 percent.

    Ashley Gorakhpurwalla, ‎president and general manager for server and infrastructure systems at Dell EMC, said the plan is make it possible to compare the state of an IT infrastructure deployment against AI models that Dell EMC is constructing in the cloud using all the data gathered from the company’s systems connected to Dell EMC support services. Armed with that data, it will become possible to optimize system settings for every type of application deployed on it, said Gorakhpurwalla.

    He noted that despite advances in DevOps, provisioning resources in a local data center on demand is still too time-consuming. Many IT organizations have adopted converged and hyperconverged infrastructure (HCI) platforms to unify the management of compute, storage and networking. But machine learning algorithms combined with other emerging technologies should make it possible to make IT infrastructure resources on demand in a cloud-like manner. That increased level of automation should enable IT organizations to allocate more resources to developing applications than managing the infrastructure those applications run on.

    Each IT organization today is at a different stage of maturity when it comes to IT infrastructure. Dell EMC has one customer with a single administrator who manages more than 80,000 servers, Gorakhpurwalla said. Over time, IT infrastructure will become increasingly automated across a much broader range of customers, he noted—critical because it will allow local IT teams to be as agile as any cloud service providers. Today, many workloads are deployed in the cloud because of the perceived agility of the cloud, regardless of the actual costs.

    It may take some time for developers to regain confidence in the agility of local IT departments. But as AI models continue to evolve it’s now a matter of when rather than if local IT infrastructure will become much more responsive to the needs of any given application.

    — Mike Vizard

  • Puppet Expands Scope of Pervasive Automation Initiative

    Puppet Expands Scope of Pervasive Automation Initiative

    Puppet today unveiled a series of initiatives as part of a continuing campaign to make IT automation available pervasively across the enterprise.

    Omri Gazitt, chief product officer for Puppet, said the first step in that effort is making it easier for IT organizations to discover what assets they need to manage. Puppet Discovery is an agentless tool through which organizations can monitor their IT environments continuously. Any changes or additions are captured immediately in a database.

    Scheduled to be available in May, Puppet Discovery replaces a traditional configuration management database (CMDB) with a platform that more accurately reflects the state of the IT environment because it’s always up to date, Gazitt said.

    Puppet is also extending the reach of its IT automation framework to include modules spanning platforms from Barracuda Networks, Cisco Systems and Nutanix, as well as the Azure cloud service from Microsoft.

    Modules for Cisco ACI software-defined networks (SDNs) and Cisco Meraki wireless networks are now available, along with a private beta of a module for the Cisco IOS operating system widely employed on the Cisco network infrastructure.

    Similarly, Puppet modules are now available for security and data protection offerings from Barracuda Networks and the hyperconverged infrastructure (HCI) platform developed by Nutanix.

    Puppet, in the context of the cloud, is now adding a module for Azure Resource Manager, as well as adding support for Windows PowerShell Desired State Configuration (DSC) and the Microsoft Task Scheduler 2.0 application programming interface (API) used in Windows.

    In related news, Microsoft, Barracuda Networks and Puppet also announced they are combining their respective capabilities to create an Azure Accelerator program to automate and secure mission-critical workloads. Organizations that participate in the program can get started at no cost, with free software from Puppet and Barracuda and no Microsoft Azure infrastructure charges while migrating workloads to Azure Cloud.

    Other new members of the Puppet Technology Alliance Partner program include Lenovo and xMatters.

    Finally, Puppet announced scheduled June availability of Continuous Delivery for Puppet Enterprise (PE), an update to Puppet Enterprise that includes role-based access control for Tasks, which can define node groups corresponding to business functions or units to limit who can run tasks within a specific node group. Puppet also has added Puppet Bolt Task Plans, which enable customers to orchestrate a set of tasks across thousands of Puppet Enterprise nodes using Puppet Orchestrator. Continuous Delivery for PE is based on a continuous delivery platform developed by Distelli that Puppet acquired last year.

    Puppet Enterprise has also been enhanced with easier backup and recovery capabilities to automate disaster recovery and support for a Puppet Development Kit (PDK), which includes a new resource application programming interface (API) that Gazitt said can be used to create custom Puppet modules to automate the management of any platform.

    In general, Gazitt noted that IT automation and DevOps increasingly are becoming synonymous. The biggest issue now, he said, is unifying all the independent silos of DevOps implementations that now span many enterprise organizations.

    Of course, IT organizations can apply IT automation without necessarily embracing DevOps. But once an organizations begins to adopt DevOps, it’s pretty clear IT automation quickly becomes indispensable.

    — Mike Vizard

  • Eclipse Foundation Charts Cloud-Native Path Forward for Jakarta

    Eclipse Foundation Charts Cloud-Native Path Forward for Jakarta

    A new era begins for the Java community today with a commitment to a Jakarta EE specification that the Eclipse Foundation expects will become cloud-native in short order.

    Jakarta EE formally marks the end of a Java era. While the term Java will still apply to any technologies developed prior to Oracle transferring stewardship of the venerable programming language to the Eclipse Foundation, all future innovations will be delivered under the Jakarta brand.

    A survey of 1,800 Java developers shows that in addition to increasing the overall pace of innovation, the top two priorities of the developer community is to see more emphasis being placed on microservices and integration with the emerging de facto Kubernetes container orchestration platform.

    A full 95 percent of the respondents building microservices said they are employing Java as part of those efforts, while nearly one-third of respondents are already working with Kubernetes. Mike Milinkovich, executive director of the Eclipse Foundation, said that although it’s yet to be determined precisely how Java and Kubernetes will be more tightly coupled, it’s clear the Jakarta community wants to be able to deploy cloud-native applications based on Jakarta. Half of survey respondents said they ran only one-fifth of their Java applications today in a cloud. But more than 30 percent said they expect to be running 60 percent of more of their applications in the cloud within the next two years.

    Milinkovich said with Jakarta under the auspices of the Eclipse Foundation, many more developers from different vendors will be contributing code to advance it. Previous advances to Java have been slow in coming over the years because all contributions to the code base were controlled by Oracle. One of the first things to change under the stewardship of the Eclipse Foundation, he noted, is that Oracle has committed to open-sourcing the Test Compatibility Kits (TCKs), which vendors previously were required to license at significant expense.

    Also expected to witness a faster innovation cycle, Milinkovich said, is Eclipse MicroProfile, a Java framework developed by IBM and Red Hat optimized for microservices, which the Eclipse Foundation expects to be as widely embraced as the Spring framework based on Java that Pivotal Software helped popularize. In fact, there will be a lot more cross-pollination of ideas and concepts across all the major frameworks from writing applications, he added.

    Tighter integration between Jakarta and Kubernetes and a general simplification of the effort required to develop microservices is likely to have a significant impact on DevOps for years to come. Many organizations today are contemplating the degree to which they may want to lift-and-shift existing Java application into the cloud versus rewriting them completely in a new language. With the Eclipse Foundation’s commitment to a cloud-native implementation of Jakarta EE, it’s clear that organizations can have greater confidence that existing investments in Java applications likely will remain relevant in the age of the cloud. In fact, the only decision left for many of them to make is the degree to which they might want to turn monolithic applications written in Java into highly portable microservices based on Jakarta EE.

    — Mike Vizard