devopsy.kinsta.cloud

Category: Features

When Automation Predictions Come To Be: Transportation as a Service

Back in December of 2016 I wrote an article for devopsy.kinsta.cloud titled, “What Do We Do When Everything is Automated?” in which I made a prediction:

Also, think about this: As Uber and Lyft mature in the business landscape and self-driving cars become commonplace, the ride-share companies will replace human-driven vehicles with self-driving vehicles. Then, Uber or Lyft will start to offer a pricing model that is a flat fee for 24/7 service with unlimited mileage.”

Pretty brazen prediction, huh? Well not really. I thought and still do think that such a situation is inevitable. You just have to think things through to arrive at the conclusion I made above. However, my thinking was that, until yesterday, this sort of inevitability is about five years out. Then this news flash come in from Bloomberg: “Apple Is Working With Hertz to Manage Its Self-Driving Car Fleet”

This caught my eye. Hertz stock went up 14 percent that day. Upon further inspection, I learned that Apple is leasing a small fleet of cars from Hertz to test self-driving vehicles. Turns out the Alphabet Inc., a.k.a., Google, has a similar deal with Avis Budget Group Inc., a competitor to Hertz in the car rental space. Now granted, I thought that Uber or Lyft would extend the scope of their activity by working directly with automobile manufacturers making self-driving vehicles. That the service provider might be a current automobile rental company was a bit unanticipated. But, as I explored further, it gets interesting.

I turns out that Hertz previously was owned by Ford Motor Company, which sold the company to a private equity group in 2005 for $15 billion, a tidy sum. Hertz acquired Dollar Thrifty in 2012. Avis Budget Group, a competitor to Hertz, owns Zipcar as well as the New Zealand rental company, Apex Car Rental and Maggiore Group, the fourth largest car rental company in Italy. There’s a lot going on in the auto rental space.

As I reflect upon events, things become clearer. It makes sense that those non-automotive companies working to create driverless vehicles are attracted to car rental companies. Car rental companies are not in the automobile business. They are in the transportation service business. Few people go to Hertz to rent a Chevy. They go to rent a way to get around. If a customer shows up at the Hertz counter only to find out that there is no Chevy to be had, most people will take the Nissan alternative. They don’t care about the car. They care about the service the car provides.

Now imagine this: Let’s say you are a vehicle manufacturer, new to the marketplace. You finally figure out how to make a driverless vehicle that satisfies the needs of consumers under most driving conditions. Given current trends, when it comes time to make a profit from your investment, are you going to open showrooms with the hope of selling your new automotive brand to consumers? Or, are you going to buy an existing company that has a proven record success and infrastructure for providing transportation services on demand to the masses? In other words, what’s easier to imagine, Apple setting up showrooms throughout the world to sell autonomous vehicles to consumers accustomed to buying Ford, Toyota, Nissan or Tesla? Or, rather, Apple going directly into the autonomous transportation-on-demand business by buying Hertz? Or maybe Hertz will just buy driverless cars from Apple. (Hertz buying from Apple is hard to imagine; Apple is a company that likes to think big. Selling cars to Hertz is thinking small.)

My take? Well, two things: First, as autonomous vehicle technology matures, transportation as a service is going to grow on the landscape. Vehicle manufacturers need to survive. They will adapt. How the actual selling of vehicles fits into it all is still working itself out. I think we’re going to see a lot of vehicles being made to provider of service, not as a property to own. Second, maybe it’s time to buy some stock in Hertz, maybe Avis too, for that matter.

What do you think?

— Bob Reselman

June 29, 2017
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

June 26, 2017
In DevOps, Figure Out Why Before Considering How

It has been fairly well-established that DevOps is primarily a function of the underlying culture—about breaking down barriers and shifting roles so that teams and individuals are empowered to come up with innovative ideas and execute them without the burden of traditional corporate bureaucracy. It is also understood that there are a variety of tools and platforms that enable and automate processes. However, before an organization can even get to the “How”—the culture and tools of DevOps—it should be able to answer the question, “Why?”

