devopsy.kinsta.cloud

Author: Mike Vizard

VMware CEO Stakes Out DevOps Position

At the Dell EMC World 2017 conference this week, VMware CEO Pat Gelsinger waded into an increasingly heated DevOps debate by suggesting that most developers are too “lazy” to be really interested in IT operations.

At a time when factions within the DevOps community are making the case for developers to be responsible for DevOps on an end-to-end basis, Gelsinger contends that most developers want to get out of being involved with IT operations as quickly as possible so they can spend more time developing applications.

The VMware approach to DevOps is closely aligned with Pivotal, a sister company operating under the Dell Technologies umbrella that curates an instance of the platform-as-a-service (PaaS) environment developed by the Cloud Foundry Foundation.

Gelsinger notes that the two primary reasons developers have shifted workloads to public clouds is perceived costs and the fact that invoking infrastructure as a service (IaaS) via an application programming interface (API) is simpler. To combat both those issues, Dell EMC has been rolling out preintegrated converged and hyperconverged infrastructure that, for certain classes of workloads, is less expensive to own over multiple years. Those systems are optimized to run either VMware or Microsoft virtualization software within a software-defined data center that exposes IT infrastructure resources via APIs. In effect, Dell EMC is applying a cloud operating model on top of IT infrastructure deployed inside the data center to close what Gelsinger describes as an “easy gap” between public clouds and internal IT operations. As those systems are more widely deployed, Dell EMC and VMware jointly contend that IT organizations will be in a better position to inject more agility into their DevOps processes.

Many IT operations professionals have a vested interest in the outcome of those efforts because developers have been doing an end run around internal IT operations teams by deploying applications directly on to a public cloud. The challenge VMware recognizes, says Gelsinger, is that the entire DevOps space currently is chaotic. Each IT organization not only has a different view concerning to what level of DevOps integration it wants to achieve, but none of them are at the same point in making that DevOps journey. In fact, there’s a raging debate over the merits of PaaS environments versus lighter-weight container-as-a-service (CaaS) environments.

Dell EMC, in collaboration with VMware and Pivotal, has invested heavily in a Cloud Foundry platform that it makes available as a Pivotal Cloud Foundry (PCF) offering is increasingly automated, from an IT operations perspective. The latest version includes a rolling update capability that requires no human intervention. Pivotal claims one financial services customer has deployed 10,000 application containers on an instance of PCF that is managed by only four IT operations people. Couple that level of automation with the automation that VMware and Dell EMC are driving into the underlying IT infrastructure, and it shows that DevOps will be profoundly different than today. Less clear is who inside the IT organization will be exactly managing what.

— Mike Vizard

May 12, 2017
Quali CloudShell Rises to Multi-Cloud DevOps Challenge

Multi-cloud computing is now an everyday reality for most IT organizations. Because of that, most DevOps teams are trying to figure out how to apply a repeatable set of processes against multiple clouds; rather than having to manage a unique pipeline for each cloud, DevOps teams want to be able to deploy application workloads on any cloud as necessary.

With that goal in mind, Quali has extended its CloudShell tools for modeling production environments in a sandbox to include support for both Azure and OpenStack environments. Previously, CloudShell only supported Amazon Web Services (AWS) and VMware.

Shashi Kiran, chief marketing officer for Quali, says version 8.0 of CloudShell makes it possible for developer, test, QA and compliance teams to create a truly authentic replicas of a production environments. That replica can then be used to create a blueprint of an application spanning all the physical or virtual infrastructure, data, applications, tools and services in that environment.

CloudShell 8.0 also includes support for application configuration management using either a custom script or playbook created using the open-source Ansible IT automation framework. In addition, DevOps teams now can edit some app details directly within blueprints.

Via a CloudShell web portal, shells now can be centrally managed, updated and removed. The new version also offers enhanced single sign-on (SSO) support, enabling more SAML security features and integration with third-party identity management tools. Finally, CloudShell 8.0 includes increased control of blueprint max reservation time, advanced search improvements and access to new table views.

Kiran says CloudShell is unique in that it gives DevOps teams access to a model that eliminates the surprises that commonly occur when developers attempt to move an application into a production environment. Given the level of scale involved in modern applications, it’s not possible for developers to effectively replicate a production environment on their own machines. The result is a lot of rolling back of applications after they’ve been deployed into production. CloudShell eliminates that problem, says Kiran, by giving developers and IT operations teams access to a sandbox in which to make sure that applications work as expected once they are deployed in production.

