devopsy.kinsta.cloud

Author: Mike Vizard

IBM Extends Cloud Reach to Include Integration

At the IBM Think 2019 conference this week, IBM unfurled an IBM Cloud Integration Platform that pulls together a range of tools in a single development platform that the company promises will reduce the amount of time it takes to deploy applications by making it easier to reuse integration code.

Hillery Hunter, vice president and CTO for IBM Cloud Infrastructure, said by bringing all of its primary integration tools into a single cloud platform, IBM is effectively making an integration platform-as-a-service (iPaaS) environment available for the first time.

IBM this week also formally rolled out IBM Services for Multicloud Management, a portal through which multiple clouds can be managed using software-as-a-service (SaaS) applications developed by ServiceNow, along with a set of IBM Services for Cloud Strategy and Design through which IBM will advise clients on how to architect the right holistic cloud strategy. The premise of both those services is that organizations soon will be rightsizing workloads to run on whatever cloud or on-premises IT platform that best suits them. The portal developed with ServiceNow provides access to dashboards and analytics designed to enable IT organizations to analyze cloud spend and manage workloads deployed on any platform, including Amazon Web Services (AWS) and Microsoft Azure.

IBM is also extending the cloud services it provides to include the IBM Cloud Hyper Protect Crypto Service, which makes use of IBM LinuxONE mainframes to provide encryption key management built on the only FIPS 140-2 level 4-based technology.

Hunter said IBM’s approach assumes organizations have already bought into best DevOps practices and API management to provide the means through which multiple clouds will be managed. The challenge many of those organizations are now wrestling with is implementing processes that determine where a workload not only should be developed and deployed but also moved as its characteristics evolve. To provide that analytics, IBM is employing machine learning algorithms running on distributed instances of Kubernetes to continuously track changes and updates to cloud platforms, said Hunter.

IBM previously outlined a strategy under which it is trying to meld DevOps and ITIL-based processes to make it easier to manage workloads running on any cloud or on-premises IT environment. While the growth of cloud computing continues at an exponential rate, IBM executives this week took pains to remind conference attendees that 80 percent of enterprise-class workloads still run in on on-premises IT environment. In fact, IBM’s rationalization for spending $34 billion to acquire Red Hat is based on that fact. However, while many workloads will continue to run on-premises, IBM is clearly making a case for centralizing the management of all those platforms on IBM Cloud.

It most likely will take the better part of the next decade to determine where different types of applications may wind up running. Predictions concerning the percentage of application workloads that will run in the cloud continues to be one of the most hotly debated topics in the IT industry. Whatever the outcome, however, it’s 100 percent certain more than one cloud platform will be involved.

— Mike Vizard

February 14, 2019
Datadog Acquires App Dev Testing Platform Madumbo

Datadog announced it is extending its reach beyond IT monitoring to include application testing by acquiring Madumbo.

Madumdo CEO Gabriel-James Safar said it’s become increasingly apparent that application testing needs to be more informed by the metrics gathered by IT monitoring tools. The combined Datadog/Madumbo will bring intelligence to automated testing processes using both application and infrastructure data gathered via the Datadog platform.

The Madumbo platform already makes extensive use of machine learning algorithms and predictive analytics to inject artificial intelligence (AI) into the application testing process. The more data those algorithms can access, the more precise the AI models become over time.

That approach made it possible for Madumbo to build a bot that checks for errors using code running on a real browser, which Safar said means DevOps teams can capture the same defects as they are experienced by end users. That’s critical because much time is wasted by IT organizations that are unable to prioritize tasks to either identify the root cause of a problem or, arguably more importantly, prevent issues in the first place, said Safar. Because of that issue most organizations lack the time required to develop best-in-class DevOps processes.

Datadog provides a complimentary set of IT monitoring tools that are consumed as a software-as-a-service (SaaS) application. That data will then become a trusted source for Madumbo, which in turn will increase confidence in the AI recommendations being made by Madumbo, said Safar.