I reached out to organizations that have embraced DevOps and leaders in the field to see what they had to say about the “why.” What benefits can businesses expect, and what goals can adopting DevOps help them achieve—or achieve faster, or achieve cheaper?

“Delay in delivering innovation comes with an increasingly high price tag, perhaps the loss of an entire market to competitors,” says Forrester Analyst Charles Betz. “DevOps accelerates and improves the quality of software delivery, but that is not an end in itself. The increased speed provided by DevOps is essential to achieving the fast product feedback needed for digitally transforming enterprises to stay relevant and competitive.”

As Betz points out, companies should implement DevOps for the competitive advantage. Dave Lindquist, IBM Fellow and VP of Private Cloud for IBM, puts it another way: “DevOps is at the heart of the digital transformation. It’s how the next wave of disruptions are being developed and delivered.”

DevOps bridges the gap between development and operations teams. Inspired by agile development and continuous integration, and incorporating their principles, it addresses the challenges of today’s condensed timeline for application development.

In that way, the line between the “Why” and the “How” blurs into a bit of a gray area. Companies should adopt DevOps with specific goals in mind—a vision for what they expect it to do for them—because simply eliminating barriers or implementing tools and platforms without a strategy in place for what that is expected to accomplishment is likely to be a waste of time, money and effort. On the other hand, it is very difficult to execute or achieve those goals without also successfully navigating the “How.”

“Enterprises are navigating major technology shifts and demand is therefore higher than ever for simple and consistent automation and management across hybrid infrastructure and application portfolios,” says Marc Holmes, VP of Product and Revenue Marketing at Chef. “Organizations should adopt DevOps practices for both the culture and tooling to create a consistent and collaborative workflow so enterprises can build, manage and deploy software quickly and safely in any environment.”

“DevOps can have a direct effect on your bottom line. According to a recent study from Enterprise Management Associates (EMA), ‘Companies that excel at DevOps interactions are 11 times more likely to see double-digit annual revenue growth. It doesn’t stop at revenue growth either. According to EMA, 49 percent of organizations also agree that accelerated delivery frequency leads to higher customer satisfaction, and 35 percent find that it enables them to be more agile and competitive,’” notes Chris Lippi, VP of product at NGINX.

With its focus on automation, DevOps also helps to ensure predictability, efficiency, accuracy and the standardization of operational, development and testing processes. This, in turn, saves time and money by shortening the release cycle, reducing errors and lessening the need for time-consuming fixes. It also frees up resources to focus on more creative endeavors and on tackling larger problems as they arise.

Lippi sums it up this way: “Once implemented, DevOps tends to prove its business value in terms of time and cost savings. Making the business value of DevOps clear—to the newly unified team and beyond—helps DevOps culture take root.”

There are lots of tools and practices out there to choose from, and plenty of guidance and advice on how to implement a DevOps culture. Before you go down that path, though, step back and figure out what you hope to accomplish by adopting the culture, tools and practices.

— Tony Bradley

June 23, 2017
Humans: The Ultimate Exception Handlers. Until …

Back at the turn of the century, I had a job working in the IT department of a Big Bank. The section I worked in was Mortgage Exceptions. My group’s task was to route exceptions that could not be addressed by the mortgage processing system to a human being for resolution.

Most of the intelligence required to execute the Big Bank’s mortgage business processes was automated by the mortgage system. Each month the system processed millions of mortgage payments. The systems sent out the bills for payment. And, when a payment came in, a human operator entered the check payment into the system. (This was before the days when direct withdrawal was the norm.) Most people paid their bills. So, for the most part, the system chugged along without a hitch. But every so often there was a problem the system could not handle—an exception, if you will.

Examples of exceptions were accounts that were significantly past due, account numbers that were unknown to the system, customer complaints and bounced checks. There was a whole array of stuff that could—and did—go wrong that the software could not handle. Thus, the exception ended up in front of a human being. The human was the ultimate exception handler.

I worked on that system more than 15 years ago. I think it’s safe to say that today the bank’s system intelligence is a lot smarter. I imagine that today the IT group I worked in is more concerned with writing more robust, automated exception-handling than routing problems to humans.