Rolling back applications in a multi-cloud world has become especially problematic. IT organizations now need to deploy applications locally on a private cloud and in a public cloud. But from an IT operations perspective each of those clouds is becoming more complex, which means the opportunity is greater for something to go awry when it comes time to deploy an application into production. Include the number of target platforms in the age of the cloud and the probability that an application will work seamlessly the first time it’s deployed is virtually nil. Multiply all the application deployments and updates an IT organization is trying to manage, and it quickly becomes apparent how much time and effort is being lost.

Production environments need to be as pristine as possible. The only way to make sure they remain that way is to make sure that every application that runs on them doesn’t ever get the chance to adversely affect their condition.

— Mike Vizard

May 10, 2017
AWS Extends DevOps Ambitions via Managed Services

Amazon Web Services (AWS) is signaling its increased interest in providing managed services spanning multiple aspects of DevOps with the launch of service that promises to make it easier to set up development projects.

At a recent AWS Summit conference in San Francisco, CTO Werner Vogels described AWS CodeStar as a means for building pipelines using templates that span more than 90 different AWS services. The templates currently support five different programming environments: JavaScript, Java, Python, Ruby and PHP.

CodeStar automates configuration of a continuous delivery pipeline for each project using CodeCommit, CodeBuild, CodePipeline and CodeDeploy, as well as providing integration with Atlassian JIRA Software for tracking issues via the CodeStar console. There also is a preconfigured project management dashboard for tracking activities such as code commits, build results and deployment activity.

Over the past couple of years, AWS has expanded the number of managed services it provides considerably, including databases and now various classes of machine- and deep-learning algorithms exposed as a service. In most of those cases, it is replacing a task that previously was performed by IT operations staff with an automated service. That may appeal to IT organizations that have standardized completely on AWS. But in a multi-cloud world where elements of applications are deployed both on-premises and across multiple public cloud services, it remains to be seen the degree to which organizations will want to employ managed services that only automate AWS processes.

One thing’s for certain: DevOps processes across multiple computing environments are becoming more automated. As microservices architectures become more widely employed, many organizations in the months and years ahead will become a lot more comfortable mixing and matching various cloud services as they see fit. Within that context, automation of DevOps processes will need to be multiplatform almost by definition. As a set of services exposed via application programming interfaces (APIs), it may very well turn out that the automated managed services provided by AWS can be programmatically invoked by other DevOps management frameworks.

Of course, there are plenty of organizations that, for now at least, have standardized on AWS. DevOps delivered as a managed service by AWS clearly has some appeal for those organizations. But as cloud computing continues to mature, the number of organizations employing only one cloud service is expected to decline.

While the battle of control of the cloud has been mainly focused on developers, more attention now is being paid to how application development pipelines get managed in the age of the cloud. Each IT organization will have a unique set of processes and requirements for managing those pipelines. In fact, the issue going forward will be to what degree can cloud service providers (CSP) adapt to those processes versus making the IT organization adapt to the CSP.

In the meantime, IT organizations would be well-advised to establish the roles and functions they need to manage those automated pipelines sooner than later.

— Mike Vizard

April 25, 2017
Veracode Makes DevSecOps Transition Easier for Developers

Following the formal acquisition of Veracode by CA Technologies, a much bigger effort to make security a more integrated element of DevOps has kicked off in earnest.

Veracode recently unfurled an update to its application security platform aimed specifically at developers that provides security findings as each application module is scanned. Tim Jarrett, senior director of enterprise security strategy for Veracode, says the idea is to provide developers with that information from static analysis delivered via the Veracode platform as early in the application development lifecycle process as possible.

Other new capabilities include support for custom cleansing functions to automate remediating issues involving common known vulnerabilities and an auto-scan capability that gets implemented any time a file is saved.

Also with this release, Veracode is adding support for the Perl programming language that is still widely used for building web applications.

Jarrett notes that organizations these days are holding developers more accountable for security issues that are easier to fix during the application development process. Addressing those same issues after an application is deployed in production not only exposes organizations to security threats, but can be much more expensive to fix.

The challenge is that most organizations have yet to solve the riddle for getting developers to address security issues earlier in the application development cycle. Jarrett says far too many developers are conditioned to view IT security has being someone else’s job inside the organization. Veracode is trying to make it simple to address security issues using tools that make the process as frictionless as, say, relying on a spell checker to publish a higher-quality document.

