devopsy.kinsta.cloud

Tag: legacy

IBM Adds Lower-Cost Linux Mainframe to Portfolio

IBM today made its most aggressive move yet in its quest to make mainframes running Linux more affordable, launching an entry-level platform starting at $135,000.

The IBM LinuxONE 4 Express is a pre-configured rack system that is based on the same 5.2Ghz IBM Telum processor that IBM uses in its Z16 series of mainframes.

In addition, the platform supports IBM Secure Execution, which is designed to thwart any attempt to decrypt data in the future using quantum computers.

IBM claims organizations that move Linux workloads from x86 servers to an IBM LinuxONE 4 Express can save over 52% on their total cost of ownership over five years.

The overall goal is to make it simpler for organizations to consolidate workloads that otherwise would need to be deployed across a distributed computing environment, she added. That approach ensures higher levels of availability for workloads that are increasingly processing massive amounts of data using two levels of physical and two levels of virtual cache in a way that consumes less energy, noted Tina Tarquinio, vice president of product Management for IBM Z and LinuxONE.

The IBM LinuxONE 4 Express also includes an integrated accelerator for running artificial intelligence (AI) inference engines using more than 6 TFLOPs compute capacity per chip.

IBM expects that as more organizations process sensitive data to drive AI applications, there will be increased interest in deploying applications in more secure on-premises IT environments, said Tarquinio. Mainframes provide a more cost-effective way to achieve that goal at a time when DevOps teams are embracing methodologies such as platform engineering to centralize the management of workloads, she added.

At the same time, increased reliance on automation is making it simpler for IT teams to rely on multiple types of platforms to optimally process workloads. That capability enables IT teams to make platform decisions that are based on fit-for-purpose best principles more easily, noted Tarquinio.

It’s not clear how many organizations will now be able to afford a mainframe when the initial cost of an x86 server is still much lower. But in the face of ongoing economic uncertainty, it seems more organizations are willing to consider all their options. The issue is that adding additional X86 servers is often viewed as the path of least resistance to increasing compute capacity.

Naturally, each IT team will need to decide what path forward makes the most sense for them, but as workloads continue to become more data-intensive, it’s clear that infrastructure requirements are changing. The more data that needs to be processed, the more challenging it becomes to maintain service level agreements that are based on maintaining specific levels of application performance, noted Tarquinio.

The challenge now is determining where best to run those workloads across an increasingly hybrid cloud computing environment that continues to offer more options as IT platforms evolve and expand.

February 6, 2024
IBM LLM AI: COBOL to Java ASAP ¦ ARM IPO is GO!

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…)

August 23, 2023
FAA Ground Stop due to Technical Debt? | Don’t Do DIY Crypto!

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: The FAA’s NOTAM database gets corrupted, and Threema shows why DIY cryptography is bad. (more…)

January 12, 2023
Cloud Migrations Demand Risk and Compliance Maturity

The COVID-19 pandemic brought undeniable disruptions for organizations and their employees whether business, personal or otherwise. Across the globe, businesses and governments alike were forced to try and manage these disruptions. For nearly all organizations, digitization initiatives were accelerated in a short period of time, from implementing work-from-home policies and launching new applications to support a distributed workforce to adopting artificial intelligence (AI) to adapt supply chain processes and more.

According to Gartner, by 2022, 30% of all security teams will have increased the number of employees working remotely on a permanent basis and by 2023, 40% of all enterprise workloads will be deployed in cloud infrastructure and platform services. The distributed cloud enables organizations to provide products and services when they’re needed in this era of work-from-anywhere, whether to their employees or customers.

Even in sectors such as energy and utilities, which are historically heavily reliant on standard on-premises installations and had often avoided cloud adoption, business leaders are realizing the value of migration, especially in light of the global pandemic. These businesses are able to deliver digital products with speed, experiment with tools such as artificial intelligence (AI) and robotic process automation (RPA) to increase productivity and to lower the total cost of ownership (TCO) across assets, among other benefits. Still, cloud migration risks abound, and new challenges may arise. A risk that cannot be ignored is the cybersecurity risk. Meeting regulatory IT compliance and managing risks involved with cloud computing are top challenges facing those migrating their workloads to the cloud.