That’s the way technology goes. Systems get smarter and, in many cases, become better than humans when it comes to doing work that is well-known and repetitive. The more the machine can do, the more the machine will do. Businesses like machines—always have, always will. Automation is a good investment.

Those of you who have been following my writing on devopsy.kinsta.cloud know that I am very concerned with the impact of automation on human employment. I saw the writing on the wall when I read the Ball State study. As time goes on, more machines will be doing more work. Less human labor will be required. What will those displaced humans do?

Many believe that automation will create new jobs for humans. In some cases, it will. As I said earlier, I am sure the people who were writing the routing code at the Big Bank I worked at years ago are now writing more robust exception handlers that require less human interaction for resolution. Those few developers writing the exception handlers are probably doing just fine. The developers who were writing simple if-then rules, with no ambition otherwise, are probably gone. Also, I’ll bet the the Big Bank has embraced the DevOps sensibility, which probably has resulted in those with lesser talent in terms of implementing automation being shown the door. As for those humans who were entering checks into the system and turning delinquencies over to collection agencies, their number is probably now a handful, if any. Hopefully, the poor soul who was hired as a teller out of high school and worked her way into mortgage exception resolution adapted, despite the odds.

As I said previously, many believe that automation will create new jobs. There always will be new things to do or things that need to be done that machines can’t do. Fair enough. Still, for me it’s not about new jobs being created. It’s about the number of new jobs that will be created.

Many of the new jobs will require a lot more smarts than did the jobs they are replacing. And my gut tells me that, while there will be new jobs, there will be fewer than the number of old jobs eliminated. And these new jobs will fall into two categories: “Cool New Work” and “Doing Work the Machines Have Yet to Master.” The “Cool New Work” is just that. “Doing Work the Machines Have Yet to Master” is handling exceptions, the work I used to route to humans back at the Big Bank. Except this time, as systems become smarter, many of the exceptions these systems throw will become a lot more difficult for humans to resolve. The systems will throw fewer errors, but when they do, watch out!

Exception-handling has been in the realm of advanced human activity since the days when the ancient Mayans needed to figure out a way to build pyramids that didn’t fall down. A lot of buildings fell down before a few stood up. Eventually, they figured it out. Exceptions gave way to learning, and today we have the art and science of architecture. The industry has matured. Today, constructing a building is more about process and technology than figuring out what went wrong with the last building.

So, too, will it be with automation exceptions. Just as over time fewer pyramids collapsed, with automated systems fewer exceptions will be raised and fewer humans will be needed to figure out what went wrong. Then, we’ll be back to where we seem to be going: more machines doing more general work, a smaller number of very intelligent people doing more advanced work, and the rest of us doing the tasks the machines can’t do yet—aka, the exceptions. We’ll be working on exceptions until the time that the thinking machines will be able to resolve those exceptions. Then what? Dunno.

Now, don’t get me wrong. Technology is good; automation is good. There’s more to life than spending most of one’s waking hours entering check deposits into a mortgage system. Humans were meant for more. But, when earning a living means being really smart or being just one step ahead of a machine, it’s going to be a real challenge for the Average Joe to the find opportunities to earn a buck, let alone find a job. How will we meet this challenge? This I leave for you to determine.

— Bob Reselman

June 21, 2017
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

June 15, 2017
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

June 15, 2017
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

June 13, 2017
Survey: DevOps Divide Grows a Little Wider

The gap between the number of organizations that have invested in DevOps is starting to narrow, and IT organizations that made the transition to DevOps earlier are starting to see accelerated returns on that investment, according to the latest survey by Puppet.

The annual “State of DevOps Report” finds that out of 3,200 IT professionals surveyed, only 11 percent were part of organizations that could be considered high DevOps performers. High performers are deemed to have higher deployment frequencies, lower lead times for changes, better mean time to recovery (MTTR) and better change failure rates. The higher performers in this year’s survey are deploying applications 46 times faster than the same designated group of higher performers were last year.

The survey also finds that higher-performing organizations have automated 72 percent of all configuration management processes. Those same high performers spend much less time (28 percent) employing manual configuration processes. Lower performers are spending almost half of their time (46 percent) on manual configuration.