How many of those customers will wind up replacing whatever application testing tools they currently employ with Madumbo remains to be seen. But if Datadog can provide a more efficient approach to testing, testing tools may wind up driving organizations to replace their monitoring tools. Most organizations spend an inordinate amount of time trying to correlate data across tens of monitoring tools that often generate either conflicting alerts or alerts about issues the IT organization has already been informed of by another tool. Most IT organizations eventually will see the rise of AI platforms that will drive consolidation across the entire DevOps tools category.

In the meantime, the more issues that get addressed during the application development process, the fewer number of problems that will raise their ugly head in production environments. In fact, it’s arguable the whole point of investing in best-in-class DevOps processes is not just to roll out applications faster, but also make sure those applications are of a markedly higher quality than previous generations of applications. That’s not going to happen, however, unless DevOps teams can derive actionable intelligence from the millions of alerts that get generated up and down the IT stack.

— Mike Vizard

February 13, 2019
Electric Cloud Aims to Make DevOps More Accessible

Electric Cloud today unfurled the Winter 2019 edition of the ElectricFlow platform for managing DevOps, which makes it easier for different classes of users to tailor the platform to meet their specific needs.

Sam Fell, vice president of marketing for Electric Cloud, said the latest release of ElectricFlow allows end users to choose from different personas based on their role in the organization, and each persona has a user interface crafted to surface the level of detail they most likely require. That approach is intended to make the company’s DevOps platform more accessible to wider variety of end users, he said.

The latest edition of ElectricFlow also adds a customizable customer login experience that is more task-oriented. Users can now add bookmarks/favorites to access specific pages faster.

Finally, Electric Cloud is now including release and pipeline templates that make onboarding easier, based on user created events/triggers and code check-ins in a Git repository.

Fell said that while DevOps platform such as ElectricFlow increasingly have incorporated higher levels of automation by relying more on machine learning algorithms, humans should not be left behind. Electric Cloud has been focusing more of its development effort on making it easier for DevOps professionals of all skill levels to derive value from the platform, he said, noting current DevOps platforms tend to make available far too much information than the average IT professional can ingest, added Fell.

Less clear is how the complexity inherent in DevOps processes extends the time it takes for an organization to employ DevOps pervasively. While DevOps platforms are undoubtedly powerful, they also can be intimidating. In many instances, it’s simply easier for IT administrators to continue to rely on tools they already know to manage a specific task even when that tool is not as robust or rich as what might be accessible in a more modern DevOps platform. What often is ascribed to cultural IT inertia may have its roots in the simple fact that IT professionals are not always equally excited about having to learn and master new tools.

The number of IT organizations that have been able to employ DevOps processes across their entire organization are still a comparative minority. Most organizations today have what can best be described as pockets of DevOps processes, usually driven by a small, cross-function team that is highly motivated to update a specific set of applications continuously. IT organizations are, of course, hoping to replicate the success of those teams across the rest of the organization. However, the rest of the IT organization doesn’t always have the same level of engineering skills—the spirit may be willing, but the initial DevOps hurdles needed to be overcome are simply too high.

It may be a while before IT organizations sort this all out. More accessible tools are only one part of the equation. But IT leaders almost inevitably find that giving their teams access to easier tools will, at the very least, start moving their organization in the right direction.

— Mike Vizard

February 12, 2019
Actifio Looks to Meld DataOps with DevOps

Actifio and IBM have formed an alliance under which IBM will make available data management software developed by Actifio under its own name as part of an effort to close the gap between DevOps and DataOps.

At the same time, Actifio will make available a software-as-a-service (SaaS) offering for the first time, dubbed Actifio Go, which promises to make it easier to manage and move data across multiple clouds.

Actifio CEO Ash Ashutosh said with the rise of both DevOps and DataOps there is now a unique opportunity to unify the management of pipelines across the enterprise. While storage administrators have been creating data pipelines for databases and applications for decades, the pipelines developers create to consume that data have been developed and managed separately. Now there is a nascent DataOps effort based on a set of best practices for automating the management of data that borrows many of the same principles being advanced by DevOps proponents for the building and deploying of applications.