Cloud Migrations and Security: Clear Risk and Compliance Gaps

Many cloud providers such as Microsoft Azure, AWS, Google Cloud and others have a global network of service models that include compliance teams and consulting organizations that help with risk and compliance for their cloud instances, whether public, private or hybrid cloud. Many of them have even built tools for customers to use to implement basic risk and compliance management in-house, leveraging relevant data and applications. However, monitoring and meeting security and compliance controls that span people, processes and technology for cloud environments, and in the broader context of the enterprise, is complex. This is one cause of cloud migration risk, and is a challenge for many other reasons; lack of measurement, visibility and accuracy are three of the greatest risks when migrating to the cloud. The point solutions that currently support most cloud instances don’t elevate the posture of cloud environments to that of the enterprise risk posture, and the majority of assessments still remain point-in-time and qualitative. Metrics are fractured and far from holistic, and very few, if any, solutions can provide insight beyond compliance and into real-time risk management.

IT and security regulations and standards are filled with requirements that were created before the cloud became a commodity. In the energy sector, for example, cloud security isn’t taken into account because regulators and industry leaders couldn’t fathom those platforms becoming as pervasive as they have, because on-premises installations were standard to the industry. On-premises installations are still a mainstay in energy, power and utilities, and for those who have become more comfortable with cloud migration processes, there is a clear and pressing need to leverage their human capital, processes and technologies to implement robust risk management practices.

Beyond regulatory compliance lags, many distributed organizations opt to have multiple providers in place, requiring a multi-cloud approach to compliance requirements and risk assessment. As more organizations consider cloud migration risks and begin shaping their cloud migration strategies, there are some innovations that address risk management and compliance in the cloud, but not many. Measuring, managing and reporting on compliance frameworks, making the shared responsibility model actionable, and getting a view into risk are all serious challenges. Cloud providers will continue to mature and bring new innovations to their services, but, to date, there hasn’t been a lot of anticipatory work done in this area. The focus has largely been on creating reactive solutions. In heavily regulated countries, the challenges only become greater.

Leverage AI Automation for Compliance and Risk Management

There is a shift occurring in cybersecurity and IT risk management, calling for the dramatic disruption of the legacy IT governance, risk and compliance (GRC) space and demanding a reevaluation of how we manage compliance and risk in the digital age. For years, data has been aggregated manually and analyses performed on out-of-date information. With the increasing availability of automation, the five functions of the NIST Cybersecurity Framework – identify, protect, detect, respond and recover – are becoming more continuous in nature and shifting into real-time management, from assessment to reporting and more.

Leveraging this technology in the cloud is no exception, but those who look to reinvent their approach must look for solutions that go beyond the siloed capabilities of cloud security posture management solutions and similar markets.

Ultimately, the true test of this next-generation approach comes when organizations are able to roll all of this data up to risk. With risk metrics that are supported by drill-downs, trend reports and risk profiles, executives can get the visibility they need into their posture with the most up-to-date data, informing their key business decisions. Using this next-generation approach to risk will inform global expansion, allow executives to evaluate risk across lines of business, and increase cyber maturity in any cloud-based organization.

March 2, 2021
Where is the Next Generation of Mainframe Talent?
Are we potentially facing a shortage of mainframe talent?

“Three of us set up this tool in 1989. One is retired, and the other person is somewhere in heaven!”

That was the remark of Alf (name changed), the senior mainframe architect at a large European enterprise, as he pointed toward the ceiling of the meeting room. Everyone else in the room let out a half-nervous smile, unsure how to react to the statement and hoping for some visual cues from Alf. We were all talking about a specific version control and packaging tool on the mainframes, which was heavily customized to suit this particular enterprise. The attendees were a mix of DevOps enthusiasts and mainframe architects and engineers with the purpose of re-evaluating the existing tooling stack on mainframes with a view to modernize them as part of a wider agile/DevOps initiative. Alf’s remark in the meeting has stayed with me ever since.

