devopsy.kinsta.cloud

Tag: infrastructure

Cisco Looks to Bridge Gap Between Networking and DevOps

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

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

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

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

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

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

— Mike Vizard

June 23, 2017
All Day DevOps: Capital One Gives Credit Where It’s Due

Listening to his talk, it seems as though George Parris and his team at Capital One aren’t keeping “banker’s hours.” George is a Master Software Engineer, Retail Bank DevOps at Capital One. At the All Day DevOps conference, George gave a talk, titled “Meta Infrastructure as Code: How Capital One Automates our Automation Tools with an Immutable Jenkins,” describing how the team automated the DevOps pipeline for its online account opening project for Capital One, a major bank in the United States. Of course, there is a lot to learn from their experience.

George started by pointing out that software development has evolved, coming a long way even in just the last few years. Developers now design, build, test and deploy, and they no longer build out physical infrastructure—they live in the cloud. Waterfall development is rapidly being replaced by Agile, infrastructure as code and DevOps practices.

Where we see these technologies and methodologies implemented, IT operations teams are acting more like developers, designing how we launch our applications. At the same time, development teams are more responsible for uptime, performance and usability. And, Operations and Development work within the same tribe.

George used the Capital One Online Account Opening project to discuss how they automate their automation tools, now a standard practices within their implementation methodology.

For starters, George discussed how Capital One deploys code (hint: they aren’t building new data centers). They are primarily on AWS; they use configuration management systems to install and run their applications; and they “TEST, TEST, TEST, at all levels.” Pervasive throughout the system is immutability; that is, once created, the state of an object cannot change. As an example, if you need new server configurations, you create a new server and test it outside of production first.

They use the continuous integration/continuous delivery model, so anyone working on code can contribute to the repositories that, in turn, initiate testing. Deployments are moved away from the scheduled release pattern. George noted that, because Capital One is a bank, regulations prevent its developers from initiating a production change. They use APIs with the product owners to automatically create tickets, and then product owners accept tickets, making the change in the production code. While this won’t apply to most environments, he brought it up to demonstrate how you can implement continuous delivery within these rules.

Within all of this is the importance of automation. George outlined their four basic principles of automation and the key aspects of each:

Principle #1 – Infrastructure as Code. They use AWS for hosting and everything is in a Cloud Formation Template, which is a way to describe your infrastructure using code. AWS now allows you to use CFTs to pass variable between stacks. Using code, every change can be tested first, and they can easily spin-up environments.

Principle #2 – Configuration as Code. This is also known as configuration management systems (they use Chef and Ansible). There are no central servers, changes are version-controlled, and they use “innersourcing” for changes. For instance, if someone needs a change to a plugin, they can branch, update and create a pull request.

Principle #3 – Immutability. Not allowing changes to servers once deployed prevents “special snowflakes” and regressions. Any changes are made in code and traverse a testing pipeline and code review before being deployed. This avoids what we all have experienced: the server that someone, who is no longer around, set up and tweaked differently than anything else and didn’t document what was done.

Principle #4 – Backup and Restore Strategy. A backup is only as good as your restore strategy. You know the rest.

George also dives into how they do continuous delivery/continuous integration in his talk, which you can watch online here.

If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here. Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed). It’s all free, online Oct. 24.

— Derek E. Weeks

May 31, 2017
Why DevOps Success Depends on the Right Infrastructure

Do you remember building with LEGOs? You could follow the directions that come in the box down to the letter, or you could go off-script to create something totally your own and evolve and refine it over time. Regardless of your level of creativity, if you had one of those classic green base plates to build from, then LEGO cities were in your grasp.

In many ways, a DevOps methodology aligns with the block-building process. While the tools and processes can change, a solid foundation is the backbone for fast and repeatable success. Developers and IT operations are beginning to reap the benefits: According to RightScale’s “2016 State of the Cloud report,” DevOps adoption increased to 74 percent in 2016 from 66 percent in 2015.

But even though adoption is on the rise, some DevOps teams still struggle to extract the full range of benefits from a DevOps model. Why? Because they’re more concerned about the LEGOs without first having considered the base plate. DevOps requires a flexible and modular foundation, a software-defined infrastructure (SDI) built with open-source technologies to be successful. Here’s why.