Obviously, there will never be perfect security. But far too many of the issues that IT security teams regularly deal with relate to known exploits. At a time when cybercriminals are making use of a variety of automated tools to discover those exploits, most IT security teams are outgunned. Worse yet, many IT organizations can’t even find qualified cybersecurity professionals to hire in the first place.

On the plus side, however, as DevOps processes mature, many developers are now assuming complete responsibility for the maintenance of the code they write, including all security issues. This not only leads to higher-quality applications, it also results in those developers being more vigilant when it comes to address security issues they would otherwise need to address themselves once an application is deployed in production. In some quarters, this earlier focus on security in the application development and deployment process is referred to as DevSecOps. As a discipline within most IT organizations, however, DevSecOps remains relatively nascent.

Of course, regulatory bodies are increasingly treating organizations that fall prey to security attacks less like victims. Instead, they are holding them accountable for ignoring best security practices by assessing fines for losing control over sensitive data. As those fines increase the blame for incurring those fines eventually cascades back to the developer. Given that changing climate, it might not be too long before developers recognize that embracing DevSecOps is in their own best interests.

— Mike Vizard

April 11, 2017
AppDynamics Extends Performance Monitoring Reach to Developers

AppDynamics, fresh off its acquisition by Cisco Systems, this week moved to extend the reach of its monitoring services all the way out to individual developers.

The spring 2017 edition of the AppDynamics service now includes a developer toolkit intended to make it simpler for developers to track the performance of their code without having to get that data from an IT operations team.

Matt Chotin, senior director of Developer Initiatives for AppDynamics, said the goal is to respond to the needs of developers who, in the age of DevOps, increasingly are being held accountable for the performance of their applications end to end. The toolkit enables those developers to directly invoke application programming interfaces (APIs) exposed by AppDynamics.

The toolkit also provides additional AppDynamics support for the Go programming language, the Xamarin framework used to develop mobile applications and a plugin for Android applications. Now also available are dashboards for tracking individual session and crash alerts and reports that make it possible for developers to discover the root cause of a potential issue much closer to the time it occurs.

But Chotin said the most unique attribute of the AppDynamics release is that developers can apply diagnostics to business transactions in two modes. One mode enables developers to examine code in pre-production and production environment, while another—a Live Mode—can be used against live application data.

In addition to extending its reach out to developers, AppDynamics is making it easier for IT organizations to deploy its agent software. A new Universal Agent makes it simpler for the AppDyamics controllers to distribute those agents. Chotin said AppDynamics is also working on developing lighter-weight agents that would be used to provide better support for containerized applications.

Finally, AppDyanmics is also simplifying its software licensing model in a way that enables sharing subscriptions.

While AppDynamics has developed an extensive following among IT operations teams, reaching out to developers represents a new frontier. As responsibility for application performance shifts in the age of DevOps, Chotin said AppDynamics is discovering the developers want to be able to access directly the metrics that apply specifically to their code. Instead of being presented with information about every application running in the environment, developers want to be able to zone in on any and all issues affecting their specific code, he said.

Obviously, not every IT organization is implementing DevOps processes to the same level of zeal. In many cases, IT operations teams are still mainly held responsible for application performance. But as the line between those IT operations teams and developers continue to blur, any move to embed instrumentation functions deeper into the application code base stands to benefit everyone. Of course, not every developer might be excited about being required to do that initially. But once they discover that the time between when there’s an issue and they can go back to writing code starts to drop, AppDynamics is betting that many of them are likely to insist on that level of instrumentation being available.

— Mike Vizard

April 7, 2017
DevOps Job Titles Emerging in Enterprise IT Organizations

IT job functions and, by extension, individual titles inside the classic enterprise have been relatively constant. Various hierarchies of developers labored separately alongside IT operations teams that focused mainly on infrastructure. However, the emphasis on continuous integration and continuous development (CI/CD) within the context of a modern DevOps environment is starting to blur the lines separating who does what inside these organizations. In fact, Phil Guido, general manager of IBM Global Technology Solutions in North America, says new titles such as DevOps engineer and Scrum Master, which better reflect new roles many IT professionals taking on, now are emerging.

At the crux of this shift is the rise of programmable infrastructure coupled with a need for IT organizations to be more agile. Instead of rolling out a few applications and associated updates a year, IT organizations today are being urged by business leaders to roll out more applications and updates at a pace associated more often with web-scale companies than the classic enterprise. Much of that demand emanates from shareholders and Wall Street to accelerate investment in digital business initiatives that generate higher-margin revenue.