Later that week, I was having lunch with a group of new joiners in the technology department, who were all part of a greenhouse initiative to in-source digital skills. During the conversation, I asked which areas where they focused on and the career direction they had in mind. The answers were predictable: data science, python, Nodejs, UX, blockchain, JavaScript etc. If all the new kids on the block are learning the newer technologies, then who will take over from mainframe people over the next few years when they retire?

The reality is that 96 of the world’s top 100 banks, 23 of the 25 top U.S. retailers and 9 out of 10 of the world’s largest insurance companies run IBM’s System z mainframes. Most digital transformations have barely scratched the surface of the legacy stack.

Like many other enterprises, this enterprise had outsourced most of its application estate to IT service providers. In few years’ time, Alf will move to a well-deserved, retirement phase of his life and take his mammoth knowledge base that the enterprise had always taken for granted. There are many more Alfs across various enterprises today with significant mainframe know-how who are set to disappear from workplace over the next few years, making these enterprises entirely dependent on external service providers—so much for those bold visionary statements for the CXOs such as, “Technology is business and business is technology.”

Most enterprises today have ambitious digital transformation agendas, investing millions on various initiatives ranging from digital, DevOps, agile, UX and blockchain. This will manage to “DevOpsify” the enterprise skin (aka front end, customer experience layer, or mode 2 apps) and, in many cases, possibly, their non-legacy middle-end system as well. However, the majority of the back-end stack, especially in financial services, remains in the legacy world (zSeries or iSeries).

One might argue with a seemingly coherent logic that, “Well, we won’t have mainframes in a few years as we will move to newer platforms soon.” But it helps to remember Mark Twain’s quip, “The rumors of my demise are greatly exaggerated,” applies so well to the mainframe world!

In simple terms, your enterprise most likely will adopt a combination of the following strategies to deal with the legacy challenge:
- Retire mainframe app, in some cases.
- Extract business logic and move it to distributed platforms.
- Componentize the monolithic mainframe code and hook them to APIs for external consumption.
- Build new platforms to replace legacy apps.
There is one least common denominator for any of the above strategic direction that your enterprises take: ever-diminishing mainframe knowledge! So, I ask again: Where is the next generation of mainframe talent?

— Aditya Vadaganadam
October 25, 2018
Enterprise Infrastructure: Adapt or Face Extinction
In my previous blog, I explored how new ways of working—DevOps, Agile, cloud and startup thinking—have brought in a tectonic shift in the ways of working of enterprises. For infrastructure leadership and management, this is nothing short of a perfect storm that they need to navigate.

While these new ways have impacted every aspect of technology including development, testing and project management, infrastructure and operations have remained the last bastions of traditional thinking, practices and approaches. Even with the rapid rise of DevOps practices in the recent years, we have just seen pockets of change in the infrastructure space, be it adoption of infrastructure-as-code practice, cloud in its numerous variants (private, public or hybrid) or containers and cloud-native technologies. But these changes all fall short of an enterprise-scale change that matters. What is missing is a systemic view of infrastructure as a value stream and transformation that ventures beyond the skin-deep changes limited to a few front-end digital capabilities.

Infrastructure Transformation on the Horizon

However, this is changing now; one by one, the barriers to infrastructure agility are breaking down. To put it simply, there are four dimensions of this change, based on various enterprise transformation initiatives that I have been involved over the years

Radical new Operating Models

New operating models are emerging to meet the business demand for infrastructure agility. There are primarily five patterns or a combination that enterprise are espousing in the operating model space:
1. Shared service: This typically involves applying lean, value-stream mapping and Kanban techniques—in simple terms, the emphasis is on transparency, business-aligned prioritization of work and limiting work in progress.
2. Responsive shared service: In this model, specific infrastructure members are “seconded” to application squads for more responsive service. However, there are limits to secondment model, in the ability to scale beyond a few iconic programs of work.
3. Cross-skilling: This model involves infrastructure and application team members learning skills across each other’s disciplines with the goal of making delivery teams self-reliant.
4. Disrupting with cloud: As the name suggests, enterprises are disrupting their own traditional infrastructure capabilities by aggressively pursuing private, public and hybrid cloud capabilities.
5. Insourcing: Increasingly, there is a trend to insource responsive cloud and DevOps-based services to near-shore locations. “Almost twice as many CEOs are intent on building up in-house technology and digital capabilities as those plan on outsourcing it (57 percent and 29 percent, respectively),” according to Gartner’s survey of CEOs in 2017.
Reimagining the Legacy Technology Stack