Infrastructure: The Path to Agile Business

The goal of a DevOps approach is to speed the entire application delivery life cycle (initial development, testing, delivery to market), enabling the business to quickly respond to consumer demands (deliver new services, fix bugs, add new features, etc). However, for the DevOps teams to successfully execute this, they need a flexible and modular cloud infrastructure that easily adapts and extends to meet their needs.

SDI provides easier access to resources via a self-service interface so developers can quickly get the resources they need. It also gives the DevOps team the capability to standardize services so that applications built in the development environment will easily deploy and run in the test and production environments, speeding their delivery to market. SDI also offers a flexible and modular approach that provides timely and easy access to the latest technologies, such as containers, where innovation is occurring at a rapid pace and easy integration is available via standard open protocols.

SDI provides the best LEGO base plate to support your DevOps processes that improve application lifecycle management.

Automation to Support Strategic Collaboration

Routine deployment and management tasks are the Achilles heel of every IT organization. The best way to improve efficiency, reduce costs and quickly respond to infrastructure demands is with automation.

As a key component of an SDI, automation and orchestration of the application life cycle including deployment of hardened VM or container templates ensures faster, consistent and repeatable provisioning and configuration. Additionally, the SDI automation and monitoring tools can intelligently sense and respond to infrastructure demands, automatically optimizing and adapting the infrastructure in real time. This frees time for the team to focus on strategic initiatives versus backend tasks.

The DevOps movement is all about collaboration and constant innovation, which is made possible by having your infrastructure automate the mundane tasks and automatically respond to infrastructure demands.

Visibility Down to the Base Level

One challenge facing successful DevOps adoption today is lack of visibility into application delivery. As developers rely on constant innovation through a loosely coupled chain of events, understanding how each link operates is crucial to keeping the chain moving in the right direction.

In the case of open source, there is no infrastructure more transparent or collaborative. The infrastructure itself is built on openness and exchange of code, leading to a natural transition to its use in a developer environment. As DevOps uses CI/CD to stay refined, so do the open-source projects that contribute to its infrastructure. Constant innovation is what keeps the infrastructure and development tools up to date, supporting the entire DevOps team.

The Solution to Cultural Challenges

Successful DevOps adoption doesn’t solely involve changes to existing technology. It also requires a cultural shift within an organization. A software-defined infrastructure that utilizes open-source technologies is built on the same concept: growth through collaboration. Businesses aren’t committed to using a single vendor or propriety solution, giving them an expanded network of resources and tools to optimize their IT needs and business operations. DevOps is a marriage of technology and people, and an SDI environment allows that union to succeed.

The world has seen many great LEGO projects over the years, both the small-scale private home projects and large-scale public exhibitions. But the common thread for their success is the base plate, allowing innovators everywhere to build LEGO masterpieces more rapidly and effectively. For DevOps professionals, a software-defined infrastructure built using open-source solutions is the base plate for success. SDI environments improve efficiency with automation, refine visibility into application performance, enable innovative and agile business models, and create stronger cultural alignment.

About the Author / Terri Schlosser

Terri Schlosser, head of SUSE product and solution marketing, has 20 years of experience in the IT software industry. She has held roles in marketing, software development, product management and strategy in many different IT software areas including cloud, networking, storage, management and operating systems. Most recently her focus has been on open-source software defined infrastructure solutions. Follow her on Twitter.

May 24, 2017
The Time Is Now for an IT Operations Revolution

There’s a level of frustration starting to build inside IT operations teams that’s about to boil over. Lucas Carlson, vice president of strategy for Automic, a unit of CA Technologies that provides an IT automation platform, says developers are bullying IT operations teams by programmatically invoking application programming interfaces (APIs) exposed by public cloud service providers. As the number of application workloads running in those clouds increases, IT operations professionals are losing control.

To ensure their continued relevance, IT operations teams need to leverage automation to inject levels of agility into local data center environments, he says. That would make it much less likely developers would feel the need to programmatically invoke IT infrastructure resources.