Just over a quarter (27 percent) of the respondents self-identified themselves as being part of a DevOps team, according to the survey. In contrast, only 16 percent said the same last year. Puppet CTO Nigel Kersten says those results suggest that understanding of the power of DevOps is increasing. It’s also apparent the early implementers of DevOps processes are enjoying a level of IT agility that is much greater than the average IT organization.

In general, Kersten says that while much DevOps progress has been made, most IT organizations have automated only various pockets of silos. Developers, for example, may have automated some processes on their own, while IT operations specialists may have developed a custom script to automate the configuration of a handful of servers. Kersten notes IT leaders should be cognizant of the technical debt their organizations are incurring every time different elements of the IT organization employ different tools to automate the same basic processes time and again.

Very few have automated their operations within the context of a continuous integration/continuous deployment (CI/CD) pipeline, says Kersten. That becomes more challenging to accomplish as new computing models based on containers, for example, are added to the enterprise mix. On a more positive note, Kersten says more processes are being well-defined, as they are bounded by an application programming interface (APIs). Those APIs then become the core technology over which IT automation frameworks are then laid.

The issue many IT organizations have yet to confront is the degree to which they want to stumble toward DevOps versus implementing a concerted plan of action. Much of the DevOps progress to date has been driven from the bottom up inside many organizations. The time is now approaching for IT leaders to imbue DevOps as a part of the IT culture that permeates the entire organization.

To one degree or another it’s a safe bet every organization will implement some form of DevOps going forward. The challenge will be figuring out how to transform all those isolated instances into something more akin to an actual IT strategy.

— Mike Vizard

June 12, 2017
Q&A: Michael Beckley, CTO/CCO, Appian

Recently I had the chance to speak with Michael Beckley, chief technical officer and chief customer officer at Appian, about his company’s move to go public and the DevOps space in general. For those of you who don’t know Michael, he is a founder of Appian and leads the company’s technology vision and oversees customer initiatives worldwide. He also serves on the Industrial Advisory Board for the University of Virginia’s Computer Science Department and is a member of the University of Maryland Advisory Board in Computing. He has an interesting take on the IT space and DevOps in particular. Read on for our discussion.

Alan Shimel: Michael, what do you think has been the “special sauce” that has led to Appian’s success to date?

Michael Beckley: With Appian, companies build unique business applications up to 20x faster and mobile-enable and modernize existing systems. For example, a company like Ryder was able to build a web and native Android tablet application that cut the time it took to rent a truck in half.

But the “special sauce”? That’s Appian’s culture of innovation. Our engineers think long-term and invest in breakthrough tech like our patented SAIL UI technology for zero code native mobile apps. Thanks to SAIL, the web apps you configure in Appian automatically deploy to iOS and Android as native, full-featured apps or specialized micro apps we call “Sites.” As long as we get the culture right, we expect to continue to deliver enduring value for our clients.

Shimel: With becoming a publicly traded entity, some companies have found “managing to the street” does not match their own long-term business plans and their customers needs, how does Appian avoid this?

Beckley: Companies, like people, are an aggregation of their habits. Appian’s habit has always been to hold to our long-term vision of enabling every company to be a software company. We are not your typical Silicon Valley tech company. Our roots are in DC, we largely bootstrapped this business, and learned to be good stewards of capital while helping to support the core missions of federal agencies and some of the world’s largest brands. The proceeds following this IPO will be invested back into our business to benefit our customers.

Shimel: What do you see post-IPO being the biggest areas for growth as it relates to new products and services?

Beckley: We plan to invest in innovating and enhancing our platform. While our platform is industry-agnostic, we have recently made, and plan to continue to make, investments to enhance the expertise of our sales and marketing organization within our key industry verticals of financial services, health care and government. We have made, and will continue to make, investments in research and development to strengthen our platform and expand the number of features available to our customers. As we continue to increase the functionality of our platform and further reduce the amount of developer skill that is required to build robust applications on our platform, we believe that we have the potential to expand the use of our platform.

Shimel: Digital transformation is a term that is being used a lot these days. How far along the adoption curve are we on digital transformation?