Legacy systems based on technologies such as the AS400 or mainframes have been the bedrocks of technology for decades, but they also have been blamed for constraining agility. Many organizations have realized that replacing legacy systems with open system stacks is not an easy feat. Consider the fact that IBM continues to report an increase in mainframe sales over the last few years, including Q4 2017. This points to the fact that legacy will be part of the enterprise landscape for years to come—as such, incumbents need to be able to leverage the legacy stack to compete with digital challengers who are unencumbered by similar technology constraints.

However, it is not all somber. There is a new wave of optimism driven by old guards, including CA and IBM, and new, including Compuware and ARCAD, that are bringing modern engineering practices such as continuous integrationcontinuous delivery (CI/CD), automated code analysis, virtualization, lightweight integration and test automation to these platforms. These new practices not only give these systems a new lease on life, but they also enable modern enterprise systems to be built iterative and incrementally—and not be handicapped by legacy constraints anymore.

Intelligent Enterprise Resource Planning Software

ERP software such as SAP/R3 are the backbone of many enterprises across industries. Historically, ERP software products have not kept up to speed with modern engineering practices and flexible architecture, which are fundamental to agility. The good news is that the ERP landscape is changing as product vendors are embracing cloud and API-led integration—IDC calls this “intelligent ERP” or “i-ERP.” Consider this: In 2025, SAP/R3, the largest ERP product in use, will no longer be supported officially, and enterprise planning programs (albeit, in a waterfall way) will move to SAP HANA Enterprise Cloud, the company’s new generation ERP platform.

Culture and People

Years of the drumbeat of Lean, Agile and DevOps ways is yielding results, especially in those organizations that see this as a people change as much as technology change. People in the infrastructure world are changing from operating being behind a queue toward being customer-focused, collaborative and value-seeking. Organizations need to address the structures that restrained it from moving forward on the journey. Traditional organizational structures don’t account for team strengths, nor do they give everyone fair input in regards to overall direction. Rather, structures should be set up that allow managers to empower teams instead of teams living to carry out management demands.

Ultimately, the key to creating agile and responsive infrastructure in organizations starts at the top, from the CXOs who need to realize the scale of change and inspire their teams on the need for change—or face extinction.

— Aditya Vadaganadam
April 25, 2018
Think of the Future When Building Delivery

We’re in a strange state of the pendulum swing right now, where speed of delivery is king and all else seems to take a back seat. Many orgs even place quality behind speed in the claim that “we’ll get it right later,” but I’m talking about the more universal rush to deploy and the infrastructures we’re building to do it.

In short, look around your organization. Do you have apps more than 10 years old? Are you working on the same type of app? Then spin your mind ahead and consider what it will be like for someone in that time.

Future-Proofing Delivery

You cannot stop the advance of technology, but you can make the environment adaptable. There are some easy tricks to provide for the future when it comes to your DevOps toolset.

COBOL Still Needed. Source: Hackerrank.com

Virtually Perfect

First, build your continuous integration/continuous deployment/application release automation (CI/CD/ARA) architecture on virtual machines (VMs) or cloud instances. If your standard is containers, then use them—but on top of a VM. The reason is simple: Given the vagaries of business environment and IT priorities, a fully installed VM gives you a buffer—you have everything needed to run the environment in a contained package. Containers alone won’t be good enough, as the underlying OS impacts container operations. As an extreme example, the switch to Red Hat Enterprise Linux (RHEL) 7.0 was massive and broke things. A DevOps environment based solely on containers would break with it, while a VM running RHEL 5 or 6X would keep clipping along, as long as your virtualization environment ran.

Get Versions In-House