Carlson says achieving that level of agility will require IT operations teams to rely more on machine- and deep-learning algorithms to automate low-level tasks. Instead of thinking in terms of managing silos of compute, storage and networking resources, Carlson contends IT operations professionals need to reinvent themselves.

The artificial intelligence (AI) models based on advanced algorithms must be trained continuously. IT operation professionals could become the trainers of those AI models. In fact, Carlson says IT operations teams are approaching a critical moment in history: They can either wait for AI models to eventually replace them or they can leverage them to take back control of IT infrastructure.

However, developers tend to make decisions based on what they prefer versus what’s best for the organization. Before too long, multiple duplicate operations management frameworks are in place. Rather than incur all those management headaches and associated technical debt, Carlson says organizations need a single framework that can more adroitly accommodate the multiple roles within the DevOps team. It’s already long past the time when IT teams should have modernized their operations, he says.

The relationship between developers and IT operations teams has always been contentious. The more belligerent members of the developer community are even making a case for “NoOps.” In that context, all the IT dollars spent on operations are moved into developing applications because the management of IT infrastructure is completely automated. Given the amount of legacy infrastructure that isn’t likely changing anytime soon, achieving that level of automation inside the enterprise won’t happen for a while. But there’s no doubt that IT operations needs to get more agile. Because of that issue, investment in software-defined data center (SDDC) technologies is growing rapidly.

Instead of resisting that trend, Carlson says teams need to demand that internal IT operations be brought into the 21st century. It’s true that SDDCs infused with AI models will automate most of the lower-level tasks associated with DevOps. But those members of that IT operations teams who become the masters of building and training those AI models will be among the most highly sought-after individuals in IT.

— Mike Vizard

May 22, 2017
DevOps: Trust, Obligations and Promises
Mark Burgess (@markburgess_osl) is a theoretical physicist, but in his keynote at the 2016 All Day DevOps conference, he talked more about economics and human interactives than physics. What does either have to do as the keynote for a conference on DevOps?

Well, for a little more background, Mark Burgess is also the founder and former CTO of CFEngine, a configuration management and automation framework, and is the author of “Promise Theory.” While at CFEngine, Mark worked to apply a theory of how the autonomous agents in software interact with each other. Promise Theory was born.

Exploring Promise Theory

Promise Theory sits counter to obligation theories. Obligation theories view human interactions and behavior under the assumption that people (or agents, in the case of software) choose behavior based on their obligation to follow the rules. Agents are obligated to take a certain action. Promise theory contends the desire to follow the rules is voluntary and that agents can only be responsible for their own behavior, not the behavior of other agents.

In his presentation, Mark started out looking at human behavior and trends in our society. For instance, with technological advances, our need for one another is decreasing, even as our interdependence through communication is increasing. For example, our smartphones enable us to do almost anything without the direct interaction of someone else.

Looking at interactions in society, trust is the basis for our exchanges, working communities, and function as a society. He contends, “The promise is the source of intent by which all promises and observers may calibrate their expectations.” Money is an example of this. Money does not have intrinsic value, but we use it because we trust the backer will stand behind its value and it is more convenient than bartering goods. He explains that in the old monetary economy, banks and governments were the provider of trust; in the new service/IT economy, the service provider is the basis of trust.

How Agents Make Promises

How do you model this trust? Enter Promise Theory, which describes how agents make promises with each other and how this leads to trust between them. Mark outlines the “ingredients” of Promise Theory:
1. Agents and super agents make promises in a scaling hierarchy.
2. An agent can never make a promise about another agent’s behavior (only its own).
3. An agent’s promise need not be accepted or used by its intended or unintended recipient!
4. An agent makes its own valuations: what you have is only worth what another is willing to give you for it.
5. Dependency invalidates promises.
At the core of understanding this, you have to understand that collaboration is made up of semantics, what words mean and dynamics: all how things work. And that our ever-increasing service economy is driving us to an explosion of semantics, because words matter so much more than the mechanics. As an example, Mark sketched the hierarchy of promise dependencies in the old and new economies. Looking at the old economy, where we have more dynamic money, the hierarchy is:

Retail→ Money→ Banks→ Central Banks→ Government.

In the new economy, where we have more semantic services, the hierarchy is:

Client→ Network Availability→ Provider→ Internet Authorities→ Company/Service Organization.

The Need for Cooperation

None of these systems could work without cooperation at the bottom of it all. So, production is a cognitive process between the producer and the consumer, but also between the agents inside those organizations that have to interact. Often we create pipelines to describe these interactions, but the interdependencies within the systems are often much more complex than the pipeline can model.

This is all just the tip of the iceberg. Mark has three books that dive into it in detail: “Thinking in Promises,” “In Search of Certainty,” and, “Promise Theory.”

In the end, Mark made the point that technology does an excellent job of both binding us together and pulling us apart. We need to be careful that we don’t take ourselves out of the systems we create, or we could scale ourselves out of existence.

devopsy.kinsta.cloud Supports the All Day DevOps Conference

If this piqued your interest, you can watch Mark’s full All Day DevOps conference session (just 40 minutes). When you do, you can view the other 56 presentations from the 2016 conference online and free of charge. Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed). It’s free and online on Oct. 24. devopsy.kinsta.cloud is a media sponsor for All Day DevOps 2017.

— Derek E. Weeks
May 19, 2017
Confessions from Fannie Mae, Liberty Mutual and Capital One
Learn from real-world stories from presenters at the All Day DevOps conference …

True Story

Over the past few years, Fannie Mae transformed the way in which it delivered software. Deploys increased from 1,200 per month to 15,000 per month. At the same time, productivity increased by 28 percent while costs were reduced by 30 percent.

But, how did Fannie Mae do it?

During the All Day DevOps conference, more than 13,500 practitioners from around the world came together to learn from their peers in the industry. Barry Snyder, senior manager of DevOps at Fannie Mae, was one of 57 practitioners who shared his real-world journey through his enterprise transformation.

Choke Point or Checkpoint?

Eddie Webb, director of Software Delivery Platforms at Liberty Mutual, also shared his organization’s journey into DevOps. Eddie described how Liberty Mutual evolved its organization, tool chain and processes to go from 20 percent of builds being deployed to 60 percent over the past 18 months. He described how the company documented its value delivery chain and identified all of its choke points in the continuous delivery process that would need to be automated to achieve its new velocity and quality targets.

Run the Gauntlet

The All Day DevOps conference recorded more than 57 practitioner-led sessions (30 minutes each) including those from Barry and Eddie. Every session is now posted online and is free to watch. The conference itself had three tracks: CI/CD, Automated Security and Modern Infrastructure, including:
- Application Secret Management with KMS – Andrey Utis of Capital One
- Getting out of the Job Jungle with Jenkins – Damien Coraboeuf of Clear2Pay
- Serverful Computing – Taking One for the Team – Paul Czarkowski of Blue Box Group
One of the best ways to learn about DevOps is to hear from the experiences of others who have run the gauntlet. Take 30 minutes this morning, at lunch or at home this evening to watch your first online session with All Day DevOps On-Demand.

— Derek E. Weeks
December 14, 2016
Will Blockchain Move Past Hype to Reality?

Blockchain has hit peak “hype,” according to Gartner’s recently published “Hype Cycle for Emerging Technologies.” The financial world has been very optimistic about blockchain or distributed ledger technology (DLT)—the underlying technology behind bitcoin—and the impending disruption it can bring to the way the financial system works.

Although the initial buzz around bitcoin has gradually died down over the last couple of years, DLT has gained a lot of traction in the industry. As a concept, distributed ledger and open network with encrypted data brings vast opportunities for ideation. But will it only be hype? Or will blockchain graduate from the lab environment to the real world? Only time will tell, but the idea of distributed ledger is here to stay.

From Idea to Adoption

Any new technology will go through its hype cycle before settling down with the complex reality of business adoption. Blockchain is most likely going through the cycle at this point in time. It may not be panacea for all the challenges faced by the industry today, but it definitely shows some initial promise of being a game-changer.