To achieve those goals, enterprise IT organizations are trying to emulate as many of the DevOps processes employed by web-scale companies. For example, web-scale companies make extensive use of CI/CD technologies and processes to roll out as many new applications as fast as they possibly can. Overseeing those processes are developers who now are accountable for not just writing but also maintaining the application. The theory is that if developers are held accountable for the quality of the application, they will focus more on making sure that application attains a level of quality. The trick is to empower those developers to own everything from the code itself to the programmatic infrastructure it runs on. Because of that requirement, many of those developers adopted a “cloud first” mentality because deploying applications on a public cloud such as Amazon Web Services (AWS) eliminated the need for those developers to engage with IT infrastructure professionals altogether.

However, most traditional enterprise IT organizations have a much smaller number of application developers. Every minute those developers are not writing code reduces the number of applications an enterprise can roll out. Because of that issue, many enterprises have been trying to find a way for existing IT operations teams and developers to work together hand in glove.

That requirement, Guido says, is creating a lot of demand for advice from IBM about how to manage DevOps. IBM advises organizations to go slow to ensure they have a few quick successes under their belts before propagating DevOps across the entire organization, he notes. If an organization tries to do too much or move too fast, there’s a good chance that employee resistance to change will only increase. Above all, Guido says, organizations should avoid being too prescriptive in how they define DevOps.

Of course, not everyone agrees that changing job titles is always the best way to go about fostering change. But human nature being what it is within large organizations, some job titles will have to be reclassified to bring about permanent change.

— Mike Vizard

February 8, 2017
AppDynamics Buy Expands Cisco’s DevOps Agenda

AppDynamics’ $3.7 billion acquisition by Cisco Systems has two major implications for the DevOps space. On a tactical level, Cisco has committed to distributing AppDynamics’ agent software everywhere from the public cloud to individual devices connected to the Internet of Things (IoT) and in between. On a more strategic level, the company is positioning itself to be able to uniquely correlate IT operations data generated by applications and IT infrastructure to give organizations comprehensive visibility into their entire DevOps environments.

During a briefing with analysts and the media this week, Rowan Trollope, senior vice president and general manager of Cisco’s IoT and Applications Business Group, described how his company sees AppDynamics as a linchpin acquisition that propels the company well beyond its well-established networking and server infrastructure base. After the merger is completed, expected sometime in the third quarter, AppDynamics will continue to operate as an independent business unit within the IoT and Applications group, and current AppDynamics CEO David Wadhani will report to Trollope.

Trollope described AppDynamics as a complement to Cisco’s ongoing efforts to drive more recurring revenue. The company, which offers an application monitoring service delivered via the cloud, was poised to shortly go public prior to being scooped up by Cisco. AppDynamics is employed mainly by IT organizations to monitor applications running on public clouds. But Wadhani noted one of the fastest-growing segments of AppDynamics’ business is monitoring applications running in private clouds.

The data AppDynamics gathers in those environments can be correlated against, for example, the data Cisco collects via its Tetration analytics application, which the company launched last year. That capability, Trollope said, will significantly increase the total Cisco value proposition.

In fact, as hybrid cloud computing scenarios based on microservices and containers become more common, Wadhani noted that monitoring of complex applications running in production across multiple clouds will become a more crucial requirement. AppDynamics recently extended its monitoring service to include support for containers deployed in these environments.

Under the leadership of CEO Chuck Robbins, extending Cisco’s reach across the enterprise has become a high priority. Cisco recently abandoned a cloud interoperability service strategy. But its acquisition of AppDynamics suggests the company is shifting its focus to higher-margin software that generates recurring revenues across multi-year contracts.

Following the acquisition, Trollope said Cisco also plans to take advantage of its existing relationships with senior business and IT leaders to advance a vision of DevOps that provides organizations with visibility all the way down to how each customer engages with their IT resources. The issue Cisco needs to navigate is the degree to which those senior executives actually exercise control over DevOps. To date, DevOps has been more of initiative led by developers and IT operations staff than mandates from senior executives.

Wadhani said Cisco’s direct and indirect sales staff should significantly expand the number of organizations that are exposed to AppDynamics services. That means one way or another, DevOps is about to become a much broader discussion across the enterprise.

— Mike Vizard

January 26, 2017