While the executables for any CI/CD/ARA toolset and development languages will be in-house, there is far more to a modern development environment than just those parts. The libraries/modules your code relies on must be available. Increasingly, we pull them on build, but that becomes a problem when suddenly they are significantly changed or downright missing. There is a market of hosted, verified module vendors out there these days that guarantee availability of a given version of each module they support, and that is an option; however, a better one is to pull them once and put them into your own enterprise repository. Is it another thing to maintain? Yes. But it might save your project from having to emergency patch—and frankly, that kind of insurance is worth it.

Choose Wisely

Like any relatively new market, there are a lot of CI/CD/ARA toolsets out there. Do evaluations; don’t just grab the one that a team member likes or is familiar with. Look at the longevity and stability of the project/vendor as much as the tool, because we’re talking about hedging for the future. In the early days (and even occasionally today), open source aficionados would say “We have the source, we’ll do fine,” which is technically true, but most organizations aren’t in the business of maintaining their dev/deploy tools and don’t want to be, so a little research goes a long way.

Plan as Though You Chose Poorly

Know what you’ll do if, in spite of evaluations, the project/product you chose goes away. While it’s not CI/CD, I was on a team that selected Mambo right before the big team split that created Joomla and doomed Mambo. Our choice was intelligently made based upon available information, but things still came around to burn us. And it could happen to your choice, too, whether you choose open source or commercial. So have an idea of what you would do in that scenario and document it. If we adopt enough IT tools, it’s guaranteed that some of them will fail over time, so this is not a totally wasted exercise. And should you ever need it, knowing what the plan is before things are falling apart helps keep level heads.

Quality Over Speed

Remember that time to delivery is super hugely important, and for decades was not given the credence it deserves. But as I mentioned above, recognize that right now the pendulum has swung so far the other way that many shops have a “just get it out, we’ll make it better later” mentality. Don’t join in where your DevOps environment is concerned. The architecture you are constructing should be for the long run—unless you enjoy rebuilding it regularly and the delays to production code such rebuilding threatens, then ignore this point.

Security, Security, Security

DevOps and security has had a rough relationship, but let’s talk about your DevOps environment instead of security’s impact on rapid delivery. Once you’ve thrown all of your build into one easy-to-use tool, the risk from a successful outsider or a risky insider is commensurately larger. Use tools that support role-based access control (RBAC) and make sure application programming interfaces (APIs) are properly locked down. Give security the time it needs to build a list of recommendations for DevOps toolsets that will protect them in almost any eventuality. Because the combined ability to mess with the build process and the deployment process through one automated toolset is powerful and dangerous, make sure you’re monitoring and it’s secure.

Consider a Modicum of Standardization

In my entire career, “We are an X shop” has never seemed to work. I’ve been at places that tried to use a single database vendor or a single development language, and inevitably, other forces override these directives. But there is a benefit to keeping the number of languages or database variants down, and that benefit is most felt in the CI/CD space. Keeping track of which DB goes with this project, or keeping that DB up to date—or determining the new release will introduce incompatibilities—all falls on the DevOps environments. Keeping the amount of accumulated future change down is in the organization’s best interests.

Make Cool Stuff

Every time I think I’ve maxed out on awe, something new comes along. We are on the cusp of fully automated build/test/deploy with ARA tools calling both CI/CD tools and application provisioning tools. Keep pushing the edge, give vendors your feedback or projects your mods, and making it better. Because there’s a fundamental change here that we want to see through to the end. And I love playing with the toys.

— Don Macvittie

April 24, 2017
DevOps in Legacy Systems: A Mission Impossible?

The word “legacy” evokes mixed reactions from the IT and business crowds alike. For those who depend on legacy systems such as the zSeries and iSeries platforms, it is a way to deliver stable and reliable applications into production. Business stakeholders who may not know the intricacies of the technology often take a view of, “Why fix it when it ain’t broken?”

On the other hand, for those who haven’t experienced the joys and pains of legacy systems , legacy world will continue to defy their logic and assumptions because their view of the world is shaped by the open system world which has completely different characteristics: being more malleable to change and easy to maintain etc. Hence there is this great divide between the legacy and new worlds. Add Agile and DevOps to the equation with the lofty goals of increased release frequency and reduced lead times, we end up with a divide that is too far to bridge.