We have very rarely seen industry cooperation like this for a new technology. Financial institutions are excited and rightly so. Global financial markets potentially can save as much as $80 billion in operating costs if blockchain becomes a mainstream technology.

The application of blockchain will exceed hype only when it addresses the core issues financial institutions face today: simplification and security. While cost takeout is a great value proposition, I believe that adoption of blockchain as a technology fundamentally should revolve around rationalizing the process value chain and providing robust security. Some of the initial use cases for financial services firms show a lot of promise, from the process simplification and digitization perspective leveraging distributed ledger, but there is still significant ground to cover before it becomes real.

Why Blockchain Isn’t There Yet

There is exciting amount of exploratory traction around blockchain use cases, but the reality is that no financial institution has yet implemented blockchain in production, and I don’t think it’s going to happen anytime soon.

The success of blockchain as a technology hinges on three factors:

Security – Recent lapses in bitcoin exchange and virtual robberies of digital money pose a significant threat to the underlying technology (blockchain itself). In a world where each participant will have his or her own private key, there will be many hurdles to cross in the barriers of data security. How safe will it be? How quickly will it scale up to expose all the vulnerabilities?

Dealing with legacy – Many technologies have matured over the years, yet banks still run on mainframes! How blockchain interoperates with the legacy infrastructure in banks will be the most important aspect to watch out for. Is the idea to build a greenfield environment and re-imagine the financial world more pragmatic?

Trust – Data ownership traditionally has been a source of power. Digital currency and federated data over blockchain will change the very existence of political hierarchies. How will businesses deal with it?

Still, it’s a good bet to have in your long-term portfolio.

Bill Gates once said, “we always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next 10. Don’t let yourself be lulled into inaction.”

Although its foundational blocks are really solid, blockhain’s mainstream adoption in the near future is going to be tough. Hawk-eyed regulators will be picky about security threats and any negative news. But the collaboration on this technology is unprecedented and bodes well for the future, so I’m optimistic blockchain will become a reality at some point in time. Going by the wisdom of Bill Gates, I’m looking at five to seven years.

About the Author / Mohit Sinha

Mohit Sinha is a client partner in the Finance Solutions group at Wipro Digital and currently manages the relationship with a top tier Investment Bank in London. He has over 14 years of experience spanning domain consulting and client relationship management in the Investment Banking and Wealth Management domain. He has been part of successful delivery of transformation initiatives across UK and Europe CIB and PWM, Derivatives Operations, SEPA transformation and CIB/PB Order and Trade Management areas. Connect with him on LinkedIn and Twitter.

November 8, 2016
Infrastructure’s Impact on Shifting Left

If you lead big honkin’ software development projects at a big honkin’ enterprise, you’re probably doing everything you can to shift QA left. That’s because the earlier you discover defects and shortfalls, the faster and less expensively you can bring great software to market.

Unfortunately, above a certain scale, it takes more than just better processes and a more aggressive culture to shift test and QA left. It also requires a different approach to the infrastructure you use to distribute your builds.

Infrastructure and the Problem of Scale

Most software developers understand the scale issue primarily as one of complexity. The bigger the project, the greater the chance that something won’t work with something else exactly as planned.

But large software projects also canget badly impeded by the sheer physics of build distribution.

Take, for example, a 10GB build that you have to distribute to five different domestic and offshore locations from your primary facility over your company’s 10Mbps MPLS connection. If your two of your locations are domestic and have 5Mbps connections, it will take five hours to get them each build. If the other three are offshore and have 2Mbps connections, it will take them each 12.5 hours to get their copies of the build.

That’s a “time tax” you’ll have to pay again and again as you keep having to ship massive files over the network to your globally distributed test/QA team. Worse yet, the more Agile and iterative you get, the more you keep paying this “time tax” over and over.

So hours expand into days, and days into weeks—constantly frustrating even your best efforts to more aggressively shift left.

Avoiding the Scale-Driven Time Tax

Here’s how you can successfully avoid the time tax that chronically prevents you from shifting your biggest projects further left.

Instead of continuing to use IT infrastructure that was never designed to support time-compressed software development at scale, you can instead implement a hub-and-spoke build distribution system that virtually eliminates network-related delays.