Beckley: While many speculate that digital transformation is just a tech industry buzz word, in reality, digital transformation is a living, breathing effort. According to a recent survey, digital transformation is a C-level priority and is considered a top focus for almost 50 percent of all companies this year. From Appian’s perspective, we believe that the utilization of low-code software to drive digital transformation is still relatively new and our customers will be able to succeed in their digital transformation efforts by incorporating low-code development.

Shimel: Where does the DevOps market intersect with the Appian business model?

Beckley: Organizations are turning to DevOps to accelerate development and bring an application’s capabilities to a user quicker. The Appian low-code development platform fits into the DevOps model and supports the seven major DevOps categories including code, build, test, package, release, configure and monitor.

Overall, our business model supports the DevOps market; we’re living in a world where citizen developers are playing such an important role in the enterprise and our platform empowers the citizen developer while alleviating developer resources to focus on the more challenging, business-critical developer work.

Shimel: What about containerization and microservices? How do these technologies affect Appian?

Beckley: Appian already uses containers and microservices. Appian’s enterprise customers often require a mix of cloud, hybrid cloud, and on-premise installations. We view containers and microservices as enabling technologies to support the diverse workloads and deployment models required by our enterprise clients.

Shimel: What about security? What challenges does cybersec pose to Appian’s development of their platform?

Beckley: Appian works with some of the nation’s most important and highly regulated industries, therefore we have built a comprehensive security and compliance structure that meets several industry standards. We frequently undergo third-party audits to ensure that we are always operating effectively to protect our customer data.

— Alan Shimel

June 7, 2017
VMware Moves to Automate Management of Hybrid Clouds

Moving to expand the reach of its portfolio of IT management software well beyond virtual machines, VMware today announced that the vRealize suite of IT automation tools can be employed across containers and virtual machines running on-premises or in a public cloud.

In addition to providing support for VMware’s Admiral container management portal, version 7.3 of vRealize Automation adds much tighter integration with both Amazon Web Services (AWS) and Microsoft Azure public clouds. For Microsoft Azure, vRealize now can deploy and manage middleware and application services. For AWS, vRealize Network Insight now can microsegment networks in an AWS Virtual Private Cloud as well as troubleshoot network traffic issues in AWS.

From a DevOps perspective, however, the most significant new capability is being added via an update to the vRealize Operations module: the ability to automatically deploy workloads across multiple clusters and datastores based on business policies defined by the IT organization, says Mahesh Kumar, senior director of product marketing for VMware. This update also adds a predictive Distributed Resource Scheduler (pDRS) that leverages analytics provided via vRealize Operations to predict anomalies and identify potential I/O contention issues before they occur.

At the same time, the latest update to VRealize Operations will incorporate a tab for vRealize Business for Cloud 7.3, which has been extended to provide cost and capacity utilization metrics for AWS and Microsoft Azure alongside VMware-based private cloud costs.

Other additions to the VMware portfolio include tighter integration between VRealize Operations and VMware vSAN storage software, NSX network virtualization software, enhanced blueprints for sizing deployments and integration with configuration management tools from Puppet. Kumar says that latter capability will be extended to include support for Chef and Ansible configuration management tools as well.

With these additions to the IT automation portfolio, VMware is clearly signaling its ambitions lie beyond its own hypervisor. Within enterprise IT environments VMware is dominant. That position has enabled it to gain significant traction in terms of driving adoption of its management tools. Now, VMware is moving to extend the reach of those tools into public clouds and containers. At the recent Dell EMC World 2017 conference last month, VMware debuted instances of its portfolio of software running on AWS. Most containers today are deployed either on top of a virtual machine or in a platform-as-a-service environment. But VMware is also aware of the fact that over time more containers will be deployed on bare-metal servers that are not running any type of virtual machine software at all.

Of course, just about every other provider of an IT management framework knows this as well. In addition, there’s no shortage of management tools designed specifically for containers. But as DevOps continues to evolve, most IT organizations are naturally expected to favor approaches that enable them to manage the broadest number of platforms possible.

— Mike Vizard

June 6, 2017