Actifio’s core Virtual Data Pipeline technology advances DataOps, Ashutosh said, by making it easier to copy a virtual instance of a data set running in a production environment and update it with the most recent copy of that data at any point in time. That capability is not only being employed to, for example, copy data into the cloud, but also to make data readily accessible to DevOps teams as needed on a self-service basis, he said, adding the goal is to make it easier for developers to dynamically consume the latest version of any data set as needed, with a minimal amount of intervention required on the part of a storage administrator.

IBM plans to make an instance of Virtual Data Pipeline available as part of the IBM InfoSphere portfolio of data management software it provides. That agreement extends Actfio’s existing reseller relationship with IBM.

Ashutosh conceded there is much work to be done before DataOps becomes a natural extension of DevOps. Most storage administrators today are not all that familiar with how the data pipelines they create are consumed by applications. Most storage administrators continue to think in terms of volumes and files rather than in terms of managing data pipelines, he said.

But as those application environments become more dynamic thanks to the rise of microservices, pressure to modernize data management will only increase, Ashutosh noted. For example, more DevOps teams will be integrating the ability to copy data directly into their continuous integration/continuous delivery (CI/CD) platforms. Achieving that goal will be easier if the software employed to manage data within the context of a DevOps processes is invoked as a SaaS application, he said.

Most IT organizations are a very long way from melding DevOps and DataOps. Most are still struggling with mastering the fundamentals of DevOps. But the convergence of DevOps and DataOps is all but inevitable. The only thing that remains to be seen is the degree to which IT organizations will proactively seek to achieve that goal versus waiting for developers to force the issue.

— Mike Vizard

February 12, 2019
Red Hat Tightens CloudForms Integration with Ansible

Red Hat has tightened integration between CloudForms, its tool for managing IT infrastructure on-premises and in the cloud, and the its Ansible framework for automating IT operations.

Pete Cruz, product marketing manager for management for Red Hat, said version 4.7 of Red Hat CloudForms and Ansible together promise to make it easier to manage multiple IT environments running on-premises and in the cloud using a common set of tools. Most IT organizations today are trying to manage at least one public cloud alongside their existing IT environment. Rather than having to master a separate framework for each IT platform, IT organizations can employ multiple Red Hat tools and frameworks to unify the management of multiple clouds and their internal IT operations, said Cruz.

Version 4.7 of Red Hat CloudForms now makes it possible to execute Red Hat Ansible Tower workflows directly from CloudForms deployed on-premises. Those workflows can already be extended to include multiple clouds.

With this release of Red Hat CloudForms, Red Hat is continuing its effort to extend its reach into the management of networks and servers. CloudForms is now integrated with Lenovo Clarity, a set of systems management tools, and Nuage Networks’ Virtualized Services Platform (VSP). Integration with networking platforms is becoming increasingly pivotal because internal IT organizations are now being asked to be as agile as a cloud service provider, said Cruz, noting it’s not especially useful if an IT organization can spin up a virtual machine in a matter of minutes but must wait weeks as network services are provisioned manually.

Red Hat is trying to lay a foundation on top of which best DevOps practices can be extended across multiple IT environments. With each additional cloud service an organization adds, the less agile the internal IT organization becomes, unless it finds a way to centrally manage all the platforms being employed using a common set of tools, noted Cruz, and the only way to effectively manage IT at that level is to rely on automation frameworks.

Unfortunately, the number of organizations that are haphazardly embracing multiple clouds seems to outnumber greatly the number of organizations defining a strategy for unifying the management of hybrid clouds. But as the operational costs of managing multiple clouds becomes more apparent, the pressure to unify the management of multiple public clouds and on-premises IT environments inevitably will rise.

In the meantime, savvy IT leaders are trying to ensure their organizations don’t become overly dependent on any one cloud service provider. The deeper an IT organization dives into the management frameworks provided by cloud service providers, the more difficult it potentially becomes to move an application workload, should the need arise. It does not follow that because a workload was built on one platform it never will move off that platform.

Naturally, Red Hat, which is scheduled to be acquired by IBM, is not the only vendor with an eye on the rising need to unify the management of hybrid clouds. But the one thing that is certain is that even before the deal closes, Red Hat is aligning its portfolio to specifically address that opportunity.

— Mike Vizard

February 11, 2019
OverOps Employs Machine Learning to Measure Application Reliability