This hub-and-spoke model lets you maintain a “gold copy” of your current build(s) in the cloud—while providing all your remote locations with their own local copies that get continuously and automatically updated with any changes as they occur.

This model eliminates network-related bottlenecks while allowing your geographically dispersed teams to collaborate without tripping over each other’s work. As a result, you can shift left much more aggressively.

Of course, infrastructure decisions typically aren’t made by the same folks who lead software development. So the two groups have to collaborate closely to make sure the network doesn’t impede critical development processes.

But both parties have lots to gain—because hub-and-spoke saves infrastructure owners lots of money in storage, bandwidth costs and network acceleration hardware at the same time as it empowers development to shift further left.

That’s why DevOps leaders and enterprise infrastructure owners need to work together ASAP. The digital success of the business depends on it!

— Barry Phillips

October 28, 2016
Reasons Why DevOps May Not Work for You

DevOps is a great way for many organizations to optimize software design and delivery. Yet, like every other technological innovation in history, DevOps is not perfect. Here are some examples of drawbacks associated with DevOps.

By no means do I think DevOps is a bad idea in general. I want to be very clear about that.

However, organizations considering making the move to DevOps—and those that are already doin’ DevOps, as we say here on devopsy.kinsta.cloud—can gain useful perspective by recognizing the difficulties that DevOps can present. Those include …

Narrower Team Member Roles

Traditionally, software engineers were expected to bring “full-stack” skills to the table. That meant they should understand the ins and outs of all layers of an application stack.

Under the DevOps model, each member of the software delivery team has a more rigidly defined role. Coders code, QA engineers test, IT Ops admins administer and so on. These people all talk to each other, but they do not share in the same tasks.

In many cases, this approach is better because it allows each professional to focus on what he or she does best. But this can be a drawback for full-stack developers. Their broad skill sets are no longer valuable. This is why people such as Jeff Knupp complain that DevOps is “killing” developers.

There’s a potential downside here for organizations, too. Under DevOps, they have to hire and manage more personnel to make sure there is a specialist who can cover each stage of the software delivery pipeline, rather than investing in a smaller number of full-stack developers.

Software Feature Bloat

One of the key advantages of DevOps is that it promotes continuous software delivery. That means new features can be rolled out faster.

But the ability to add features more easily also raises the risk that software delivery teams will add functionality to software just because they can, not because it’s needed. More features are not always better, even if they can be implemented efficiently.

Infrastructure Changes

To make the most of DevOps, most organizations will have to upgrade at least part of their infrastructure to optimize software delivery. Many will need to migrate apps running on virtual servers to containers, for example.

There is nothing inherently wrong with such infrastructure upgrades. But they are potentially expensive and complicated endeavors, and if you don’t complete them properly, you might not actually get very much out of the other DevOps processes that you implement. Organizations considering DevOps should keep this in mind.

Half-Baked DevOps

The final major risk of a DevOps migration is not actually a downside of DevOps, per se. It’s a risk that results from the chance that organizations will implement DevOps imperfectly.

This can be easy to do, because organizations can mistakenly believe that doing DevOps means simply running a continuous integration (CI) server or changing job titles. In practice, DevOps also requires significant cultural changes and new methods of communication. If you implement a half-baked DevOps environment that includes the tools but not the culture, you’ll likely be worse off than you would without having attempted DevOps at all.

Conclusion

Again, I want to be clear that there are lots of good reasons to do DevOps. I’m not trying to go on record as the guy who hates DevOps, because I absolutely don’t. Almost all organizations have much more to gain than to lose by adopting DevOps, if they have not already.

Still, being aware of the imperfections and risks associated with DevOps is important. DevOps is not a magic pill that will solve all of your software delivery problems with no side effects. If you want to avoid mistakes or unrealistic expectations when doing DevOps, you need to appreciate the drawbacks you may face.

— Chris Tozzi

October 4, 2016
Mainstreaming the Mainframe: DevOps, Automation, Unified Deployment

The mainframe is alive and well. That big metal beast in the data center is not going anywhere anytime soon—nor are its applications.