The likes of Gartner have come up with constructs such as two-speed delivery to help deal with this legacy challenge. In my view, there is a problem with the idea of dual-speed because it is based on a wrong analogy to start with — that of allowing vehicles to move at different speeds depending on whether you are on the motorway or a city road. That analogy works well for traffic management scenarios but not for complex IT architectures we see in the enterprise. The dependencies across the systems in the enterprise landscape are just too intricate and too tightly coupled to be defined using such a binary logic. In my experience, I find that many Agile and DevOps transformations hit the roadblock and never achieve the desired levels of productivity and effectiveness because of an oversimplified view of these complex dependencies across legacy and open systems.

The three biggest challenges that prevent a legacy DevOps transformation are mindset problems, architectural constraints and tooling limitations.

The Mindset Problem

“There are no legacy systems, just legacy thinking.” That’s a great quote I heard recently from an engineer in a large organization trying to adopt DevOps at enterprise scale. The initial resistance from teams to move into DevOps ways is due to reluctance to change, emerging from an inertia of doing things a certain way for years if not decades. The mindset problem is as much a problem for those outside the legacy world as those inside. The “outsiders”—typically leadership, management team and consultants—tend to oversimplify the problem and, too often, rely on examples from the open systems world. This just alienates the incumbent legacy teams and makes them even more skeptical of DevOps driven change. The outsiders need to have a genuine appreciation of the challenges with legacy architecture and need to work in collaboration with the legacy teams if they really want to transform their organization.

Architectural Constraints

Legacy systems have certain characteristics such as being static, tightly coupled and monolithic blocks of procedural code. These systems were not built for the modern Agile workflows that focus on incremental and iterative deliveries. A significant majority of these systems are written to operate in batch mode.Testing the systems requires cycling through multiple business days, which simply limits the level of agility you want to introduce in the organization. I am currently working with a legacy engineering team in the financial services space where you have to cycle through a minimum of 20 business days to simulate even 70 percent of the test scenarios. However, there are a number of solution options to overcome the architectural challenges; they range from killing applications to migrating to modern platforms or re-engineering legacy code. Not surprisingly, the right approach depends very much on your context.

Tooling

Tooling in the legacy world to support a DevOps ways of delivery has always been a challenge. But it is fast changing now, thanks to a number of startups and even old-school IT product companies investing in this space. If you consider zSeries as an example, there are better IDEs (integrated development environments) such as RDz that can replace traditional code editors typically based on “green screens.” These IDEs provide great features such as better navigation, debugging, split views and searches on the legacy code. One of the CIOs I worked with made it clear to his team that he wanted to get rid of “green” screens from the IT floor. There are tools such as SmartBear Collaborator that support a great peer review experience and help bring one of the original XP practice of pair programming to the legacy world. There are tools such as endeavor from CA that promise automated build and deployments in the z-series world. Similarly, there are tools that support test automation of mainframe applications and tools for code coverage and code quality checks on legacy programming languages like COBOL. XATester looks like a promising tool for unit test automation from a Danish startup called Xact.

While this write-up is not intended to be a compendium of all DevOps and engineering tools, the central message is that there are a number of DevOps tools emerging on the legacy landscape which can help your legacy delivery teams get on to the DevOps and Agile journey.

What is more important is for organizations to realize that many of these legacy systems will remain part of their IT landscape for the next foreseeable future and it is time to invest in these core systems. They may not look as appealing as the digital platforms, but they are fundamental for businesses and you cannot ignore them on your DevOps journey. DevOps in the legacy world is not going to be smooth, but it is certainly not a mission impossible!

— Aditya Vadaganadam

March 17, 2017
Good News: DevOps is not One-Size-Fits-All

Want to try something fun? Ask different groups around your organization what “DevOps” means. It’s fun because the odds are good you’re going to get very different answers, many of which will be vague, if not outright contradictory. This is perhaps unsurprising when even industry-recognized DevOps luminaries tout varying definitions, approaches, tools and methods.

Here’s what’s not so fun: trying to figure out how DevOps might look at your organization, and what resources and amount of time it would take to do it right. The one thing upon which everyone seems to agree is that “DevOps is a good thing” and something organizations ignore at their peril, in light of the significant competitive edge it provides.