OverOps is adding a series of dashboards to its analytics platform that employ machine learning algorithms to identify which software application anomalies in a pre-production environment are likely to have the most impact on a production environment.

Company CTO Tal Weiss said one of the biggest challenges DevOps teams face is prioritizing which issues to fix first in an application. The Reliability Scoring capability being added to the company’s namesake platform for analyzing code employ machine learning algorithms to keep track of introduced errors, regressions and slowdowns during every phase of pre-production. In addition to enabling DevOps teams to visually identify the root cause of an issue via a single click, that data is then used to identify which issues will impact reliability.

Weiss noted that the Reliability Scoring can also be employed to set thresholds of acceptable application performance that would also be used to determine whether there is an issue. The data collected using that capability then can be fed back into a continuous integration/continuous deployment (CI/CD) platform to set up gates that would then prevent suspect code from being promoted, he said.

The primary benefit, however, should be a major reduction in the number of troubleshooting instances any DevOps team should need to engage in after an application is deployed in production, said Weiss. In fact, the Reliability Dashboards will provide a central mechanism through which developers, testing professionals and IT operations teams can collaboratively track and measure the progress of an application development project, he added.

The Reliability Scoring tool OverOps developed employs “micro-agents” that operate between application code and the hardware. Weiss said those micro-agents can not only capture data that was never previously available, they deduplicate, classify and gate critical issues as they move into staging and production. The Reliability Dashboards visualize that data in Grafana, a set of open source tools for visualizing data. DevOps teams can also opt to feed that data into any existing dashboards they may already have in place.

In general, Weiss said the metrics surfaced by the Reliability Dashboard are critical to justifying investments in DevOps over the long term. Organizations expend a lot of time and effort making the transition to DevOps. But most of them don’t really know to what degree they are getting better at building and deploying applications. Reliability Scoring dashboards provide the historical context required to make those assessments, he said.

Far too many DevOps teams are still starved for data needed to make critical decisions. In the absence of that data, teams address issues as they arise, rather than based on the impact they might have on the business. Worse yet, it’s difficult to identify new issues over those that might be another manifestation of a known issue that suddenly becomes a much higher priority.

Regardless of the root cause of any problem, however, DevOps teams would do well to remember things that get measured are usually the first things to get fixed.

— Mike Vizard

February 5, 2019
Cisco Opens IoT Development Center

Cisco Systems this week launched an IoT Dev Center as part of an effort to foster development of a new generation of applications that will be deployed at the network edge.

Announced at the Cisco Live EMEA event, the IoT Dev Center provides access to sandboxes and tutorials for building highly distributed IoT applications that Cisco envisions will be deployed directly on top of Cisco routers and switches. To facilitate that effort, Cisco also launched a series of ruggedized switches and routers, which, in addition to usingCisco ASICs for processing network traffic, can be configured to include x86 processors that enable low-latency applications to be deployed at the edge.

The Cisco IoT Dev Center also provides access to a DevNet Ecosystem Exchange, through which organizations will be able to discover IoT applications optimized for Cisco infrastructure.

Susie Wee, senior vice president for the DevNet community at Cisco, said the IoT Dev Center is an extension of the company’s ongoing efforts to build a DevOps community around Cisco infrastructure. From Cisco’s perspective, IoT represents an instance of edge computing.

Cisco is attempting to extend its current dominance over networking infrastructure to include both networking gear for IoT environments and two-node hyperconverged infrastructure (HCI) platforms intended to be deployed at the network edge. Each of those systems will be connected via the Cisco Application-Centric Infrastructure (ACI) software-defined network (SDN), which Cisco says enables intent-based networking when infused with advanced analytics.

Cisco claims it already has 40,000 customers using some element of its portfolio to drive an IoT application. As that ecosystem continues to evolve, Wee said it’s apparent that both operational technology (OT) teams, which historically have been responsible for embedded systems, and enterprise IT teams will need to embrace best DevOps practices to deploy, manage and update IoT applications. While embedded systems deployed by OT teams were not frequently updated, IoT applications will take advantage of containers and other microservices-based technologies to add new functionality more frequently and, when required, update systems to remediate potential vulnerabilities. By the end of the decade, many of those applications will be connected via 5G wireless networks that will provide enough bandwidth to make continuously updating edge applications much more practical than it is today.

