Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Translating legacy COBOL code to a slightly more modern language, and Arm will go public (again) next month. (more…)
At its HashiConf EU 2019 conference this week, HashiCorp extended the reach of its Terraform Enterprise tools for automating the management of IT infrastructure beyond the realm of DevOps into legacy IT environments.
Via integration with the Service Catalog from ServiceNow, IT administrators working with a traditional ITIL-based framework now can invoke Terraform Enterprise to provision IT services. HashiCorp CTO Armon Dadgar said rather than requiring organizations to hire an infrastructure engineer to automate the provisioning of IT infrastructure, IT administrators now can do the job.
At the same time this week, HashiCorp announced that policy sets may now be configured using the source policies available in multiple version control systems (VCSs), including GitHub, GitLab and Bitbucket. The goal is to make it simpler to enforce policies that would limit, for example, the number of virtual machines a developer might be allowed to spin up within the context of a set of GitOps processes, said Dadgar.
Finally, HashiCorp also announced that HashiCorp Consul service mesh networking software has been enhanced to include Layer 7 application traffic management capabilities alongside integration with the HashiCorp Nomad application and cluster scheduler software.
In general, Dadgar said HashiCorp is moving toward enabling its portfolio of offerings to span multiple types and classes of IT environments. HashiCorp Consul, for example, can be run across both legacy IT environments as well as Kubernetes. Most organizations will need to support both legacy monolithic and microservices applications using a combination of DevOps and legacy ITIL processes, noted Dagar. Rather than having to master new tools for each environment, HashiCorp is making a case for a common set of tooling that can be applied across multiple IT classes of processes.
While some organizations have fully transitioned to DevOps, many more organizations are still struggling to make the transition. Reasons for not making that transition faster range from simple inertia to a lack of skills. Rather than having to take an all-or-nothing approach to modernizing IT processes, Dadgar said HashiCorp is enabling each IT department to embrace IT automation wherever they happen to be on that journey, including being able to embrace new platforms as they become available.
Dadgar noted that level of extensibility is critical because most tools are still being brought into organizations from the bottom up by individual members of the IT staff, rather than being championed from the top down. In the absence of an executive mandate, Dagar said the path of least resistance is to make IT automation tools as accessible as possible to members of the IT team regardless of skill level.
There will, of course, come a day when IT leaders will try to rationalize processes around a common standard set of practices. The degree to which any IT organization has been able to achieve that goal, however, has been mixed at best. In the meantime, IT organizations will always need to keep their options as open and flexible as possible.
My conversations about innovation and the enterprise have afforded me an intimate understanding of the technological challenges companies are facing. Chief among these concerns, regardless of industry or sector, is digital transformation.
Just the other day, a C-level financial executive came to me seeking guidance on this topic. He said his company was on a mission to become a lean, mean, digital machine, and was currently leading four or five initiatives to modernize operations and convert systems from legacy to new. “We’re moving everything to the cloud, we’re building new apps, and our teams are working toward agile methodologies,” he said, “I’m proud of my teams for all the hard work they’ve put in—in fact, they’re worn out from all their efforts! But honestly, I feel like all this work hasn’t paid off. We’re not seeing the dramatic progress that was promised. What are we doing wrong?”
He’s not alone in his frustration. I’ve seen many organizations get excited about these kinds of changes, high on the notion that once they’ve knocked out a few initiatives, they will have conquered digital transformation and secured the future of their business through technological fortification. But I reminded him not to get too distracted by all of the technology jibber-jabber, and instead make sure to keep the big picture in mind: Digital transformation is, first and foremost, a fundamental shift in your business model.
It isn’t simply about switching from outdated technologies to newer, slicker solutions. It’s not about transitioning to the cloud or performing a complete upheaval of legacy systems or processes. And it definitely can’t be accomplished in a few steps or one fell swoop. In reality, digital transformation is a journey that requires a road map and strategic planning to ensure all of your initiatives support the greater movement toward agile, streamlined and more efficient, and directly address and impact your business needs and objectives.
To this end, I posed a critical scenario to this financial executive: Consider an industry competitor who is smaller, newer, more agile and less bound by the market. If this player were to become super successful, how would your company respond? And which parts of your business specifically would be responsive? His reply was that his company is adopting ideas from new-entry players, primarily online-only banks. He’s building a new mobile platform and revamping his web properties to make banking more efficient for his customers.
While these efforts certainly have value and no doubt will improve how he does business, it’s not enough to constitute a digital transformation. These changes won’t be enough to drive the fundamental shift that needs to happen. It’s more of a blended approach, which won’t be enough. Hybrid models can allow companies to survive—but not thrive.
We can draw similarities to the evolution of automotive technology. While internal combustion engine (ICE) cars have long dominated the market, about a decade ago electric vehicles gained real popularity as a superior alternative. However, there have been real obstacles in the way of pure electric vehicles going mainstream. For one thing, we have so much invested in the infrastructure to support ICE cars and very little in the way of making electric cars practical. While charging stations are expanding and becoming more common, we don’t have nearly enough to make pure electric travel the practical choice—for now.
What has been our interim solution? Hybrid vehicles. In response to the electric contender, we’ve developed a number of vehicles that bridge the divide between infrastructure and efficiency needs. We created ICE-electric hybrids to harness the beauty of electric without having to sacrifice on practicality as the infrastructure works to catch up.
So this is what our financial executive is actually doing: he’s going the hybrid route by borrowing some of the nice, fancy features from the new entry companies while keeping an entire foot of his company in the traditional ICE world. And though the hybrid movement has been serving us reasonably well with cars, it’s not a good approach when it comes to a technology strategy. In the world of enterprise tech, bi-modal IT is like a hybrid vehicle. Sure, it allows companies to say, “We’re getting more electric!” But if they make the mistake of designating a hybrid operating model as their end goal, they’ll be stuck with split IT personalities and bifurcated cultures.
Organizations can get by on a hybrid approach, but only for so long. They may be able to modernize in part and reap some of the benefits of better technology, but it just gets too expensive to be sustainable. Hybrid necessitates investing in both types of infrastructure—legacy and new, gas stations and charging stations—to keep services running. In the long run, this holds companies back from truly taking advantage of all the benefits of electric, and they need to build transition technologies between ICE and electric components to make them run as smoothly and efficiently as possible.
“Okay, so hybrid’s not the way to go. What do I do instead?” the financial executive asked. My answer is to create a space expressly for innovation. You should compile whatever resources you can to create an entirely independent division of your company (or even a separate company) that makes room for innovation. This arm would be free from the constraints of legacy systems, free to ignore the norms of its parent, and free to create its own rules and business model. Using our example from the automotive industry, you can think of it as akin to General Motors creating an entire, standalone electric division, rather than simply converting Chevy models into electric versions.
While your organization may be in survival mode in the near term, you can’t lose sight of the pure electric play. Think about the inevitability of the electric car age: Battery prices will continue to plummet, driving ranges will increase, charging stations will multiply and the auto industry itself is investing in both EV and air pollution standards. We’re not putting all of our money on oil anymore.
So as you move forward on your digital transformation journey, be mindful of your true end goal: to have your business thrive through this technology cycle and the next (and hopefully the one after that, too). Going hybrid is a necessarily survival mechanism, but only as long as it builds momentum and helps drive you toward success.
Abbas Haider Ali brings over 16 years of experience in networking, cloud services, software, and cloud communications. As CTO of xMatters, he is responsible for evangelizing the adoption of communications-enabled business processes, and has worked closely with more than 400 global enterprises and IT organizations to create a vision for adopting intelligent communication strategies across business scenarios. Abbas holds a BASc in Computer Engineering from the University of Toronto.
I’m not sure if you’ve noticed, but the pace of the world seems to continue accelerating. Organizations—and the developers and IT teams that work in them—need to be able to adapt and respond quickly to changing demands. DevOps addresses this challenge for app development and IT infrastructure. However, a new application lifecycle equivalent is emerging, called AppOps, which seeks to bring the same sort of efficiency and agility of DevOps to existing IT services.
Just as DevOps creates an automated life cycle between software development and IT operations, AppOps streamlines application analysis, deployment and management. Sparked by the emergence of BYOD and the consumerization of IT, AppOps simplifies how IT securely delivers and manages existing enterprise and browser-based apps, while quickly adapting to demands of line-of-business managers.
“For a long time now, businesses have shifted toward ‘commercial off-the-shelf’ software packages in hopes of saving resources,” says Calvin Hsu, vice president of Product Marketing for Windows App Delivery at Citrix. “However, this shift toward packaged software doesn’t change the operational needs for IT. They need a fast, simple way to securely roll out and deliver new applications in alignment with operations—an AppOps approach.”
According to Hsu, AppOps provides a variety of potential benefits, including:
Hsu says that app and desktop delivery simplification and collaboration between vendors is simplifying how IT deploys and delivers apps to employees—virtually, centrally, securely and reliably. He adds that cloud-based management infrastructure makes it easier for IT to offer a menu of services to help business managers determine which apps and data resources will work best for their teams.
On the one hand, AppOps seems like a natural evolution of the DevOps culture. On the other hand, it also seems like it’s just an extension of DevOps rather than its own separate thing. It is simply taking the DevOps culture—breaking down silos and removing roadblocks to streamline collaboration—and applying it to existing IT services.
What do you think? Is AppOps the “next big thing” or just a new buzzword being applied to the same old DevOps?
Legacy information technology infrastructure has a strong effect on the potential success of DevOps. In environments where different teams have always used the same servers, change can be difficult due to inter-team coordination and limited server transparency and application inventories, says David Blank-Edelman, a 30-year systems administration/DevOps/SRE veteran and currently Technical Evangelist at Apcera.
“Unraveling the Gordian knot to bring DevOps principles and practices into that environment will be quite a challenge,” he says.
In such a legacy environment, the enterprise walks a topological tightrope stretched between one or more development machine clusters shared by multiple teams with no real isolation between teams and projects, Blank-Edelman notes. “In most cases, there is a second parallel set of machines for production and, if the business is very fortunate, for test/QA as well. There is seldom anything, however, to prevent a production workload from talking to a database server in development by mistake, which can lead to all sorts of fun.”
One solution is a policy system approach, in which the organization provides for a policy system to migrate a legacy information technology environment to a platform that uses continuous delivery (CD), Blank-Edelman says.
To create the policy system, he notes, the organization will need to address questions such as:
“The process of developing a policy system and then enacting it can lead an organization on a journey that brings their existing infrastructure to a much better place. If that platform can also automatically enforce the decisions that organization made during this question and answer discovery process, you can be certain that the answers to these questions stay answered,” says Blank-Edelman.
Other approaches to moving to continuous delivery include tool-first approaches in which the organization adopts one to several CI/CD/workflow tools and then makes an effort to implement those, possibly by shoehorning existing processes and runbooks into that tool or toolset.
A better tactic is the people-first or culture-first approach that focuses on how the development and operations personnel will work together to create a product vs. a project, says Blank-Edelman. While tools still have a role to play in the people-first approach, they are not the priority; rather, organizational change comes first. Once the people have made the commitment and the change, everything else will follow.
It’s not the existing information technology infrastructure that presents moderate challenges to CD that is the issue; it’s the infrastructure that poses either very many challenges or very few that is the hurdle. “If you start with a more challenging situation, this will incentivize people to work very hard to reduce the associated pain points in their life,” Blank-Edelman says.
On the other hand, he notes, when an organization begins a move to CD with an infrastructure that is already in pretty good shape, you won’t often hear its people say that they should stop working on the product and work on CD all the time instead. People will still claim they have plenty to do already.
Continuous delivery starts with a code base and takes logical steps through that code base to increase confidence that it is ready for production, using a process that is as smooth, automated and loosely coupled as possible, he says. With confidence in that pipeline comes confidence in moving the result of that process into production automatically, which is continuous deployment, he adds.