Here’s the good news: DevOps is not one-size-fits-all. In fact, there are many different facets in defining DevOps relative to your purpose(s). This article will identify some of the axes along which the answers to those questions fall, and sketch how they contribute to the overall picture. By the end, you should be better equipped to navigate your organization through the resulting, thoroughly non-Cartesian witch-space that is DevOps today.

Axes and Allies

My use of “axes” in the previous paragraph was neither random nor merely picturesque. It was chosen because it’s a bit of a chameleon, the only English word that can be the plural of three separate noun forms. In short, you don’t know what the word means apart from context. The same is true of DevOps.

Linguistic pedantry aside, DevOps grew out of the organizational friction between developers and operations, hence the name “DevOps.” But the DevOps movement pearl unquestionably has been layered and shaped by the oyster of today’s development trends: the increased (if not nearly exclusive) focus on web and mobile applications. This is simply because it’s an easy fit, those products often being much simpler to build and deploy than legacy applications.

This gives us the first axis: the industry (or industries) in which you compete. If you’re building the next great social networking site—please don’t, I beg you!—you’re going to have a tough row to hoe. And you’re going to have to do at at the speed of Web whatever-dot-oh. Because continuous deployment isn’t an option for you; it’s your personal Obi DevOps Kenobi (your only hope). Yet, at the other end of the spectrum, even the most legacy-heavy manufacturing concern can benefit from DevOps principles, though the requisite pace of innovation should be rather lower.

Industry also can determine the degree to which you accumulate necessary but hard-to-satisfy stakeholders. In the medical industry, for example, keeping your compliance department happy is both essential and more than a full-time job in itself. The DevOps drive to deploy quickly will run straight into the sort of bureaucratic inertia one expects in a heavily regulated industry. You’ll likely need to temper your DevOps expectations and shape your processes to deliver and archive additional content if your industry is more legacy than modern.

A second axis around which DevOps revolves is the type and level of maturity of products you deliver. The more you lean toward legacy products, languages and processes, the more you’ll likely need to scope and direct your DevOps efforts differently, depending on the answers to a variety of questions. For example, it’s rather a different thing to build, test and deploy a monolithic C++ application than an app intended for the web or mobile devices.

Ask yourself: How complicated are the true essentials of your build process? Which parts can you tighten? Can you isolate and prebuild components and leverage an artifact management system? What build artifacts must be retained to satisfy support, compliance and other stakeholders relevant for your industry? You’re going to need tools that can handle the load in every sense.

Similarly, how much testing can you realistically automate for the best payoff? And what sorts of testing will give you the strongest guarantee of success for the effort? Unit tests are a good start, but have you automated your all-up functional tests? What about UI testing? Stress testing? Again, the type of industries you serve and the type of products you create will generate different test demands and degrees of time and effort to automate your test suites.

A third axis along which to evaluate DevOps is your organizational culture. I’ve heard “legacy” defined as code lacking unit tests, but this seems incomplete. I’d suggest that, in fact, there’s a legacy state of mind as well, by which I refer to the sort of inertia that accretes in products and organizations over time. You’ll find it expressed in “the way we do things.” If that phrase is a discussion-ender at your organization, then you’re going to have a much more difficult time embracing DevOps.

What allies can you bring to the table to push for necessary change? Attending a DevOps conference or event can connect you with experts with experience in your industry who might be able to recommend materials. The more your organizational attitude “leans toward legacy,” the more you’re going to need a thick bench of allies to make DevOps a reality.

Leaving a Good Legacy

If it seems as though I’ve been hammering on the notion of legacy in all its forms, I have. But it’s important to recognize that legacy isn’t always a bad thing; in fact, legacy applications are essential to a non-trivial fraction of our world. Not every need can be met with a web or mobile app. It can be very difficult to tame the legacy beast in all its forms, but it’s nearly always possible to at least trap it in a well-defined cage, then shrink that cage over time.

DevOps principles can raise your game no matter how legacy your industry, products and personnel are. But it’s important to understand where you fall on all the relevant axes to determine the right scope, methods and tools to deliver the most value. DevOps isn’t one-size-fits-all, but it can be tailored to fit in at your organization.