Less clear going forward is the degree to which networking teams will become part of a larger DevOps teams. As more applications get deployed on switches and routers at the edge, it’s obvious networking teams will play a critical role. The issue is to what degree. In many cases, networking teams will attempt to provide developers with access to a defined set of resources they can access via a self-service portal. But there are also likely to be instances when developers will want programmatic control over network resources that can be invoked via application programming interfaces (APIs).

Naturally, Cisco is not the only networking vendor with similar edge computing ambitions. But while most IoT initiatives remain relative nascent, the next major battle for control over the network edge is more likely be determined by the sophistication of the processes enabled as it is the core underlying infrastructure.

— Mike Vizard

February 1, 2019
Salt Security Unveils Platform to Secure APIs

Salt Security, fresh off raising an additional $10 million in funding, announced a platform that promises to advance the state of DevSecOps by making it possible to detect when application programming interfaces (APIs) are being probed by cybercriminals looking for weaknesses to exploit.

Salt Security CEO Roey Eliyahu said the Salt Security API Protection Platform employs machine learning algorithms to first establish a baseline for how APIs are being invoked across an IT environment. The software-as-a-service (SaaS) platform then monitors activity to surface any anomalous behavior indicative of cybercriminals engaging in reconnaissance of API traffic flows, he said.

Armed with that analytics, DevOps teams can then prioritize fixes to any potential security hole cybercriminals might be able to exploit. That approach advances DevSecOps because the Salt Security technology makes it possible to feed requests to address those security issues directly into a continuous integration/continuous deployment (CI/CD) platform—critical, he said, because all too often developers are unclear regarding what cybersecurity professionals are asking them to fix whenever a cybersecurity issue arises.

Eliyahu noted that, in today’s business environment, security has become a major concern. According to the Open Web Application Security Project (OWASP), nine of the top 10 vulnerabilities in its current Top 10 report include an API component. Insecure APIs were ranked as the third most severe threat to cloud computing in 2018 by the Cloud Security Alliance (CSA), and Gartner predicts that by 2022 API abuses will be the most frequent attack vector resulting in data breaches for enterprise web applications.

The challenge organizations face is each API is unique to each application and the organization that builds them, which means each has unique logic and, by extension unique vulnerabilities, said Eliyahu. Existing cybersecurity tools lack granular understanding of these because they are designed to protect organizations from known attacks. Attacks that target API logic go unnoticed by these tools because they appear to be authenticated use cases, and then employ subtle methods to probe each for unique vulnerabilities, he noted.

To thwart those attacks, the Salt Security technology automatically discovers all APIs and associated functionality, said Eliyahu. That’s important because it’s not uncommon for organizations to lose track of the many that might have been exposed over the course of an application’s lifetime.

APIs in general are often overlooked because much of the focus in any organization tends to be on business logic. But as the number of applications and services continue to proliferate across the enterprise, the number of APIs being exposed has increased dramatically. Those numbers will increase more as organizations embrace microservices to build applications that are more easily updated.

The issue, of course, is how to secure APIs that often are developed and maintained by teams that weren’t involved in the integration of the original application. Because of that issue, API management has emerged as a discipline unto itself within many organizations. The challenge now is finding a way to ensure those APIs are employed as intended, versus becoming an avenue for data exfiltration that no one is aware of until it’s long too late.

— Mike Vizard

January 31, 2019
SolarWinds Survey Surfaces DevOps Disconnects

A survey of 336 developers, web product managers and DevOps practitioners published by SolarWinds, a provider of IT management tools, finds they spend most of their time troubleshooting applications—so much so that there is little time for strategic projects such as transitioning to DevOps practices.

Joe Kim, executive vice president and global chief technology officer for SolarWinds, said that while senior IT leaders continue to preach about the critical role DevOps will play in changing their IT culture, IT staff still spends too much time dealing with tactical problems to implement any of the goals defined within a longer-term strategic plan. More than half of respondents (53 percent) said troubleshooting application issues is the top task completed on a given day.

