Category: Features

  • DevOps, Security, AI Convergence on Horizon

    DevOps, Security, AI Convergence on Horizon

    DevOps is regarded as practice that can drive performance advantages. Artificial intelligence is showing very real promise across the security market. Most public and private-sector organizations know that they must explore new and different ways of defending their networks against modern threats. These three factors make it clear that DevOps, AI and security are ripe for convergence.

    Defining AI

    Anyone reading this post doesn’t need me to explain to them what DevOps and security are; both of these categories are well-defined. However, AI is really in an emergent stage, with different types in use and many definitions floating around. Because of this, I think it is important to let readers know that in this post, AI refers to a class of technology that can:

    • Consume data, learn and get smarter on its own
    • Automatically identify and solve problems
    • Operate independently, without human supervision
    • Scale massively
    • Move at near real-time speed
    • Achieve levels of accuracy that are beyond human capabilities

    DevOps and Security are United

    DevOps and security have merged. For several years now, organizations have been leveraging automation technologies and DevOps practices to continuously deliver security and compliance policies across data centers and clouds.

    Further legitimizing the union is the fact that leading DevOps and automation players such as Puppet, Chef and Ansible have formed numerous partnerships that deliver effective security capabilities to their customers.

    There are, of course, other signs that show how successful the DevOps and security marriage has been. One of which is the emergence of the term “rugged DevOps.” It is now so widely recognized that it commands its own section on this site and is often the subject of discussion at several notable security conferences.  

    DevOps and AI are Dating

    The relationship between DevOps and AI is in the early stages, with the courtship between the two well underway. Examples of its progress are found in numerous blogs and articles, several of which include:

    DevOps and AI have certainly not yet intertwined as deeply as DevOps and security have. These examples (and others out there) do show they the two will continue to integrate beyond what we are currently witnessing.

    DevOps, Security and AI

    DevOps and security are wed. DevOps and AI are moving closer toward each other. It’s only a matter of time until all three get together.

    Because several DevOps leaders are already in the business of security, it’s logical to assume that a partnership between one of them and an AI-driven security provider will be what ultimately leads to a marketable solution.

    DevOps provider candidates with the potential to move on a partnership that can combine DevOps, security and AI have a raft of new and established security providers available to work with. Several of the startups in this class are recognized in the CB Insights AI 100 2017 infographic. Companies such as Cloudera (NYSE: CLDR), which is using AI and machine learning to solve security problems, are among the more established providers that may make for a perfect partner. 

    How quickly will the market see such a partnership? That remains to be seen. However, with DevOps now fully accepted as a methodology that can positively impact bottom lines, AI coming into its own, and the need for new and different ways of defending organizations against attacks at a critical stage, it seems almost certain that the convergence will be upon us sooner rather than later.

    — Joe Franscella

  • VMware Ties Desktop Virtualization to DevOps Productivity

    VMware Ties Desktop Virtualization to DevOps Productivity

    It’s no secret that when it comes to building applications, many developers prefer to use the Apple Macintosh. However, that preference can create multiple DevOps challenges. VMware is moving to reduce the friction with the release of VMware Fusion Pro 10, a desktop virtualization offering for Apple Macs that now supports REST application programming interfaces (APIs) to more easily programmatically invoke virtual machines on Macs.

    In addition, VMware has significantly improved support for graphical processors units (GPUs) and 3D graphics within VMware Fusion Pro 10 that are now more commonly being invoked by developers.

    At the same time, VMware is also updating VMware Workstation 14 and Workstation Player, which adds support for Windows 10 and Windows Server 2016 along with updated Linux support for Fedora 26 and Ubuntu 17.04 guest operating systems to the desktop virtualization software. Workstation Player is a subset of VMware Workstation 14 that IT organizations can employ to limit the size of a virtual machine running on a local workstation.

    Other new capabilities include support for Microsoft’s Virtualization Based Security (VBS) features of Windows 10 Enterprise and Windows Server 2016 guests, enhanced virtual networking and new support and controls for working with vSphere and the vCenter Server Appliance software.

    Michael Roy, product line marketing manager for VMware Fusion, says more organizations are making GPUs available to developers as part of an effort to build more robust applications. Support for GPUs make it easier for developers to build compute-intensive applications for multiple operating system environments within the context of a DevOps environment managed by an IT organization, he notes.

    Other new capabilities include a revamped user interface and support for the Apple Touch Bar to simplify moving between native applications and virtual machine environments, including applications hosted on the VMware PhotonOS distribution of Linux optimized for hosting container applications.

    In this release of Fusion Pro, VMware is also adding support for Microsoft’s VBS features—which include Credential Guard for Windows 10 virtual machines, unified extensible firmware interface (UEFI) Secure Boot and a virtual Trusted Platform Module—in the same way it supports them on VMware Workstation 14.

    Finally, VMware is providing access to enhanced networking controls to enable management of network address translation (NAT) rules, network packet loss and latency simulation and renaming of VM networks.

    The updates were announced ahead of VMware’s VMWorld annual conference, being held Aug. 27-31 in Las Vegas.

    Developers typically require more access to more IT environments than almost any other employee, so maximizing the number of operating systems that can be deployed on their systems is in the best financial interests of the organization. Even when an organization can afford multiple machines most developers don’t want to have to move files between physical machines. Desktop virtualization software provides a means to not only increase productivity but also reduce the amount of machine overhead associated with developing applications across multiple operating environments.

    — Mike Vizard

  • Automation: This Time, It’s Different

    Automation: This Time, It’s Different

    It took about 200,000 years for mankind to be able to figure out how to get an airplane to fly. The event took place Dec. 17, 1903, on a field in Kitty Hawk, N.C., when Wilbur Wright piloted the airplane he had made with his brother, Orville, into the air. The flight lasted for 12 seconds. The aircraft covered a distance of 120 feet. The next two flights went a distance of 175 and 200 feet, respectively. The last flight of the day covered a little more than 800 feet. The plane stayed in the air for 59 seconds, at an altitude never greater than 10 feet, before striking the ground and incurring minor damage.

    Although the flights were a significant technological breakthrough, they had absolutely no commercial value. Other forms of transportation could go further and travel for longer periods.

    Almost two years later, having learned from their mistakes, the Wright Brothers were able to keep an airplane flying for 38 minutes, covering a distance of 25 miles at a speed of 40 mph. The aircraft was 30 percent faster than a horse at full gallop, but still slower than a passenger train running at an average speed of 60 mph. Commercial viability was in sight.

    In June of 1919, 16 years after the Wright’s first flight at Kitty Hawk, Capt. John Alcock and Lt. Arthur Whitten Brown of the United Kingdom flew 1,690 miles from Newfoundland to Clifden, Ireland, in a little more than 16 hours. Fifty years later, it took 73 hours and and 5 minutes for the crew of Apollo 11 to fly the 238,857 miles from Cape Canaveral, Fla., to the moon.

    Think about it. It took mankind 200,00 years of technological progress to get a plane in the air, but only 63 years after that to travel to the moon. It’s pretty miraculous, in a way. Technology does not just move forward. It careens ahead exponentially.

     

    Figure 1: Mankind was able to travel from 12 feet to 238,857 miles by air in 63 years

    What was the stuff of science fiction in my childhood—think video conferencing—is commonplace today. And it’s cheaper than we ever imagined possible. The future possibilities of technology are limitless. Anything can come to be, given enough time.

    But, when it comes to considering artificial intelligence and machine autonomy, there are still a lot of people out there who think that the notion of machines taking over most of the jobs that humans do is far-fetched, if not daffy. According to conventional wisdom, history’s pattern is that for every job eliminated by technology, more are produced. And should machines displace humans from the workforce entirely, that day is a long way off.

    That’s what my grandmother thought. She was born in 1900. If you had told her when she was a teenage girl that the flying contraption she was reading about in the newspapers would have the result of putting a man on the moon in her lifetime, she would think you crazy, and rightly so. She had no historical precedent to think otherwise. Remember, in her day horses still pulled plows. Everything except birds and hot air balloons were land-bound. Yet, despite her disbelief, there came a time when she sat in front of a television to watch Neil Armstrong descend from the Apollo 11 Landing Module to put the first human footprint on the moon. She thought it would never happen. And yet, it did.

    Yes, the historical pattern has been that technology eliminates jobs and creates new ones for humans to do. When the automobile replaced the horse, the out-of-work blacksmiths went to work in factories that filled the ever-expanding industrial landscape. And, with each wave of technological innovation, there were the harbingers of doom predicting the demise of human labor. Each generation of naysayers uttered, “This time it’s different.” Conventional wisdom points out that it never is.

    That was then and this is now. This is the time of the autonomous machine. This time it is different.

    The Rise of the Autonomous Machine

    Machine autonomy is the ability for a device to make decisions and conduct itself independent from ongoing instruction, very much the way a human does. The most telling example is an automated stock trading program used by financial investors. The program is at work continually buying and selling stock with the goal of turning a profit. Certain safeguards are built in to prevent disaster. But for the most part, the application is left on its own to achieve its goal: to make money.

    Until very recently, machine autonomy was confined to software applications such as the stock trading example described above. However, modern robotics makes it so that not only can a machine “think” autonomously, it now also can move autonomously. The most apparent example is the self-driving car.

    Integrating physical and cognitive autonomy into machine behavior changes the game. In prior days, a taxi required a human driver to get the passenger’s destination, find the best route, drive the vehicle and collect payment for the ride. All a passenger needed to do was jump in the back seat and tell the driver where to go. The human driver figured out the rest. As technology improves, the passenger still will jump into the back seat, but in an autonomous vehicle that gets routing information and traffic conditions from a wireless connection to the internet.

    The ramifications are profound.

    For example, let’s imagine we have a diseased tree in our front yard that needs to be removed. Today, we call a landscaping company. The tree removal crew shows up, we point to the diseased tree and ask the foreman to remove it. That’s the only instruction we need to give. The landscaping crew has the ability to act autonomously to do whatever is necessary to remove the tree safely.

    Now, imagine the crew brings along a robot to help with the task. At this point, it’s safe to say that current robotic technology requires a lot of human guidance to remove the tree; the robot is more an aid than an independent worker. The robot might have no other ability than to pick up tree cuttings and take them to a truck to be hauled away. Or, the robot might be able to handle a tree-cutting tool to assist with demolition. Still, the independence of the robot it limited. Either its activities are limited to repeatable tasks limited in scope, or it can act in an ad hoc manner by taking one instruction at a time from a human. The robot is dependent on human instruction to get work done.

    However, let’s imagine that robot technology is on the trajectory of exponential innovation that has been the historic norm. Remember, in the scheme of 200,000 years of homo sapien activity, 63 years from a field in Kitty Hawk to the moon is but a blip in the historical timeline. Autonomous lumberjack robots are entirely possible.

    You call up a landscaping company. A crew of three lumberjack robots show up in an autonomously driven vehicle. These robots know everything there is to know about tree removal and they can do all the physical activities required. The “lead” robot asks you which tree needs removing. You point to the tree. The crew figures out the rest on its own, right down to charging your credit card for work done. Plausible? If you answer no, pretend you are my grandmother and you’ve just been asked whether you think it’s plausible that a man will walk on the moon in your lifetime.

    So the question remains, What happened to the human crew? Did they become data scientists? Don’t answer this question yet. We’ll get to it in moment. First, we need to talk about the next milestone on the road to complete machine autonomy: artificial general intelligence (AGI).

    Narrow AI and AGI

    In the tree-removal scenario described above, all robotic activity—autonomous or otherwise—was confined to a single task: removing a tree. The scope of work is limited. Working within a limited scope of behavior is called narrow AI (artificial intelligence).

    Examples of narrow AI are cutting down a tree, trading a stock, finding a date on Friday night, composing a song, making a pizza, etc. We’re going to see a lot of narrow AI emerge in the next few years. Venture capitalists such as Khosla Ventures, Greylock Partners and Goldman Sachs are already putting money into advancing narrow AI technologies. However, narrow AI is but a stepping stone to get across the pond to the final destination: general AI.

    Think of of it this way: If Kitty Hawk is the starting point of AI, the first transatlantic flight is narrow AI. AGI is landing on the moon.

    What will general AI look like? Let’s go back to the landscaping example.

    We’re back in your front yard sitting in some lawn chairs having ice tea on a hot summer’s night. A driverless vehicle shows up. Two robots emerge. One approaches you and asks your permission to deposit $500 in your PayPal account in exchange for cutting down a diseased tree in your front yard. “OK,” you say, “but how do you know the tree is diseased and why are you giving me $500?”

    While the second robot gets to work, the first robot responds, “The county keeps drones in the air 24/7 analyzing the landscape. A drone did a spectral analysis of your property and noticed the diseased tree. In addition to reporting back the location of the tree, the drone also included a full biological profile. If you don’t remove the tree, the disease will spread. That’s the bad news. The good news is that it’s a cherry tree. And it seems that only 10 percent of the tree is diseased. The rest is perfectly good wood. The price of cherry wood is quite high on the commodity markets right now. Also, there’s a legal statute that requires the county to reimburse property owners when a private landscape is altered for general good. So, the county sold a futures contract on the wood it can reclaim from your tree. The $500 we want to put in your PayPal account reflects your share of the revenue received from the futures contract plus the amount of the reimbursement entitlement required by law.”

    This is what AGI looks like. AGI is the ability for a machine to think in broad terms, using a multitude of knowledge domains. Combining AGI with the advances in physical robotic capabilities expected on the horizon produces a result in which machine autonomy is not only possible, but will exceed human capability.

    If you think AGI is a fantastic notion, go talk to Yves Bergquist, CEO over at Novamente. The company is actively working to improve AGI for general commercial use. One application Novamente is developing uses AGI to determine, if not create, movie scripts with a high probability for profitability. To quote Bergquist: “A story is an algorithm.”

    Making a modern-day Hollywood blockbuster is a billion-dollar undertaking. Given the choice, studios would rather not roll the dice. However, when it comes to scripts, predicting a winner is difficult. Of all the human endeavors that are tough to emulate with artificial intelligence, creative storytelling ranks high. Writing a script requires working in a multitude of knowledge domains: story, character, plotlines, scene design and historical continuity, to name a few. Narrow AI is not suited to the task. You need AGI. There’s too much to consider. In a way, it’s surprising to think of Hollywood is the perfect incubator for developing real-world AGI. But it makes sense. AGI might produce a few flops. But, it’s a whole lot safer to lose at the box office than to lose on the battlefield.

    Given companies such as Novamente, the entertainment industry might well become the incubator in which AGI is perfected. Then, if the trend in rate of technological innovation continues, eventually AGI will become viable everywhere. Then what? What happens when a machine can do everything a human does only faster and better?

    A Turkey’s Life

    Understanding the long-term impacts of a given technology has not been one of the highlights of human endeavor. As cars became commonplace, few people considered the possibility that too many would create too much carbon monoxide and thus threaten the health of the earth’s population. And nobody really thought about what was going to happen to the displaced blacksmith who was no longer needed to make shoes for a diminishing number of horses. Events just ran their course with little or no forethought.

    But, it’s getting better. Some people do think ahead. Military planners consider the improbable as do financial analysts. It’s called risk analysis. These are the people that get paid to think outside the box, so to speak. They understand the even small possibilities might happen. Whether they are heeded or not is another story.

    Today, machine autonomy is real. The possibility exists that in our lifetime automated AI will indeed be able to do everything a human does. And, the machine will do it better at less expense. There will be no new jobs for humans to do as old ones are destroyed. A machine will be able to do the new job faster and cheaper—even those jobs that require a significant amount of AGI. Then, what will happen to the humans?

    We have to think about it today!

    Sadly, few are. We are not hearing any articulation in general industry or in government, at any level, about ideas to address the the impact of automation on human employment as machine autonomy and AGI become more prevalent in the economy. It seems as though most people are relying on the old logic of the conventional wisdom.

    Conventional wisdom is easy to accept. The U.S. economy is reported to be at practically full employment levels. Employers are complaining about how difficult it is to find qualified workers. The stock market is achieving historic heights. Given history and current events, of course it’s reasonable to say there always will be jobs for humans to do.

    This assertion works until the day fully autonomous machines appear on the landscape. Then, conventional wisdom will be that which is uttered by turkeys on the day before Thanksgiving.

    What do I mean? Allow me to elaborate using a previously written analogy.

    Imagine you are a turkey on a farm. Every day the farmer comes by to feed you. This goes on for one week, two weeks, 10 weeks. Given your history, you are completely justified to predict that your future will be one of satisfying meals. It’s always been this way; how could it be otherwise? You go day in and day out predicting that the next day will be full of food and sunshine. You are correct … right up until the day before Thanksgiving.

    In other words, there are things that happen independent of historical precedent. The trick is to imagine what such events might be.

    Everybody agrees that AI is here and that machine autonomy is growing. The conventional wisdom is that, based on historical observation, there have always been jobs as technology grows. Many think the full replacement of human labor by autonomous machines is a possibility, but one that is coming in the far, distant future. When Wilbur Wright took off in 1903, my grandmother’s distant future as was 1969. Those 63 years passed in no time. She lived to see a man land on the moon. Those of us alive today are seeing the beginnings of true machine autonomy appearing on the technology landscape. A world of full machine autonomy is more than probable in the lifetimes of our grandchildren. It will happen. What will be the impact? What will they do if their labor is no longer required?

    Back in 1903, as automobiles began to chug along the planet’s roads, we missed predicting the possibility of air pollution and global warming. Today, will we allow conventional wisdom to prevail and miss preparing for the impact that full machine autonomy will have on human employment? Or will we plan ahead? Hopefully, we’ve learned from our mistakes.

    I’ll leave it to you to decide.

    Author’s Note: The analogy of prediction in terms of historical precedence is taken from the book, “The Black Swan,” by Nassim Nicholas Taleb

    — Bob Reselman

  • Jenkins World, Training and Infostretch

    Jenkins World, Training and Infostretch

    I’ve talked to a fair number of vendors about Jenkins World 2017, and I’ve spent a decent amount of time lately supporting DevOps training initiatives at a variety of vendors.

    The thing is, the DevOps world is changing fast enough and there are enough options out there that training is not something you need only before moving to DevOps. During one recent project, I ended up learning about a particular topic as I was developing support materials for a training session on that topic. And I’m pretty steeped in the DevOps world.

    So, while I don’t write about every vendor I’ve talked to about Jenkins World, Infostretch‘s new training program is worth talking about. Infostretch is unveiling an array of training solutions to help companies not only get a handle on DevOps needs, but also to grow their DevOps maturity.

    Among the offerings will be a DevOps maturity assessment and new Jenkins training programs. In conjunction with its visit to Jenkins World, Infostretch will be offering a free 90-minute webinar on adopting Jenkins 2.0.

    Demands of the job will keep me from attending Jenkins World, but if you’re there, it might be worth checking out Infostretch’s booth (#415) to see what there is to learn. If you do, feel free to drop me a line—I’m intrigued to learn more about the training and how it fits in with other available offerings. As an added bonus, the company is giving away “Game of Thrones”-themed DevOps Journey Maps marking various stages of DevOps journey and the “happy flow” of DevOps, and including the various tools available in the market for each stage. So you can snag that while stopping by for me to learn about Infostretch’s training.

    The other thing that interested me was a presentation. Sanil Pillai, director of Infostretch Labs, will be presenting a 15-minute demo titled, “Auto-Convert Your Freestyle Jenkins Jobs to Coded Pipeline” on Wednesday, Aug. 30, at 10:45 a.m. at the Sponsor Theater, in the Expo Hall. The variety of scripts that can make up the components of a Jenkins build environment are a problem many of us have struggled with; while better than what we had because they’re part of an automated process, the components are still technical debt with variable maintenance requirements. Someone, please go see the talk/demo and report back. It would be cool if Infostretch has an answer for this problem.

    I Reiterate: Training is Imperative

    It is human nature to make a large change and settle in with the known new world. DevOps is not designed to be that way. It is still growing and changing, so don’t get complacent. Challenge yourself and seek out training, tool enhancements and opportunities to improve. As others have said repeatedly and well, DevOps is a journey, not a destination. Learn, get better, find better ways and tools and keep improving.

    And, keep rocking it. Eliminating IT as a bottleneck is a huge step to improving product development and being more in sync with the business.

    Of course, now that I’ve written out the reasons why Infostretch’s plans for Jenkins World interested me, I am tempted to dig into some of the other offerings. Or to try and figure out how to go to Jenkins world without missing important things at work.

    You may be hearing more of Jenkins World from me before it arrives.

    — Don Macvittie

  • CollabNet Merges with VersionOne for ALM Supremacy

    CollabNet Merges with VersionOne for ALM Supremacy

    Thanks to the rise of DevOps, there has been a lot of focus on various forms of application lifecycle management (ALM) spanning multiple application development methodologies. But as IT organizations become more comfortable with multiple methodologies, it turns out they are not replacing one with another as much as simply trying to figure out where to employ one over another. That, in turn, is driving some consolidation across the ALM category.

    CollabNet this week announced it is merging with VersionOne, a provider of an ALM framework optimized for agile application development. While CollabNet has made some forays into the space, historically its primary focus has been on waterfall methodologies commonly used across larger enterprise IT organizations. CollabNet CEO Flint Brenton says the goal now is to combine the best of the ALM tools provided by both companies to enable IT organizations to leverage agile and waterfall methodologies as they best see fit. In fact, he says the biggest ALM issue facing organizations today is the need to balance developing applications faster and the inherent risks associated with potentially moving too quickly.

    Robert Holler, formerly the CEO of VersionOne, will assume the post of chief strategy officer for the combined company. He says there’s very little overlap between the two company’s product portfolios, and the one thing that will distinguish CollabNet going forward is an open approach to ALM that enables organizations to employ whatever tools they prefer. Instead of forcing organizations to rip and replace those tools, Holler says ALM frameworks need to foster collaboration rather than trying to impose a closed ALM environment. That environment also needs to be deployable on-premises or in the cloud, depending on the requirements of the customer.

    Holler notes that once any segment of the IT industry reaches a certain level of maturity, consolidation is all but inevitable. The opportunity CollabNet has is providing an ALM environment that makes it possible to automatically package and deploy applications that includes strong version-control mechanisms. Those capabilities will become even more critically important as IT organizations expand usage of microservices based on, for example Kubernetes, alongside traditional virtual machine deployments across the enterprise. Accomplishing that goal will require a common management layer capable of spanning both environments, he says.

    The combined companies have more than 20,000 customers. That number may not collectively represent the lion’s share of the ALM market, but it does make CollabNet a serious contender against a host of rivals that are both a lot older and larger. CollabNet’s challenge now is convincing customers of competitive organizations to switch to an ALM platform that CollabNet contends is a whole lot more flexible.

    In the meantime, it’ll be interesting to wait and see if the combination of CollabNet and VersionOne will drive any additional acquisitions at a time when IT organizations are becoming a lot less religious about what type of application development methodology gets employed by who and when.

    — Mike Vizard

  • Sonatype Report Spotlights Software Supply Chain Issues

    Sonatype Report Spotlights Software Supply Chain Issues

    Most application developers today don’t write much raw code. Rather, applications developed today are created mostly by combing various modules and widgets to create a custom application. But currently there is little oversight being applied to the provenance of application components, especially when it comes to open-source software.

    The third annual State of the Software Supply Chain Report published by Sonatype, a provider of tools for managing software supply chains, finds that the amount of time it takes for open-source projects to address vulnerabilities is considerable. The report states that only 15.8 percent of open-source software projects actively fix vulnerabilities, resulting in an average mean time to remediation of 233 days. In effect, that gives cybercriminals the better part of a year to exploit a known vulnerability. Of course, that’s usually longer simply because most IT organizations are not especially efficient when it comes to regularly updating all the components that make up an application once it’s been deployed in production.

    Based on an analysis of more than 17,000 applications, the Sonatype report estimates downloads of Java components grew 68 percent (52 billion) year over year in 2016, while JavaScript downloads (59 billion) grew 262 percent.

    Matt Howard, chief marketing officer for Sonatype, says managing all the components that make up an application will only become more challenging as developers increasingly start to leverage Docker containers. The Sonatype report estimates there will be 12 billion downloads of Docker containers in 2017, a 100 percent increase over 2016.

    The good news is that more awareness of DevSecOps issues appears to be having an impact. The report finds the percent of Java components downloaded from the Sonatype Central Repository that contained known security vulnerabilities fell to 5.5 percent (1 in 18), down from 6.1 percent the year prior. Of course, that improvement needs to weigh against the 68 percent increase in downloads, which would suggest that the total number of components with known vulnerabilities finding their way into production applications has never been higher.

    By way of contrast, the report claims that applications built by teams employing automated governance tools reduced the percentage of defective components in their application by 63 percent. The report also says organizations that are actively managing the quality of open-source components flowing into production applications are realizing a 28 percent improvement in developer productivity, a 30 percent reduction in overall development costs and a 48 percent increase in application quality.

    The report makes clear that DevOps processes are not being extended far enough to the proverbial left. Instead of focusing on only on the application release cycle organizations need to apply structured processes to the components that are being aggregated together during the application development process. In fact, Howard notes that application development is moving away from being an art to more of a manufacturing process. As that shift continues to occur, it’s only a matter of time before a much greater emphasis gets placed on quality control all the way down that manufacturing line to not only limit liability but also generally improve the overall application experience.

    — Mike Vizard

  • Loom Systems Extends Reach of AI into DevOps Realm

    Loom Systems Extends Reach of AI into DevOps Realm

    One of the things that tends to hold back adoption of DevOps are all the low-level events that need to be correlated by an engineer to generate anything that approaches actionable intelligence (AI). To eliminate that requirement, Loom Systems created a Loom AIops platform to automate many of the tasks that normally would need to be performed by a DevOps engineer.

    Loom Systems has upgraded the Loom AIops platform by adding Distributed Entity Tracing, which makes it easier to analyze events across a range of interdependent applications and associated middleware. In addition, Loom has created Correlations View, which simplifies identifying how alerts being generated are related to one another.

    Finally, the latest version of AIops adds support for the OpenStack cloud management framework, in addition to sporting a revamped set of dashboards that are easier to navigate.

    Dror Mann, vice president of product for Loom Systems, says one of the reasons that DevOps is not widely implemented is that today it requires IT staffs to accumulate and correlate massive amounts of low-level event data to create anything approaching actionable intelligence. Loom AIops is designed to automate the low-level tasks relating to DevOps to enable the IT staff to focus more of their time and effort on fixing issues and reducing the time required to release and update applications.

    Loom AIops, says Mann, accomplishes that goal by first streaming all the application log data into its platform, followed by all the log data generated by any dependencies that application might have. Loom AIops then applies machine learning algorithms in real time to identify the root cause of an issue. Armed with that information, it becomes a lot easier to reduce the mean time to resolution (MTR), which then provides the IT organization with the time needed to address more complex management challenges, he says.

    Mann notes the single biggest challenge IT organizations encounter with DevOps is that it requires them to change their modus operandi. By automating many of the lower-level DevOps tasks, there’s more time available for IT organizations to think through the cultural changes required to successfully implemented integrated DevOps processes.

    Most IT professionals will view the application of AI to IT operations with a combination of skepticism and trepidation. It will be difficult initially for many IT professionals to trust the analysis being generated by AI software. Once they do begin to trust that analysis, there naturally will be some concerns over to what degree an AI program can eliminate the need for a DevOps engineer altogether. But, Mann notes, there are many complex tasks that never get addressed because most DevOps engineers spend an inordinate amount of time and effort trying to correlate the right data.

    At this juncture, usage of AI within the context of DevOps is now all but inevitable. The challenge now is not figuring out the line between where humans add higher orders of value compared to machines that are generally going to be limited to identifying patterns. The advantage a machine has it that once it learns something, it doesn’t forget it, take days off or switch jobs. However, being able to identify a pattern is not nearly the same as being able to apply reasoning to what the sum total of those patterns really means for the business.

    — Mike Vizard

  • IBM: DevOps Challenges Require Managed Services

    IBM: DevOps Challenges Require Managed Services

    The DevOps complexity associated with determining which classes of application workloads are best-suited to run on certain platform types will push an increasing number of IT organizations to embrace managed services. That’s the premise put forth by IBM, which provides such a service.

    Steve Robinson, general manager for IBM Cloud Platform Services, says it’s becoming less likely that internal IT operations teams will have the tools and expertise required to analyze and optimally deploy workloads. In fact, the number of platform choices have already exceeded the ability of most internal IT organizations to master. They include:

    • Traditional virtual machines: The most widely deployed form a virtual machine software comes from VMware. But there’s already a lot of interest starting to emerge in so-called “micro VMs” that promise to reduce the memory footprint of VMs. However, rather than replacing traditional VMs, it’s probable micro VMs would be deployed alongside traditional VMs.
    • Containers: Most containers today are deployed on top of virtual machines because of a lack of tools as well as security concerns. But as IT organizations become more adept at managing containers, many more of those containers will wind up running on bare-metal servers that will be able to attain much higher utilization rates by eliminating the need to deploy traditional virtual machines.
    • Serverless Computing: Based on event-driven architecture, these platforms can be invoked natively as functions or simply be used to host containers. In either case, the need to provision servers, storage and networking resources is eliminated because IT infrastructure resources are made available on demand in real time.
    • Graphical Processing Units (GPUs): As an alternative to Intel Xeon class processors, GPUs now are taking on many workloads involving machine-learning algorithms and big data because of their ability to process many of those workloads in parallel.
    • Field Programmable Gate Arrays (FPGAs): Based on custom integrated circuits, FPGAs are being more widely employed within a variety of cloud services.

    IT organizations today have the option to deploy any of these technologies on-premises or invoke them in the cloud. The issue most are contending with is a lack of advanced IT skills. In the absence of those skills, many IT organizations are in peril of falling behind their rivals. To overcome that issue, Robinson says it’s easier for many organizations to rely on third-party providers to manage their infrastructure while they concentrate their limited resources on application development.

    Any increased reliance on managed services to gain the benefits of a more sophisticated approach to DevOps will vary widely by organization. Crafting DevOps process that span third-party organizations takes time and effort. There’s no way to analyze a workload and then automatically deploy it on the optimal platform without any human intervention. But as IT organizations continue to struggle with mastering DevOps processes, many may conclude it makes the most sense to rely on the expertise of a third-party service provider to manage a hybrid approach to DevOps. Regardless, the pressure to show results by increasing the amount of high-quality code being generated across the enterprise is mounting.

    — Mike Vizard

  • NodeSource Gets to the Source of the Node.js Issue

    NodeSource Gets to the Source of the Node.js Issue

    There’s no shortage of variants of Node.js in the world, but NodeSource is making a DevOps-related case for why IT organizations should standardize on its runtime implementation.

    NodeSource released version 2.3 of N|Solid, which adds support for event loop delay notifications that pinpoint precisely where an issue that needs to be addressed has occurred with an application, based on the Node.js variant of JavaScript.

    Pravin Halady, product manager for NodeSource, says N|Solid uniquely provides a runtime implementation of Node.js that provides that capability. Coupled with tools to monitor applications based on N|Solid, additional visualization tools and configurable webhooks-based integration to create alerts that can be shared via collaboration platforms such as Slack, N|Solid is the only Node.js runtime specifically optimized for enterprise IT environments, Halady says.

    He notes one of the thornier issues organizations that embrace Node.js face is that any long-term synchronous activity blocking the event loop can prevent other incoming requests from reaching the server. Before too long, the application hangs or simply crashes. By providing insights into when an event loop delay is occurring in real time, Halady says IT organizations don’t have to waste time trying to reproduce the problem. The result is a much faster time to resolution of Node.js application issues.

    DevOps teams can find themselves dealing with those types of issues at a much higher level of frequency once developers employ Node.js. As adoption of the most widely employed variant of JavaScript increases, IT organizations are managing more applications than ever. In fact, a recent survey published by the Node.js Foundation finds that three out four respondents plan to increase their usage of Node.js over the next 12 months. The primary reasons cited for that additional usage are increased developer productivity (68 percent); improved developer satisfaction (65 percent); reduced development costs (58 percent); and increased application performance (50 percent). Nearly half the respondents (47 percent) working in enterprise IT organizations say they been using Node.js for more than three years. Over half the developers (58 percent), in contrast, report having more than 10 years of experience working with Node.js.

    IT organizations generally have very little visibility into what’s occurring inside Node.js applications, which makes it difficult to apply DevOps processes. In fact, most DevOps processes in place today are wrapped around applications written in more mature languages such as Java. Developers employing JavaScript tend to not be as well-versed in the role programmers ideally play within the context of an integrated set of DevOps processes.

    In the absence of those processes, having the tools needed to debug an application in real time becomes more important to an IT operations teams that needs to inform a developer about the root cause of a specific issue. Otherwise, the developer ends up running one test after another in the hopes of replicating the problem. Unfortunately, the probability of accomplishing that goal inside most organizations is often relatively low. Because of that issue alone, an event loop delay notification made in real time is likely to pay for itself in a matter of hours.

    — Mike Vizard

  • Study: Half of Enterprises Have Achieved DevSecOps

    Study: Half of Enterprises Have Achieved DevSecOps

    The inclusion of IT security into DevOps processes, also known as DevSecOps, appears to be occurring at an accelerated rate. A new survey of 300 enterprise IT organizations published this week by DigCert, a provider of identity management and encryption software, finds that almost half (49 percent) of the respondents says they have completed DevSecOps, while another 49 percent say they are already working on it.

    In terms of overall impact, however, only 22 percent say they are doing well in terms of achieving and maintaining higher levels of security.

    In addition, those that have achieved DevSecOps say it took them anywhere from 12 to 14 months to make the transition. Those that have not completed the transition are estimating it will take them seven to 11 months. Based on the experience of the organizations that have completed the transition, there would appear to be a natural tendency to underestimate how much the cultural difference between developers and IT security teams can negatively impact integration objectives.

    Jason Sabin, chief security officer (CSO) for DigiCert, says that while many organizations may have brought IT security professionals into the process, an increase in the overall security of applications being built requires more time and patience, says Sabin.

    DigiCert recommends IT organizations identify an IT security champion within a DevOps process and automate the implementation of IT security controls as much as possible. Those moves can help lower developer cultural resistance to having to spend time on what often are considered mundane programming issues.

    It’s worth noting that most IT security professionals don’t have much in the way of programming skills. They can secure an application using any number of platforms that have a management console. But understanding how to employ APIs to help plug security holes before an application gets deployed is beyond the capabilities of most IT security professionals. IT security professionals can make developers aware of issues, but in general there’s not much they can do to fix the application itself.

    Also, IT security professionals typically don’t understand the amount of coding that might be required to fix an issue, and they are not always able to access the true risk associated with a specific vulnerability. All vulnerabilities tend to be treated as equal threats regardless of number of instances a vulnerability has been exploited.

    The good news is a full 88 percent of respondents saying it is somewhat to extremely important to integrate security into DevOps. Failure to do so will lead to issues such as increased costs (78 percent), slower application delivery (73 percent) and increased security risks (71 percent). Awareness of these issues should eventually lead to the development and deployment of more secure applications.

    The issue, of course, is that not every development team is equally along the DevSecOps maturity code. Because of that issue, it unfortunately may be years before the preponderance of applications running in a production environment are able to defend themselves from even the most rudimentary cybersecurity attacks.

    — Mike Vizard