About the Author / John Williston

John Williston is a veteran software developer for Windows, .Net, and the web. He is currently a product marketing manager at Perforce Software.

August 5, 2016
DevOps and legacy system lessons from dwarf planet Pluto

If you’re a bit of a space geek like me, then maybe you’re one of the 243 thousand plus followers of #NASANewHorizons; diligently monitoring deep space twitter sphere for the latest news and pictures from dwarf planet Pluto.

The success of the New Horizons project is incredible – especially when you consider it’s all been delivered by legacy technology. Technology that lifted off back in 2006 – when Pluto was a real planet and before we had the iPhone, mobile apps, social media, Big Data, the Internet of Things, oh and DevOps.

So why did this nine year old piano-sized hunk of tech deliver so impressively, and what lessons are there for those of us in IT managing our own legacy systems and applications? Actually there’s a lot we can learn from the outer reaches of our solar system.

Even in Deep Space constraints can be managed

The New Horizons space probe is an extreme example of a constrained physical system. Three billion miles from home, command sequences take 4.5 hours to reach the probe and the consequences of screwing as it barrels along at a lazy 30K mph are, well, pretty severe. Of course NASA scientists have a fallback – they use a simulator with engineering and telemetry models to test the commands that perform all the vital spacecraft activities.

In business computing we don’t have the luxury of having spare hardware of tap – especially for large legacy systems. Too often access to systems and data needed for development testing is constrained due to schedules, contention, security restrictions or service provider usage fees. To address this many organizations attempt costly provisioning of lab infrastructure, but these often don’t fully reflect production condition.

As with New Horizons, constraints within IT can be eliminated with technologies that model and simulate the behavior of dependent systems. This not only lowers infrastructure costs, but also helps teams move testing activities earlier in the lifecycle, where in parallel with development help detect software defects well before they impact production systems.

Change and release co-ordination is critical

Just days out from its rendezvous with Pluto, New Horizons suffered a minor glitch and lost contact with the earth. For a $700 million probe at the edge of the solar system, that caused a few jitters. Then after a day of analysis (and maybe some head scratching), mission control tracked the problem to a timing flaw in the spacecraft command sequence. Basically, the main computer went into safe mode after being asked to do two intensive tasks at once.

In enterprise tech our own legacy applications play an essential role in supporting key business processes. As such, and like New Horizons, changes must be carefully coordinated. What’s different, however, is the scale of the challenge. Multi-tier release deployments by nature are inherently complex with many dependencies. Automation therefore is critical, as are reusable and repeatable deployment processes to streamline application releases involving legacy systems.

Data can be exposed and utilized in different ways

It’s interesting to see how NASA have exploited social media for the New Horizons mission. Thanks to blogging, podcasts and Facebook all the news and fantastic images are now easily accessible. From the web-site too, the twitter API has been exploited to provide a constant channel of updates and facts about the legacy technology – did you know for example that the original PlayStation CPU (MIPS R3000) is used in the probe? – I guess if it worked solidly for a 100 million game units it can fire some thrusters 3.5 million miles out in space.

Businesses operating in an economy governed by software applications can take a lesson from the New Horizons mission. Application Programming Interfaces (APIs) are now central to the exchange of value between companies, so it makes complete sense to use them against legacy systems and line of business applications. By securely unlocking the application data (and business processes) through API’s and by seamlessly managing message mediation and translation, organizations can have these older systems quickly participate in more modern processing and customer-centric computing.

Every system is a legacy system

Just as we rush to embrace every shiny new tech object, we can be equally hasty berating the value of existing systems and applications. To this end, legacy becomes a term of derision; associated with everything bad about enterprise computing. The more pragmatic among us know this isn’t so. After all these systems support a plethora of back-end business processes and continue to be the transactional work-horses upon which many businesses depends.

There’s a lot we can learn from the New Horizons mission. Even now scientists are saying that the spacecraft has decade’s worth of exploration left in it. So with some quick course adjustments it’s off to explore the next icy world.

Not bad for old space tech – perhaps in business computing we should be thinking the same way – extracting value before prematurely consigning our own legacies to application scrap-heap.

September 24, 2015