Because most of their time is spent on troubleshooting applications and not on managing and/or deploying applications, Kim said, many employees suffer from low morale. Then, before many IT leaders realize it, their best people are being lured away by the promise of working for an organization that enables them to focus more on the parts of IT process they enjoy, he said.

In fact, Kim noted, in this situation IT leaders that embrace DevOps are in danger of losing credibility. If IT leaders tout the benefits of DevOps, and yet the internal IT staff is spending most of their time on application troubleshooting, chances are good many of the rank-and-file IT professionals will conclude their leaders are out of touch with their everyday reality. IT leaders would be well-advised to engage more with their IT staffs to make sure their strategies are more informed by that IT reality, he advised.

The survey also finds respondents are spending less than 25 percent of their time proactively optimizing performance of their IT environments. Being able to spend more time on this aspect of IT is critical, because if more time is spent on proactively discovering issues, less time must be spent on troubleshooting, said Kim.

IT teams should also be trying to push the boundaries of IT automation to reduce as much of the manual drudgery associated with IT as possible, added Kim.

To get a better appreciation for real state of the IT environment, Kim advised IT leaders gather and share metrics with their teams. Not only does that provide IT teams with some sense of accomplishment as specific goals are achieved, the metrics make it easier to get IT teams to rally behind transitioning to DevOps best practices, he said. That’s crucial because any transition to DevOps is likely to fail because of cultural rather than technical challenges.

It’s unlikely the need to troubleshoot applications ever will go away entirely. The developers that create those applications, after all, are only human. But it is possible to make working in IT a lot more fun and rewarding than what most IT professionals currently experience today.

— Mike Vizard

January 28, 2019
Google Rolls Out Additional Cloud Certifications

Google is moving to address a chronic shortage of cloud skills necessary to advance DevOps.

Specifically, Google plans to add Professional Cloud Developer (GA), Professional Cloud Network Engineer (Beta), Professional Cloud Security Engineer (Beta) and G Suite certifications (GA) alongside Professional Cloud Architect, Professional Data Engineer and Associate Cloud Engineer certifications that already exist.

Google also plans to localize its cloud learning and certification programs in Japanese, French, German, Spanish and Portuguese to make them accessible to more people.

Rochana Golani, director of Google Cloud learning and enablement for Google, said Google is trying to increase the number of qualified engineers available to manage IT infrastructure as code. Most of the IT operations community is made up of IT administrators that don’t have much in the way of actual programming skills. The Google cloud certifications are all steeped in the site reliability engineer (SRE) principles that Google defined in 2003. As a more prescriptive instance of a DevOps practice, the goal is to make the skills needed to successfully transition to DevOps more widely accessible, said Golani.

Google is especially keen to increase the number of networking and security professionals that have demonstrated cloud skills, as the critical role these functions play in cloud application environments is often underestimated, added Golani.

Those challenges likely will only increase as organizations increasingly embrace microservices based on containers running on Kubernetes clusters that eventually will be tightly coupled to serverless computing frameworks. In fact, the first era of the cloud was defined by a comparatively simple replacement of virtual machines from on-premises IT environments with similar virtual machines residing on a shared public infrastructure. The next wave of the cloud is being defined more by so-called cloud native applications constructed using microservices. That approach is inherently more flexible from a business perspective, while paradoxically being more difficult to manage from an IT perspective.

On the upside, however, DevOps in general and SRE disciplines more specifically enable IT organizations to operate more hand in glove with the business as it grows and evolves.

Of course, none of that is achievable without the skills required to achieve that goal. Savvy IT professionals naturally will pursue certifications that enable them to earn higher salaries. But organizations that encourage their personnel to achieve those certifications should be able to at the very least engender more loyalty among IT professionals they help advance their skills.

In the meantime, it should be apparent that transformation is all but inevitable. Not every workload will move into to the cloud. But the principles applied to managing workloads in the cloud will be increasingly applied within on-premises IT environments. Those on-premises IT environments may not be as programmable and resilient as a public cloud, but the need to process data locally is not going to go away anytime soon. The challenge IT organizations are facing today is how best to define a set of best DevOps practices that can span both environments.

— Mike Vizard

January 24, 2019