“If mainframe applications disappeared tomorrow, planes couldn’t fly, people wouldn’t get paid, and the economy would come to a halt,” wrote Forrester analysts in a recent report, “Digital Transformation Needs Mainframe DevOps.”

I couldn’t agree more.

Mainframe systems are the brain of most enterprises. Unfortunately, many mainframe applications have failed to keep pace with technology innovations, forcing enterprises to update them at any cost.

Those “dinosaur” apps need to be modernized so they can become part of the mainstream IT ecosystem that revolves around the web, the cloud, and everything mobile. To make that leap into the modern software world, mainframe apps need to be re-engineered to fit into what is increasingly a cross-platform, predominantly digital world.

Digital enterprises need to apply the same continuous delivery management practices to mainframe environments that they use for their distributed, web and cloud platforms.

Scripting is Not the Solution

Complex, multi-tier enterprise applications often include back-end mainframe applications and data. Upgrades and enhancements of these applications, therefore, require modifications of application code, data interfaces and other components across multiple platforms simultaneously.

Scripts are virtually impossible to audit and typically depend on the knowledge of the individuals who write them. Furthermore, scripts lack the end-to-end process visibility and auditability vital to the success of continuous delivery.

The Need to Re-Engineer Mainframe Apps

DevOps, which mostly revolves around adopting or improving automation, increasingly is being embraced by enterprises. Having initially chosen DevOps for pilot projects, departmental needs and individual applications, big companies now are taking a broader perspective of DevOps—focusing on their needs to drag their mainframe applications into the modern world.

Most enterprises that embark on transforming their legacy applications realize it is smarter, easier and more cost-effective to build a bridge with modern engineering than to start from scratch. Typically, these companies deploy DevOps principles because research and analysis prove they accelerate the delivery of top-quality software. At the same time, they realize their existing investments in their mainframe applications cannot be thrown away or ignored.

Applying DevOps principles to the mainframe application delivery pipeline can help enterprises cut risk, cost and complexity, while improving their responsiveness to ever-changing customer needs.

Unified deployment means that enterprises might need to work with two or three leading vendors to achieve their vision of automated, cross-platform DevOps. Such a vision typically involves unifying COBOL applications, DB2 databases, z/OS processing power and other mainframe assets into a single, shared pool of enterprise digital resources that IT can adapt wherever and whenever they are required by the business, without operational or staffing impediments.

The Need for a Unifying Software Delivery Infrastructure

In enterprises, it is common to have a broad mix of back-end systems, middleware and various platforms from a vast array of vendors. These technologies might be managed by distributed teams and potentially in different parts of the world as well. When it comes to the process of creating and delivering software, the same level of distribution and diversity also is common.

To connect these islands of technology and expertise, enterprises need a unifying technology that sits on top of everything else, connects to everything, and helps to orchestrate, automate and provide visibility into the process of creating and delivering software. Improving traceability, auditability, security and risk compliance through orchestration and automation of the entire stack of applications is critical to any organization.

What that means in practice is that people with different skills in different parts of the world can collaborate easily without having to learn new skills. For example, if you know all about the mainframe but know nothing about middleware or distributed systems, that’s no problem. You can still contribute to the process through a unified pipeline.

In the same vein of thinking, a unifying technology should reduce, if not eliminate, the gap between highly technical and non-technical contributors. That means the unifying technology should provide a solution where people don’t have to write (or even understand) code to make core changes to software.

In Summary

Modernizing the way organizations deploy applications to the mainframe is crucial to their success and very survival. Organizations need to embrace change at all levels of their IT infrastructure and begin automating their processes today. By applying DevOps processes and tools to their mainframes, these organizations will help their “dinosaur” applications evolve and survive under the pressures of modern software delivery processes and deadlines.

About the Author / Sunil Mavadia

Sunil Mavadia is director of Customer Success for XebiaLabs, provider of software for continuous delivery and DevOps. A former customer, he was the head of major DevOps transition projects with his previous company. Sunil runs Client Services, including consulting and implementation of the XebiaLabs product suite: XL Release, XL Deploy and XL TestView.

September 16, 2016