Category: News

  • Microsoft Woos Development Partners

    Microsoft Woos Development Partners

    If Microsoft has its way, many more DevOps processes will revolve around the cadence at which the company upgrades its applications. At its Inspire 2017 conference, the tech behemoth announced an ISV Cloud Embed initiative designed to entice more developers to add value by extending application functionality it has already developed and deployed in the cloud.

    Rather than reinvent the same functionality over again, Microsoft will provide developers with access to its application at price points that are as much as 50 percent less than what an end user might pay, notes Alysa Taylor, general manager for Microsoft Business Applications and Industry. In addition, the company is promising to help software developer partners reach 100 million commercial active users of Office 365 and Dynamic 365 customers through the Microsoft AppSource online store.

    The specific software modules the company is providing developers access to under this program include:

    • Dynamics 365 Embedded: a suite of business applications the company is hoping third-party developers will customize and extend across a variety of vertical industries.
    • Microsoft Flow Embedded: Makes it possible to customize workflows to automate business processes within their application.
    • PowerApps Embedded: Provides access to extensions that make it easier to deliver an application via a browser or as a mobile application.
    • Power BI Embedded: Allows users to easily embed fully interactive reports and dashboards.

    This latest initiative is a logical extension of the work the company has been doing to entice developers to employ Microsoft Office as the front end for accessing a wide variety of back-end services.

    The challenge IT organizations that go down this path will face is aligning the pace of DevOps with the rate at which the company is updating its applications.

    Microsoft is not the only IT vendor that presents this DevOps challenge. The more a software developer invokes APIs, the more complicated managing the DevOps process can become. The whole concept of continuous integration/continuous deployment (CI/CD) can get sorely tested when control over when the back-end services being invoked via an API are updated.

    In effect, software developers are being asked to make a buy-versus-build decision. To entice developers to make a buy, the company not only provides a common API framework, but also developers will be able to take advantage of any investments it makes in artificial intelligence across the entire Microsoft application portfolio.

    Taylor says Microsoft is committed to working with partners to eliminate any competitive friction. The company is in the process of implementing a massive reorganization under which the company’s core technology groups are being aligned around four technology groups: Modern Workplace, Business Applications, Applications and Infrastructure, and Data and AI. The rest of the company is then being organized around a go-to-market strategy that is focused on education, financial services, government, healthcare, manufacturing and retail industry segments. Microsoft is looking for partners that can apply their own intellectual property to extend its core applications into each of those segments, says Taylor.

    It remains to be seen just how well partnering with Microsoft can work on a practical DevOps level. But the one thing that is clear is that there will be no shortage of software developers who are about to find out.

    — Mike Vizard

  • CircleCI Injects Workflow Flexibility into CI/CD Platform

    CircleCI Injects Workflow Flexibility into CI/CD Platform

    Nobody likes to be told how to get a specific task or job done. In fact, it’s arguably that very sentiment that holds backs adoption of DevOps processes inside many IT organizations. Aiming to provide IT organizations with a more flexible approach to DevOps, CircleCI has updated its continuous integration and continuous deployment (CI/CD) software to give IT organizations more granular control over workflows within a DevOps environment.

    CircleCI CEO Jim Rose says the issue with most CI/CD frameworks is that they are too monolithic. Rather than allowing IT organizations to apply different types of workflows against various types of scenarios, Rose says most CI/CD platforms are too prescriptive in how they define workflows.

    To provide some additional flexibility, version 2.0 of the company’s namesake CI/CD platform provides IT organizations with the ability to employ different types of workflows whenever appropriate, including:

    Sequential job execution: Provided in the first release of CirceCI, this class of workflow is optimal for approaching jobs in a lockstep build-deploy-test model.

    Parallel job execution: Allows IT organizations to run multiple jobs simultaneously in a way the resolves dependencies before deployment.

    Fan-in/fan-out in a repo: Ideal for a more complex build orchestrations involving different test suites against commits to get faster feedback.

    Branch-level filtering for job execution: Allows deployment of code off specific branches.

    Job execution from failed and job execution from start: Allows IT operations teams to choose where and how build reruns are implemented to save repeating unnecessary jobs. IT allows IT operations teams to start jobs from the last failed job, instead of rerunning every job or stage.

    Rose says the rise of microservices has begun to stress CI/CD platforms that were not designed to scale to support environments where Docker containers in any given microservice often are replaced. Any change to an element of microservice is likely to have a significant impact upstream and downstream. Rather than having to continually rerun every job, Rose says CircleCI now enables IT organizations that have embraced microservices to respond more adroitly to changes in the overall environment.

    In an ideal world, DevOps processes lead to faster rollout of new applications and updates. In reality, however, there are more dependencies than ever. Rose contends that CI/CD platforms need to evolve to the point where they can allow IT operations teams to cope with accelerated rates of change instead of becoming a bottleneck. The irony of that, of course, is that CI/CD platforms were adopted to eliminate bottlenecks. But as microservices architectures continue to evolve, in many cases the CI/CD platform has become a new bottleneck.

    It’s too early to say what impact microservices will have on DevOps. There’s no doubt that adoption of microservices will finally force the DevOps issue inside many organizations. But at the same many organizations that have already gone down the CI/CD path may soon find that some of their initial assumptions about what the word “continuous” meant were considerably misguided.

    — Mike Vizard

  • How AI Impacts DevOps Pipelines

    How AI Impacts DevOps Pipelines

    The rise of machine- and deep-learning algorithms is about to create some interesting data-gravity challenges for IT operations teams. Over most of the last decade IT operations teams have been caught up in a public- versus private-cloud computing debate that has mostly been species. The truth is that most organizations wind up employing both. But as IT organizations are just now getting used to that multi-cloud reality, the rise of machine- and deep-learning algorithms to create a new generation of advanced artificial intelligence (AI) applications are about to add some significant nuances to managing the DevOps pipeline.

    New applications tend to be built and deployed where they can access the most relevant data. Most of the data employed by the average enterprise resides on-premises today. But it’s clear that the data being created in various types of cloud services is growing at a faster rate, thereby altering data gravity forces across the enterprise.

    To get the most value out of that, developers are now building a new generation of advanced applications that employ machine- and deep-learning algorithms. In most cases those algorithms are being deployed wherever data happens to reside. For example, Salesforce just announced at its Salesforce TRAILHEADX 2017 conference that it is making available additional APIs to the Salesforce Einstein Platform Services for building custom applications that can now be infused with sentiment analysis, the ability to detect objects and understand customer intent.

    Michael Machado, director of product management for Salesforce Einstein, says that the success of any AI initiative will come down to both the amount and quality of the data being accessed. As a CRM application consisting of a mix of structured and unstructured data concerning customers, Salesforce represents an attractive platform for building AI applications. In fact, to facilitate the building of applications, Salesforce also is making it simpler for developers to collaborate across multiple alliances in addition to providing access to DevOps tools from Atlassian and Github.

    But CRM applications are only one element of the typical application portfolio. The more data that any set of algorithms can be applied against, the faster the application learns and the more accurate it becomes. As developers build the next generation of applications, they are going to want to be able to access as much data as possible. For many IT organizations, that will mean the applications will be hybrid almost by definition—attempting to centralize all their data will prove to be impractical as well as prohibitively expensive. Constructing application pipelines spanning multiple data sources, however, requires a very mature set of DevOps processes.

    Arguably, the rise of these next-generation applications might finally force the DevOps issue inside most organizations. Most have been able to manage application development on various cloud platforms in isolation. Going forward, that may no longer be practical, as developers seek to incorporate more data sources within their application environment. The challenge IT operations teams will need to wrestle with is providing timely access to that data in way that doesn’t ultimately compromise their performance.

    — Mike Vizard

  • Riverbed Aims to Unify App, Network Performance Management

    Riverbed Aims to Unify App, Network Performance Management

    Much of the initial focus on DevOps has been on accelerating the rate at which applications are built and deployed. But once those applications are deployed, it’s not too long before the focus shifts to the quality of the end-user experience. Aiming to make it easier to determine what the quality of that experience really is, Riverbed Technology has launched a Digital Experience Management initiative based on the SteelCentral management platform.

    Erik Hille, director of product marketing for Riverbed, says the latest release of SteelCentral provides tighter integration between SteelCentral Portal and the SteelCentral Aternity end-user monitoring tool and SteelCentral AppInternals, an application performance management (APM) platform. The goal, says Hille, is to make it easier for an organization to holistically manage individual end-user experience by correlating information at the device, network and application levels. As part of that effort, Riverbed also has integrated the workflow between SteelCentral Aternity and AppInternals to create an integrated monitoring system.

    Hille says IT operations teams can use a comprehensive approach to managing digital experiences that can be set up in fewer than 10 days. Once in place, IT operations teams can more quickly identify the root cause of any issue by correlating application, device and networking data through a single pane of glass. In addition, Riverbed is employing REST APIs to make it possible to consume alerts generated by collaboration tools such as Slack and HipChat. IT operations teams can not only automatically open incident management tickets, but also collect additional metrics via those APIs.

    Riverbed is also providing integration between NetProfiler, a network performance monitoring tool, and NetIM, a network device management tool, to provide more visibility into how network infrastructure impacts network performance.

    Hille notes that most IT operations teams are swiveling between different sets of tools to correlate the same information. The problem is that as more organizations strive to become a digital business, any performance issue has a direct impact on customer satisfaction and the amount of revenue being generated. Faced with that increased business pressure, Hille says IT organizations need to re-evaluate legacy approaches to IT operations based on silos. The goal should be to implement a more proactive approach to IT focused on proactively preventing issues from occurring or escalating, versus merely reacting to isolated events as they occur.

    One of the few things in DevOps that developers and IT professionals can agree on is that whenever there’s an issue, it’s the fault of the network guy. That’s not always true, but it does take networking professionals a long time to prove their innocence. Until then, there’s a tendency to assume their guilty until proven otherwise. Obviously, that kind of bias isn’t in keeping with the whole spirit of integrated DevOps. A more comprehensive approach to application and networking performance management should go a long way toward reducing the amount of finger-pointing inside any organization.

    There will never be a perfect IT environment. The goal is to discover issues before the end-user notices—and, failing that, resolve that issue in as little time as possible. Any argument about what exactly happened to cause the problem can occur at a later date and time.

    — Mike Vizard

  • Fleetsmith Pulls Apple into DevOps Orbit

    Fleetsmith Pulls Apple into DevOps Orbit

    For too long now Apple Macintosh systems have been the proverbial red-headed stepchild of DevOps. There are a lot of ways to incorporate Windows systems automatically into a larger DevOps pipeline, but Macintosh systems generally require a lot of manual intervention.

    As part of a larger effort to automate application deployments across Apple systems, Fleetsmith has announced that the platform it created for automating the management of Apple systems now supports both the Puppet and Chef automation frameworks. DevOps teams looking to extend the reach of those frameworks to Apple systems can now invoke Fleetsmith to automate the deployment of Chef and Puppet like any other Macintosh application.

    Of course, once Puppet or Chef are installed, IT organizations can control what gets deployed on those systems going forward. But in general, organizations that deploy Macintoshes prefer to employ tools that provide a native Macintosh experience when it comes to managing those systems, says Fleetsmith CEO Zack Blum. There are plenty of options when it comes to cross-platform management tools, but Blum notes each of the tools compromises the Apple Macintosh experience such that individuals who prefer Apple systems must manage those systems using a construct that was not primarily designed for use in, for example, a Windows environment.

    Over the years, a number of developers have shown a marked preference for Apple Macintosh systems. As a result, it’s difficult to develop a coherent approach to DevOps that does not include some way to automate the management of those platforms, including the ability to deploy DevOps tools such as Puppet and Chef. Blum says that, in time, Fleetsmith plans to increase the number of Macintosh applications that can be distributed via its platform.

    Naturally, Apple is too focused on the end-user experience to trifle with IT management issues. It prefers to leave those issues in the hands of partners such as Fleetsmith, JAMF Software, IBM and SAP. The other alternative is to rely on open-source software that has been created to address this same issue. But Blum says open-source alternatives are more complex than commercial software, while rival commercial approaches to provide the same level of fleet management of Apple system at scale.

    Fleetsmith was developed when its founders worked at Dropbox and Fandom. Both organizations had evaluated several Mac management options before deciding to develop their own code. The company launched last fall with $3.1 million in funding.

    Pricing for the service, which officially is still in beta, is $10 per month per device. The service is free for any organization with fewer than 10 Apple devices. In addition, Fleetsmith integrates with Google G-Suite to make it simple to authenticate users of the service.

    Obviously, there’s more to be done in terms of pulling Apple devices into the greater DevOps ecosystem. But as a first step, making it simpler to deploy Chef and Puppet on these systems signals greater awareness of the overall issue.

    — Mike Vizard

  • Cisco Looks to Bridge Gap Between Networking and DevOps

    Cisco Looks to Bridge Gap Between Networking and DevOps

    Networking in the enterprise has always stood apart. It might take two minutes or less to spin up a virtual machine, but it can take two weeks to set up the network connections. To help bridge some of the gaps between networking and the rest of the DevOps team, Cisco Systems this week unveiled a series of intelligent switches that promise to do just that.

    Via a Cisco intent-driven networking initiative, it soon will be possible to describe a business outcome that will be automatically enabled at the networking level, says Kiran Ghodgaonkar, senior marketing manager for Cisco. To achieve that goal, Cisco is moving to unify networking on an end-to-end basis, which Ghodgaonkar says primarily will require building a common controller that can be implemented at both the edge of the network and in the data center.

    The first concrete step in achieving that goal is a set of Catalyst 9000 switches running an IOS XE operating system, which Cisco has imbued with machine learning algorithms. Over time, those algorithms will be deployed across both legacy networking infrastructures when appropriate, as well as any new networking and security equipment Cisco brings to market in the future. Once in place, IOS XE will make it easier to implement policies in software that spans everything from prioritizing traffic to implementing security polices.

    This latest Cisco initiative follows the rollout a Tetration analytics platform based on an instance of Apache Spark and Cisco’s acquisition of AppDynamics, provider of an application performance management service delivered via the cloud. Ghodgaonkar says Cisco is aiming to combine analytics and machine learning algorithms to simplify network management in a way that furthers DevOps integration. Right now, however, the biggest impedance to achieving that goal, says Ghodgaonkar, is the fact that 80 percent to 90 percent of networking tasks still require manual intervention. Because of that issue alone, many organizations have experienced limited success in terms of integrating server, storage and networking management, despite the rise of software-defined networking (SDN) in the data center. In fact, to get past that issue, many organizations make investments in pre-integrated systems such as the Cisco Unified Computing System (UCS) platform. But the number of organizations willing to make that kind in forklift investment in IT infrastructure is not all that high when compared to the size of the overall IT market.

    The biggest DevOps issue IT organizations now face, says Ghodgaonkar, is that as various elements of the IT organization invest in automation, silos of automation are created. Cisco says it has developed open application programming interfaces (API) will provide interoperability between its technologies and the rest of the IT environment to help break down those silos.

    It’s still a little unclear these days just how much networking and IT operations can get automated. The good news is that, given the state of network management inside most organizations, things can only improve. The real issue (as any existing DevOps team already knows) may not be so much the technology as it is the culture differences spanning the compute, storage and networking teams.

    — Mike Vizard

  • BMC Pushes Automation to the DevOps Left

    BMC Pushes Automation to the DevOps Left

    Much of the inherent conflict that exists between developers and IT operations teams often comes down to how IT automation processes are implemented. IT operations teams generally have their own preferred tools for automating operations while developers have another. To resolve that issue, BMC Software unveiled Control-M Workbench, a set of development tools that extends an application programming interface (API) to allow developers to embed instructions for automating infrastructure using BMC Control-M automation platform.

    Gur Steif, president for digital automation at BMC Software, says Control-M Workbench moves the responsibility for automating the IT infrastructure resources that their application consumes, including the ability to code, debug and test workflows. The IT operations team can then more easily deploy that application in a production environment, he says.

    In effect, BMC Software is enabling IT organizations to put the control of how jobs are executed in a production environment in the hands of developers by moving that function further to the left of the DevOps life cycle. Control-M Workbench represents the first time BMC is venturing beyond its traditional IT operations base to create a tool that will primarily be employed by developers.

    Steif says the goal is to enable IT operations teams to manage much higher volumes of application rollouts. In return for spending a few minutes on installing Control-M Workbench, IT organizations can deliver application 20 percent faster, while running jobs using 50 percent fewer full-time employees. In addition, Stief says production incidents can be reduced by up to 25 percent and batch processing failure rate can drop by as much as 80 percent.

    Control-M Workbench is clearly part of a trend to give developers more control over and responsibility for IT operations. A recent survey of 650 IT decision makers conducted by BMC finds 94 percent of IT decision makers expect automation to spread into all other areas of business by 2020.

    In addition, the survey notes that 73 percent of IT decision makers believe businesses that do not embrace IT automation to achieve the larger digital business strategy within the next five years will cease to exist in 10 years. The top three areas of investment priority in the next 24 months to achieve those goals are containerization, workload automation/scheduling and DevOps. Almost 9 in 10 (89 percent) respondents concur that IT automation needs to achieve their desired digital business objectives.

    However, there are considerable obstacles that need to be overcome, including lack of budget (67 percent), skills (44 percent) and time (51 perent). In fact, 42 percent of the respondents concede that when it comes to digital business initiatives there are conflicting objectives between business units and CIOs that can get in the way of crafting a comprehensive IT strategy.

    DevOps, of course, is more about people and processes than it is technology. Then again, DevOps isn’t going to be willed into existence without providing the tools needed to change the processes. Given the chicken-and-egg relationship between processes and tools, it becomes incumbent on the IT leadership to serve as the catalyst for bringing it all together.

    — Mike Vizard

  • Microsoft Lifts Investment in Cloud Foundry

    Microsoft Lifts Investment in Cloud Foundry

    At the Cloud Foundry Summit Silicon Valley 2017 conference this week Microsoft formally pledged its support for the open-source platform-as-a-service (PaaS) environment by becoming a gold member of the Cloud Foundry Foundation (CFF).

    Beyond influencing the future direction of the Cloud Foundry PaaS, Microsoft also revealed this week it will tighten the integration between the Cloud Foundry PaaS running on Microsoft Azure and backend database services. There also now command line tools for Cloud Foundry available within Azure Cloud Shell, a browser-based tool for managing Azure resources.

    Corey Sanders, partner director for Microsoft Azure, told conference attendees that Microsoft is fully committed to Cloud Foundry as any member of the foundation. In fact, there have been instances of Cloud Foundry running on Azure for years, including the version of Cloud Foundry that SAP makes available as part of a multi-cloud computing strategy it has crafted. Microsoft claims usage of Cloud Foundry on Azure has increased 300 percent over the last year.

    CFF CTO Chip Childers says that endorsement of Microsoft is significant because, along with Google, it means two of the three largest public cloud providers are now investing in Cloud Foundry. There are instances of Cloud Foundry running on Amazon Web Services (AWS), but the largest public cloud service provider has not seen fit to join the CFF.

    The mission of CFF is to promote the adoption of multi-cloud computing via technologies that can be deployed across both public clouds and an on-premises IT environment, Childers says. He expects Cloud Foundry and the Kubernetes container orchestration engine to play similar roles in that regard. The actual operating system deployed in those environments, he says, is now much less relevant. The choice regarding when to deploy one or another will come down to the nature of the application workload and the relative cloud-native maturity of the organization deploying those workloads.

    Microsoft has already made it clear it it is committed to offering multiple classes of services with Azure. In addition to Cloud Foundry, Microsoft already offers a PaaS environment built on its own proprietary stack of Windows software. There’s also both a container-as-a-service offering based on Kubernetes and implementations of the container stack developed by Docker Inc., in the wake of a strategic alliance between those two companies.

    Obviously, the range of deployment options now being made available on platform such as Microsoft Azure creates some significant DevOps challenges. Rather than trying to limit the number of services developers might invoke, IT operations teams will need to focus more on making sure the right type of application workload invokes the class of cloud service that is best optimized for that workload. Naturally, that approach will require IT organizations to address both technology and cultural issues within their organizations. But given the limited effectiveness most IT operations teams historically have had in terms limiting deployment options, there’s no better time than the present to get started.

    — Mike Vizard

  • Atlassian Builds a DevOps Stack for the Enterprise

    Atlassian Builds a DevOps Stack for the Enterprise

    One of the major challenges associated with DevOps is that it’s not something an enterprise IT organization can buy. Because of that issue, it’s often challenging for IT organizations to forecast what types of DevOps tools they are going to need. To make it a lot easier to cope with that issue, Atlassian has announced Atlassian Stack, a suite of software that makes Atlassian DevOps tools available in a single package.

    Sean Regan, head of product marketing for Atlassian, says this approach will make it easier for enterprise IT organizations to embark on a DevOps journey without having to worry about what type of tool they may need now versus in the future. For example, an IT organization may opt to get started using the Atlassian Jira software to track software development projects and then work its way up to deploying Atlassian Bamboo continuous integration/continuous deployment (CI/CD) software. From there, Regan says, a DevOps team may opt to embrace collaboration software to streamline communications across their various teams.

    The move to launch Atlassian Stack comes after the company updated a slew of its DevOps offerings, including the release of Bitbucket Server and Data Center 5.0 and Bamboo 6.0. In addition to tightening the integration between both DevOps tools, the company added capabilities for verifying commits, smart mirroring and the ability to define a Bamboo configuration as code.

    Rather than making DevOps teams acquire each tool individually, he says, many senior IT leaders now request a means through which the entire Atlassian portfolio can be made more readily available. That shift in purchasing behavior suggests that the level of DevOps maturity inside many organizations is advancing considerably, he notes.

    Of course, there are many who would contend that level of DevOps maturity has been a long time in coming. Web-scale companies have been employing DevOps tools for years to accelerate the rate at which new applications are released and updated. In contrast, traditional enterprise IT organizations have been slow to implement DevOps processes. In fact, it’s taken the pressure arising from digital business transformation initiatives that have accelerated application deployment timetables to get enterprise IT organizations to fundamentally rethink IT operations. Business leaders are making it painfully obvious that their patience with extended rollouts for new applications is at an end.

    Naturally, the rate at which those transformations are occurring within organizations will still vary considerably. However, the silos that exist within enterprise IT organizations need to be consolidated. The next issue is determining to what degree altering those processes needs to come in the form of a DevOps edict from above versus letting teams come together of their own accord to meet a specific application deadline. Whatever the approach, the way enterprise IT has been managed historically is no longer up to the digital business transformation tasks at hand.

    — Mike Vizard

  • Node.js Becoming More DevOps-Friendly

    Node.js Becoming More DevOps-Friendly

    Over the last several years use of Node.js has exploded across the enterprise, as developers moved to embrace a variant of Javascript that made it easier to build both client and server-side applications. However, every time it is upgraded, all the dependencies between it and application modules written in C or C++ breaks.

    To solve that problem, the Node.js Foundation is making available on an experimental basis a Node.js API (N-API), developed collaboratively by Google, IBM, Intel, Microsoft, nearFrom, NodeSource and other contributors. The API will be in Node.js 8, and promises to eliminate the need to update all those dependencies. Pending additional testing, it is expected to be given Long Term Support (LTS) status later this year.

    At the same time, The Linux Foundation is adding new features to experimental tracing and async tracking features. A diagnostics API will make it easier to monitor the operation of the Node.js event loop across the complete life cycle of a service request. Finally, an inspector core module, which allows developers to leverage the debug protocol used by the Google Chrome inspector to inspect currently running JavaScript code, is also being added.

    Each of these new capabilities are nice to have on their own. But collectively, they signal the beginning of a maturation process in the Node.js community. Increased use of Javascript in general—and Node.js especially—have arguably caused many enterprise IT organizations re-evaluate their DevOps processes. Developers using Node.js have been able to increase the number of applications they could develop considerably. Since then, the number of languages being employed within the enterprise has exploded.

    Mark Hinkle, executive director of the Node.js Foundation, says moving forward there will be more focus on reducing the friction surrounding upgrades of Node.js applications as part of an effort to further expand the ecosystem. Many organizations commonly end up supporting multiple versions running across a variety of applications. Hinkle says N-API is a step in helping to reduce the maintenance costs associated with supporting those applications. In an ideal world, the foundation would be gathering additional input from DevOps experts pursuant to achieving that goal. In most IT organizations, the care and feeding of Node.js applications is still left in the hands of IT operations teams after the apps are deployed in production.

    In the meantime, Hinkle says its performance continues to improve. Naturally, there’s a corresponding relationship between better performance and the number of use cases for which it will be considered. Of course, that doesn’t mean Java and other legacy programming languages won’t be used to develop new applications. But it does means that in terms of the number of programming languages employed across the enterprise, it’s now a polyglot universe.

    — Mike Vizard