devopsy.kinsta.cloud

Category: Enterprise DevOps

Open Mainframe Project Launches Zowe to Advance DevOps

The Open Mainframe Project has launched Zowe, an effort to make mainframes running z/OS both more accessible and programmable using REST application programming interfaces (APIs).

Announced at the Open Source Summit, the Zowe project is being led by IBM, CA Technologies and Rocket Software.

Matt Hogstrom, chief architect for z/OS Systems at IBM, said the goal of the Zowe project is to attract a new generation of IT administrators to the mainframe platforms and make it simpler to include mainframes within the larger scope of an integrated set of DevOps process spanning multiple platforms.

In addition, IBM, CA Technologies and Rocket Software collectively are trying to create an ecosystem around the mainframe that resembles more of the types of interactions that occur between companies that participate in the Linux community, Hogstrom said. The Open Mainframe Project operates under the auspices of the Linux Foundation.

Now that IBM mainframes are more than 50 years old, IBM and its allies are increasingly relying on open source tools to make sure mainframes stay relevant for another 50 years, he said.

To achieve that goal, Zowe provides access to an extensible z/OS framework that provides new APIs and z/OS REST services. The Open Mainframe Project, as part of Zowe, has also created a unifying workspace based on a desktop app container accessed via a browser and a scriptable command line interface (CLI) that makes it easier to integrate z/OS into cloud and distributed environments using a set of low-code tools.

Greg Lotko, General Manager for Mainframe at CA Technologies, said the contributions to the Zowe Project made by CA Technologies are based on CA Brightside, a set of DevOps tools developed specifically for mainframe environments.

The biggest challenge the mainframe community now faces is a dwindling pool of talent. Most college graduates today have limited exposure to mainframes at a time when many of the IT professionals who do have mainframe skills are retiring. In the absence of skills to manage mainframes, IT organizations wind up making decisions regarding where to put workloads based on the availability of expertise available to run those platforms. IBM, CA Technologies and Rocket Software all have a vested interest in leveraging DevOps tools and processes to eliminate the silo that currently exists between mainframes and other platforms by making it easier to call services residing on a mainframe using REST APIs, while at the same time making it easier to manage mainframes within the context of a common set of DevOps processes spanning multiple platforms.

Mainframes, of course, are still comparatively expensive platforms to acquire. IBM has sharply reduced the cost of mainframes over the years. But the primary economic value proposition of mainframes is that the total cost of operating a mainframe is less than a distributing computing environment running a comparable set of workloads. Mainframes are highly automated, so IT organizations that can afford the cost of entry tend to still favor mainframes for complex transaction processing and analytics applications. The challenge—and opportunity—for mainframe shops now is in turning those applications into a set of reusable services that can be readily invoked from anywhere in the enterprise.

— Mike Vizard

September 5, 2018
A Right DevOps Approach: Assess Organizational Readiness
Driving business in this fast-paced world is maddening as owners have to remember customer preferences, beat market competition and similarly cater to different things within the organization’s radius.

How a business owner manages all this defines the business success, which is gauged through outcomes in the form of smart products, point-on services and almost-immediate feedback. Bank applications, the best smartphones and interactive technology are all proof of this.

But what is it that stands at the heart of it all?

The Right DevOps Approach

When enough is done and businesses still find that there’s a missing piece that will complete “the successful business picture,” they go back to figuring out what and how they can fix the problem. They never come to realize that they will have to consider revamping their organizational structure to meet the growing demands of their influential business.

How, then, do you assess your approach to DevOps?

While most believe that it’s a technological approach that they should incorporate in their business, it’s more of a cultural approach. To implement DevOps into your existing organizational structure, you first must look at its current state of readiness.

Doing this is important, as it helps decision-makers understand how they can embed the smart collaboration after a thorough consideration of the challenges that stand in the way of DevOps implementation. Once the initial assessment is done, business owners need to ask themselves three questions before assessing DevOps readiness:
1. Is there a Management-Employee Agreement? A successful DevOps process not only relies on collaboration between Development and Operations, but also needs a top-down (management-employee) agreement. Once that’s in place, the company is already halfway through the success road.
2. Is there a Plan in Place? Many firms just barge into technology like it’s all they need to reach their finish line. Stop! Wait! Think! Owners need to have a detailed strategy, equipped with process tools and goals clearly outlined and best practices chalked out. Once this is done, the culturally different teams need to collaborate and work ways to learn and equip themselves with the technologies and practices of each other’s processes. With all this in place, organizations will be ready to take the DevOps jump.
3. Is the Organization Ready to Tread the Ocean? Now that the plan is in place, what’s next? Organizations, as mentioned earlier, are in hot pursuit to experiment with what they’ve learnt new. Anything new is fancy, but humbleness is the key! Starting small will set the new cultural shift to completely settle in its new mold. To run the boat in big waters, you first need to test it in small water. Similarly, to test the success of DevOps for a big business project, you first want to test its adaptability to a smaller one. Once you’ve cut off from the harbor, you are all set to wade the ocean.
Conclusion

Most business players underestimate the ability of DevOps with whatever industry rumors they hear and some of their own pre-conceived notions. Some other think that they know it all, but what matters is having a strategic approach to first considering DevOps and its tools, and then adapting it accordingly.

Once the DevOps automation is in place, organizations will be busy reaping the benefits of its successful implementation.

— Veritis
August 7, 2018
Can You Implement DevOps in Large Organizations?

Trying to modernize workflows through DevOps can be a challenge for any company, but there are different challenges, risks and benefits for bigger companies

It is now more or less standard procedure to implement DevOps principles in startups or smaller companies. But what if you’re trying to utilize DevOps in large organizations? This is a bit more challenging, but let’s take a look at how such enterprises might approach a DevOps transformation through a few of the core tenants of DevOps.

Rapid Feedback

There are different types of feedback that come with DevOps: automated feedback about specific code (typically through unit and integration testing software), personal feedback from other team members, consumer feedback from customers using your product and cross-team feedback throughout the organization. Startups and small companies may find it easier to have open lines of communication between individual team members as well as across teams.

Large organizations will need to make a conscious effort to keep team communication open. On the other hand, they will have more resources available (both money and employees) to field customer and in-house feedback about individual services or larger products. They may also be able to better purchase and implement automated testing and CI/CD tools, which leads to …

Automation

One of the biggest tech benefits to a DevOps approach is automating away the manual tasks that bog down critical projects. Large organizations often have the time, money and people to set up automated tools, such as CI/CD pipelines, unit and integration test suites and config management systems. The biggest challenge in the enterprise world is trying to make everyone happy.

One approach is to standardize on a single tool for each purpose, such as Jenkins or Chef. This can enable your IT staff to specialize in those tools but may make some users unhappy with being forced into a tool they may not prefer. The alternative is to allow each team or business unit to use their own preferred software, but this can turn into a “toolset hell” with a mashup of every combination of applications within your organization. Each approach has its pros and cons, and often comes down to a management decision.

Eliminating Silos

Having individual teams that handle their part of the puzzle and nothing else is the biggest hurdle that enterprises face when trying to apply DevOps principles. The combination of “dev” and “ops” (and other disciplines, such as “sec” and “fin”) is naturally split out in a large organization, so recombining them can be a huge undertaking. Then again, that gap is exactly the problem the DevOps approach seeks to solve.

Some companies solve this by having a separate team that handles the cross-team support and communication. Other companies break down these silos by enabling employees to migrate seamlessly between teams depending on the project or application. The more “DevOpsy” method is to utilize ChatOps and centralized documentation repositories for open communication and collaboration, which can help break down unify the distinct teams.

Holistic Thinking

The idea of holistic thinking tends to come easier to larger organizations, as successful enterprises typically have a system in place for “big picture” thinking, either through a management or product team, or through a cross-functional committee. That said, communication of this vision down to the employees, along with communication up to that management team, is crucial for enabling outside-the-box thinking to get past any roadblocks and hurdles that are in the way of creating and deploying the end product. Sometimes, the hardest part is convincing programmers that not everything needs to be solved with code!

DevOps in Large Organizations: Challenging but Rewarding

Some folks think that DevOps only applies to startups and small companies, but we’re seeing more and more teams benefit from implementing DevOps in large organizations. The benefits of the above DevOps principles are numerous, but frequently come with a different set of challenges based on your organizational size. Once you are aware of those challenges and have a plan to overcome them, you can start to transform your enterprise to a DevOps shop.

— Jay Chapel

August 1, 2018
Compuware Adds Testing Tools to DevOps for Mainframe Portfolio

Compuware is extending its ongoing campaign to bring DevOps processes to the mainframe by acquiring XaTester, a provider of tools for creating unit tests for both batch and CICS-based programs written in COBOL, PL/I and Assembler.

In addition, Compuware announced it has formed an alliance with Parasoft, a provider of tools for testing application programming interface (API) calls between mainframe and non-mainframe systems.

Finally, Compuware revealed it has added support for automated unit testing for the IBM Management System (IMS), a hierarchical database that is used to run both transaction and batch-oriented applications.

Those latest editions come on the heels of an update to the Topaz for Total Test platform that, among other things, make it easier to extract data from mainframe applications.

Compuware CEO Chris O’Malley said all these new capabilities will expand the reach and scope of Topaz for Total Test platform that makes it possible to apply DevOps practices to both new and legacy applications being developed and deployed on IBM mainframe platforms.

Despite being more than five decades old, O’Malley noted that mainframes are still widely employed to process both transaction and batch-oriented applications at a level of scale other platforms still can’t match. The challenge now is to integrate the wealth of applications running on IBM mainframes within the context of a modern application development process, he said. That requires putting new application development and deployment tools in place that are optimized for DevOps versus traditional waterfall approaches still widely used in mainframe environments.

CICS and IMS applications are at the heart of some of the fastest transaction processing applications running in the enterprise. Rather than rewrite those applications, O’Malley said organizations that have invested in mainframes want to be able to expose those applications as a service using APIs. Testing those integrations requires mainframe teams to adopt frameworks that enable them to become more agile, he noted—for example, organizations integrating applications need to be able to easily engage in A/B testing to be able optimize performance.

As the lines between mainframes and distributed computing systems continues to blur, most organizations are working toward having one team support both platforms. As part of that effort organizations are introducing DevOps practices that have proven themselves on distributed computing platforms to mainframes. That approach helps mitigate a mainframe skills shortage that is occurring as more IT professionals with mainframe skills leave the workforce.

It may take a little extra effort to get IT staffs managing mainframes to part ways with legacy approaches to building and deploying applications that have clearly stood the test of time. But as more organizations embrace digital process transformation the rate of change in mainframe environments clearly need to accelerate, O’Malley said.

In fact, IT professionals with mainframe skills that are also literate when it comes to DevOps just might find themselves among the most sought-after people in enterprise IT. After all, the number of IT professionals that can play both side of the mainframe and distributed systems ball are very few indeed.

— Mike Vizard

July 25, 2018
Ops: The Other DevOps

Much of the conversation around DevOps, including right here on devopsy.kinsta.cloud, is about helping developers get easier access to production systems, increasing agility by shortening release cycles. Most of the time, this focus on developers leads to a concentration on so-called “Day One” tasks, the Dev side of the equation, to the exclusion of “Day Two” operations—the Ops side of things.

Photo via Damien Kuhn – https://unsplash.com/@producteurslocaux

Recent moves in the DevOps market underscore the fact that the weight is still very much on the Dev side, and not so much on Ops. Microsoft buying GitHub is huge news, don’t get me wrong, not least because many people are still stuck in a very Nineties conception of Microsoft, and this acquisition should help clarify that this is not your parents’ Microsoft (full disclosure: my employer, Moogsoft, has a strategic partnership with Microsoft). News on the Ops side of the house, meanwhile, rarely achieves the same prominence.

The reason for this imbalance is to be found in DevOps’ origin myth. The story is all about developer frustration with risk-averse operations procedures which prevented them from deploying as rapidly and frequently as they would have liked to. As with most good stories, there is a kernel of truth here, but the truth is more complicated. Ops people are risk-averse for good reason: When they mess up, they don’t have a safety net, and they get a lot of very public blame.

That said, it is certainly true that a reasonable aversion to risk can be taken too far. Couple that with a very human tendency to define oneself by one’s job, and you wind up with people putting hands to keyboards for even basic, routine tasks, becoming bottlenecks for huge processes.

What Does DevOps Mean To Ops?

The biggest benefit of DevOps from an Ops perspective is that it has forced that hard conversation about moving from artisanal, handcrafted IT infrastructure, to industrial and scalable models that don’t require a human in the loop for routine operation. This cultural shift began with the famous pets-versus-cattle analogy, but the transition is far from being complete.

A big sign that there is still work to be done is the relative lack of sophistication around tooling in IT Operations. There is a lot of talk about software-defined infrastructure and desired-state automation, but relatively little practical uptake, especially when it comes to operating such frameworks day-to-day. These new models will require a wrenching transition from traditional Ops models, with pervasive automation working to augment human sysadmins’ capabilities.

This is not the old style of automation, with cron jobs and shell scripts, which any BOfH worth their etherkiller has been doing for decades. The new serverless frameworks do away with the last vestiges of persistent coupling of infrastructure components to individual business services. What vMotion promised in 2003 is now coming to pass, with workloads moving, growing and shrinking to support changes in user demand, and infrastructure reconfiguring itself top to bottom in response.

Key Questions To Ask About Operational Automation

In this context, operational automation can no longer work on the old model of “set it and forget it.” Every process set in motion needs real-time contextual awareness of what is going on around it and how that is constantly changing. Without that visibility, backup scripts may go on faithfully backing up what used to be a high-priority server, but is now a backwater of the application infrastructure. Meanwhile, the cloud services where the bulk of the application’s logic runs are not meaningfully integrated into the disaster recovery (DR) plan.

All of these facets need to be reviewed regularly, in terms of need, function and ownership.

Who Needs This Automation?

Anything that runs should be linked to some kind of business requirement, however indirectly. “This ensures that our infrastructure can scale and flex seamlessly in response to user demand”: Good. “This keeps our operating systems patched”: A valid goal, but do we need to do it in production if the average lifetime of provisioned operating systems is shorter than the patch cycle? Just patch the templates and you’re done. “We’ve always done it this way, and I’m not sure what might happen if we stop”: Time to set some chaos monkeys loose, and see what happens.

What is the Function of This Automation?

We are in the middle of huge technological transitions, and the waves of innovation keep coming closer and closer together. As an industry, we had just about come to terms with virtualization by the time cloud computing came along, but that was far from settled when containerization got underway, and it looks like that may be undermined by serverless architectures before it even comes to its full fruition. Watch out for hidden assumptions in terms of the way you go about a task, and check back in regularly. Ops types should take a leaf from Dev’s book, and regularly consider refactoring their automation to remove cruft and take advantage of new developments.

Who is the Owner of This Automation?

Someone has to own every piece of automation, so that they can maintain it over time according to the previous two points, and so that everyone else knows who to call if (or realistically, when) it breaks. Again, developers have been talking about technical debt for a long time: the impact of older, unmaintained code. Meanwhile, sysadmins used to pride themselves on the uptime of individual servers. That attachment needs to move from the individual server to the overall infrastructure and the automation and management that develop over time to ensure its availability and performance. They’re cattle, not pets, remember?

Ops is the Other DevOps

As Ops becomes more and more about managing the automation, the distinction between Dev and Ops starts to blur. With Dev roles “picking up the pager” and taking responsibility for production operation of their software, Ops roles develop more and more code to fulfill the promises of those applications. With traditional Ops tasks evolving or even disappearing, new roles will appear. The job of automation architect will become much more relevant than any job that requires someone to ssh into an individual server or router. In this transition, old-school Ops people can learn a lot from what our Dev colleagues have been up to over the last few years.

One day, the term DevOps will no longer describe developers and non-developers, but two different types of developer, one focused on business logic and one on architectural underpinnings.

— Dominic Wellington

July 10, 2018
Living in a DevOps World, Part 2

Part one of this article focused on some of the more behind-the-scenes benefits of an Agile DevOps approach. In part two the focus turns to some of the other traditional problems that a well-executed DevOps approach can address, and how doing so can benefit an organization in more ways than just a technical perspective.

By way of quick review, DevOps was born out of the Lean and Agile software development methodologies when it became clear that, while those methodologies did indeed speed up the development process, a bottleneck still occurred when push came to shove and new code had to be moved to quality assurance and production environments.

DevOps was created to more seamlessly connect the development and operations processes, making code migration, testing and promotion to production a more efficient process. To accomplish this, the DevOps approach had to find solutions for some of the issues that caused operational delays, and create new ways to organize, implement and continuously optimize the operations process.

Overproduction/Overprocessing

For those who have been in development and/or operations for any length of time, it quickly becomes clear that there is a multitude of operational safety checks that serve to protect a production environment. While that is vitally important, it was also clear that there had grown an “over” problem around many operational procedures, and in many cases that manifested itself in the development process. That includes overproduction, when making or requesting more than was needed from requirements and/or operations perspective to clear arbitrary operations process hurdles.

Alternatively, overprocessing, when development and operations resources do more work (as opposed to just enough, as Lean and Agile would suggest) than required to smooth the transition of code and functions from development to operations. This created waste regarding time, resources and budgets that were not proportional to the benefits derived from following the operations process.

Motion and Transportation

Similarly, DevOps also sought to solve the operational problems of both motion and transportation. That is, the amount of excess work required to deliver new code to meet the operational requirements for code migration. The friction caused by such requirements slowed the motion and momentum of the development process. The same is true of transportation, or the difficulty in moving code between environments such as testing, quality assurance and production.

In both cases, development and project momentum was sacrificed for what often turned out to be a series of artificial hurdles that had long since become less effective or even obsolete parts of the operations process.

Correction and Inventory

In most instances, all of the above resulted in the final maladies of the pre-DevOps development and operational ways. The first was the number of in-flight corrections required when timelines were squeezed, and the rush was on to get to production. Unfortunately, this went hand in hand with the ultimate problem of good code being sacrificed for expedient delivery, often resulting in inadequate functionality, system outages and, in the end, lost market opportunity and revenue.

3 Keys to DevOps Success

Any successful DevOps implementation must address three critical factors in this order: culture, organization and tools.

Culture

It’s critically important to connect an organization’s values to the DevOps process. Valuing quality, timeliness and organizational alignment of goals and objectives is the first step toward DevOps success. Such cultural values translate directly into a DevOps organization.

Providing empowerment and accountability to DevOps team members helps to build ownership among the team, and trust from their customers in the rest of the organization. It also helps to provide a physical environment that fosters collaboration, teamwork and continued learning. Co-working spaces and collaboration tools such as Slack are a good start. Attending external conferences to broaden perspectives and to bring new ideas back to the team is often beneficial. From there, brown bag lunch sessions where ideas and experiences can be shared, frequent post-mortems on implementations to hone best practices, and even internal mini-conferences where several departments come together for a day to discuss DevOps practices are all effective ways to build a strong DevOps culture.

Organization

Any good DevOps organization is two-sided; that is it has to work from the top down and from the bottom up at the same time.

The top-down part is in the ability to “see the system” from a macro level, allowing for process understanding and insights from a business workflow perspective. This helps to identify the pain points and bottlenecks in the current process that can be optimized through the DevOps process.

Once that’s accomplished, the bottom-up work begins. Identifying things such as inconsistencies in code deployment environments that cause delivery issues, elimination of manual and custom built deployment processes and quarantining inefficient and poorly written code until it can be redone or eliminated are all part of optimizing the time, quality, resources and success factors for deploying production systems on schedule. It’s also important here to continually audit the current processes with an eye toward eliminating the processes that are no longer required or useful but have been kept in place out of the fear of “breaking something we don’t understand.” If nobody understands it, then it shouldn’t be in production software.

Automation Tools

The final factor for DevOps success is to have the right toolset.

Communication: Any DevOps team requires the ability to quickly and directly communicate with other team members sans meetings. For this purpose, tools such Slack (real-time chat), Skype (video chat), and Confluence (for storing persistent information) are pretty good options.

Planning, Monitoring & Consistency: For the team’s planning needs, a tool such as Trello that can provide Kanban board functionality is worth a look. For issue tracking and monitoring of any system’s overall health, tools such as Jira and NewRelic respectively provide some good functionality. Likewise, consistency is vital in a DevOps world, and using automation to ensure that all systems are configured as desired across different environments is a crucial best practice. For this, a tool such as Ansible is worth a review.

Integration & Deployment: For continuous integration of systems in development and as a way to tighten the feedback loop for developers to determine if the central build used for deployment to production is working as intended, the Jenkins toolset might be a good fit. And finally, when it comes making any deployment process as painless as possible, a tool such as Docker that can handle created containers for an application that includes all dependencies, reducing the complexity of deployment to multiple environments, is a solid way to go.

The point of all of this is to create an environment—culturally, technically and physically—where DevOps can succeed, grow and thrive. Organizations that can create an effective and efficient DevOps environment have also created a competitive advantage for themselves.

— Dave Farinelli

July 3, 2018
Portability Shmortability: Most Applications are Going Nowhere

I’m a huge fan of the idea of taking our super-duper applications and deploying them where it makes most sense. I always have been. Those of us in application development spent forever bemoaning the fact that our applications weren’t all that portable between operating systems. In fact, looking back through the history of computers, you find there has always been one roadblock or another to stop portability.

First there was byte order and instruction set, and we’ve largely overcome those. Internationalization wreaked havoc on us all for a while, and we overcame that. We’re still pretty mightily struggling with OS-dependent things such as windowing systems, but browser-based apps have largely overcome those also. Java takes a lot of heat for a lot of reasons, but it did improve portability of apps written in it. Maybe not “Write once, run anywhere,” as was often claimed—things such as file locations were still OS-specific—but still a lot closer than compilers that were deeply tied to the operating system they ran on. Virtualization and containers have enhanced portability in another dimension, letting the developer take the OS with the app.

We have overcome a ton of issues, and advancing technology has introduced a ton more. Now we have to either choose mobile targets or find a tool we like that can generate code for wildly different mobile systems from a single source. DevOps really isn’t helping with this process—though it will, eventually. By automating the build process, the target will be switchable at the targeting end, meaning our app—given a tool that can multi-target—can be built for whatever mobile platform the cool kids are playing with today, and the ones that are considered “cost of entry” can be generated in the same run.

So far, so good, right? We find problems, we overcome problems, DevOps helps us overcome them faster with a wider selection of outputs …

And then we hit the data.

Vendors in a variety of spaces would love to paint you a picture where it doesn’t matter. It does. The mass of your data, wherever it resides, is a pull like gravity to new application development. And it should be.

Some will try to explain to you that in the age of APIs, it doesn’t matter where the data actually resides: You can get it.

But it really does matter, and this is not Utopia. Even if you ignore the performance implications of data being latency-infested miles away from applications that need to use it non-stop, those APIs are only a viable option if the data can be secured and protected. By definition, an API is an advertisement that whatever data/service it fronts can be found right here. For applications that traditionally are data center apps, it might be possible to expose your customer file or other critical data via API and then lock down access to the API by IP …

But then we quit ignoring the latency problem. If every bit of data an app needs has to flow from San Francisco (or Tokyo, or Bejing, or London, or wherever) to Seattle before the calling app can do what it needs to and then has to be sent off again to Albuquerque (or Rostov, or Madrid, or wherever) the delays will, by definition, be more than they would be if the app sat with the data and had to transfer over a 1GB (or 10GB) connection between servers before sending it to users.

This means most data-heavy apps, no matter the level of agile or DevOps, aren’t likely to move. Vendors with a stake in the process will trot out the one or two customers they convinced to make such a move to tell you how great it is, but performance math and security sense tell you it is only great until things get busy or that exposed API is used by bad actors to vacuum user data.

Some applications have smaller datasets and can move the data with the app. Other applications can be architected not to care where the data is. A few don’t need a database at all. Move these applications to whatever platform makes sense. Make the CD for them retargetable. Most serious business applications rely too much on core data to fall into these categories. And thus, they aren’t moving, unless someone comes up with a viable way to move a ton of data between platforms that is safe and fast and effectively translates where necessary.

So, that’s what we need to see next in the march of portability. We currently have containers that can be run pretty much anywhere and languages that will work on pretty much any platform. We need data tools that can alleviate the current set of non-portability/latency constraints and get data where it is needed, when it is needed, securely.

Unfortunately, I don’t see that happening soon. So addressing the issue, “Where do we target our new application?” will have to start with the question, “Where is the bulk of the data it needs?” At least for now.

Most of you knew that, because you’re living it. I just thought you might have a use for a third-party article about it. Because someday, you will have this conversation with someone who isn’t living it. Enjoy.

— Don Macvittie

June 29, 2018
DOES UK: Nike Applies ‘Just Do It’ Attitude to DevOps
Nike’s DevOps transformation has had a lasting impact on its culture and productivity, while allowing the company to connect with its customer in ways it never could before. Its journey down the path to DevOps was shared at the DevOps Enterprise Summit (DOES UK) 2018, in London.

For a company of its size and success in the current market to take a giant leap of faith and come out even more successful takes incredible courage, hard work and collaboration. But that’s Nike for you: Shoes, apparel or DevOps—it doesn’t make a difference to the company. From day 1, Nike has lived its mantra, “Just Do It!”

Imagine this: You’re a high-level IT employee at a non-technology-focused company with a market value of just over $110 billion. All of a sudden, the newly appointed CEO makes the most significant announcement in recent history of the company, essentially saying, “We are entering a new era of growth and we expect to use technology as our main way of getting closer to the customer.” Pretty crazy, huh?

This was reality for Randy Lyons, a longtime employee at Nike with an extremely strong taste for competition and the opportunity of a lifetime in his hands. Based in the EMEA region, Lyons teamed with global Nike CFO Michelle Power with one goal in mind: to bring customers closer to the products, available at any of their 7,000 branded stores globally, through a digital platform. The aim was to tap into consumers’ need to check our phones before making a purchase. The scale was momentous; arguably, larger than any other company achieving a successful DevOps or Agile transformation before. To pull this off on the scale CEO Mark Parker had intended, a complete culture shift was necessary.

Luckily, the unlikely team shared the motto, “Culture eats strategy for breakfast,” and they were eager for the challenge. To start, they needed to change the self-identity of the IT branch. For too long had the underutilized IT staff heard the narrative that “technology helps the business succeed,” rather than existing as a part of the business. Lyons and Power placed a heavy emphasis on the new role of cross-functional IT teams as an integral part of the company rather than a useful helper. They adopted the hashtag “#OneTeam,” which promoted interaction and alignment of the tech team with all other teams, and showed everyone working for them that they were fully invested and energized in positively changing the culture and structural hierarchy of Nike. Additionally, they sought to point out the impact each person’s work was playing through the lens of the overall strategy. The “How is what I’m working on going to effect the direction of this company?” question versus “What else do you need me to do?” was a significant change—it boosted the overall motivation of the teams to work together and even raised individual production significantly.

However, the transformation was only beginning. Early on Power and Lyons discovered a fundamental flaw in the company they sought to transform: Their employees didn’t feel rewarded for their work. While it might be easy for some companies to blow off this issue in favor of dealing with “bigger” issues, they wanted to promote a company culture that would foster growth and speed, which would not—or could not—happen unless their teams felt beyond satisfied with their workplace environment. So, instead of the annual award ceremony Nike regularly used to reward and congratulate its employees, Lyons and Power decided to implement a simple change they felt would satisfy everyone: They added 15 minutes to the end of their weekly Friday staff meeting to give shout-outs everyone who had performed above expectations on a project. It was awkward at first, Lyons admitted. He also described it as “quite American” (ha ha)! However, this simple idea created a complete culture shift. Suddenly, the tech team was being praised by the supply team, while the supply team was being praised by the sales team, and the sales team was being praised by the tech team. This weekly validation of a job well done turned into more jobs well done!

Ultimately, the agile teams were motivated enough and aligned in such an efficient way that they were able to produce five separate software systems fully integrated into a single one-member profile:
1. com (full selection of products sold in store)
2. Nike app (for a more personalized experience)
3. Sneakers (collection of shoes sold in store)
4. NRC (for running products)
5. NTC (for training products)
These software products were incredibly effective in creating an emotional attachment with the brand and the products. Finally, the goal of getting the customer closer to the product through a digital interface had been achieved. The process to get there wasn’t easy. There were many problems to overcome and many things that changed drastically to allow for a newer and more efficient way of doing things. However, Lyons noted this transformation was the most influential on a personal level for him: Before undertaking this project, he didn’t feel as though he could effectively serve as both a team leader and participant. He could easily take orders and sometimes give them out, but it wasn’t until he partnered with Power that he learned to become a not just a team player, but the best player on his team.

The DevOps journey was a transformational process for both the company and the people involved. Today, “Just Do It” means exponentially more to Nike than just a slogan—it’s a way of adding value and efficiency to business.

This was just one of many of great presentations at this years DevOps Enterprise Summit UK this past week. We will be highlighting others in the days ahead.

— Landon Shimel
June 26, 2018
DevOps: The Things We Must Stop

Anytime there is a popular movement in technology (and I would argue any other field), people get carried away. We’ve seen it over and over, and DevOps attracts this kind of attention. In fact, DevOps caters to those who get carried away by mainstream folks screaming, “THIS CHANGES EVERYTHING!” That type of hyperbole pushes those who get carried away even further. And marketing always takes things to whatever place they have to in order to, well, sell their ideas to the market.

Rack ’em Stack ’em Robots

My all-time favorite purposeful over-the-top is the tendency to pretend that prior to the cloud, every project was started with “rack ’em, stack ’em.” This is demonstrably false, as by the time the cloud was taking off, VMware’s market penetration was significant. And yet, the number of blogs/amount of marketing material that starts out with the premise that every application required waiting for physical server delivery and configuration is insanely high.

No. Enterprises, in particular, had to wait for VM allocation and configuration.

Another that isn’t really mainstream—and I’ve mentioned in other locations—is the AWS TCO calculator. The simple calculator is not a bad tool, and I’ve used it numerous times in the past, but the TCO calculator makes some assumptions about deployment costs that are a little wild, such as that TCO includes the cost of VMware and its supporting hardware for an individual app. Of course, that’s not how enterprises do it. There is a VMware infrastructure and it is shared across apps. While it would increase the complexity a tiny bit, a simple checkbox that asks, “Do you already have a VMware cluster?” would go a long way—or better, one that asks how many apps you are running on VMware and divides the overhead by that number before including it in TCO. But of course, if you are getting your TCO comparisons from a competitor, expect the TCO will be stilted, no matter who is generating it.

Oversimplification

Whether it is infrastructure orchestration or app deployment, there is a lot of content out there that talks about how much easier infrastructure as code will be, and how much less documentation we will need. This, sadly, is a bogus premise. Whether you’re using the 50,000 service offerings of AWS or the power of HashiCorp’s Terraform—or any of half a dozen other competitors—it is complex. We’re not doing anyone any favors by glossing over the complexity that inevitably occurs in enterprise-class deployments, and we’re doing a massive disservice every time someone claims that documentation needs will be less because it’s “self-documenting code.” Self-documenting code sucks without a ton of comments in App Dev, and it’s worse in deployment. Employees new to the process need, and should be provided, solid documentation on how the system works and where different pieces fit.

We’re deploying complex apps on complex infrastructures with evermore complex compliance and security requirements. It is not simple.

All or Nothing

There is a belief among too many aficionados that their way is the “One True Way.” The fact of the matter is that all enterprise application portfolios are complex and there is a metric ton of extant code that must be managed. A startup with one web-based app (no matter how large it may be) or a games developer focused on Android as its only platform might well have agile and DevOps as their only development/deployment methodology. No one else does. The enterprise running a hundred or a thousand different apps on several platforms is not going to flick a switch and say, “We’re all X now,” no matter what X is. Anyone who has tried to standardize the database in an enterprise knows that just doesn’t happen (I did, as an architect in a financial services org. It was ugly).

Some projects are simply great fits for agile and DevOps—those with a high rate of change, where a little bit of instability in return for rapid feature rollout—while others simply are not—ones that maintain data that must be rock-solid, ones with a low level of change, etc. Any given enterprise is a mix of these things. Back in the days of the language wars, I used to say, “Right tool for the job,” and today, in the days of the architecture/automation wars, I say the same thing. If the project is rapidly evolving and you want lots of small changes in a constant stream, agile and DevOps are the right tools. If the project moves slowly and has an emphasis on stability or data quality, it’s not a great candidate for these tools at this time.

I’ve talked about some of the bad vendors in this post, so I’ll call out IBM for being a good vendor on this point. Looking at the company’s model for moving the mainframe is a good example of how you could look at all of your IT, because IBM doesn’t say, “This changes everything!” It says, “Here’s how to tell what offers the most bang for the buck in moving to agile and DevOps.”

Just Keep Rocking It

Working in IT? You’ve been keeping your org running. Don’t start second-guessing your gut now just because the new shiny is being waved in front of you. Learn, change, do. But don’t rush into something with misinformation. Obey your gut and keep rocking your org’s world.

— Don Macvittie

June 20, 2018
DevOps Chat: How Cyxtera Uses DevOps to make AppGate SDP Better

In this DevOps Chat, we speak with Kurt Glazemakers of Cyxtera. Kurt is the CTO of the Software Defined Perimeter group within the security and analytics group at Cyxtera. Kurt discusses how his group uses a DevOps approach to making AppGate SDP better and how that, in turn, makes it better for DevSecOps-enabled organizations.

In case you are unfamiliar with Cyxtera, it is the company that resulted from the acquisition of 57 data centers and the co-location business of CenturyLink (which then used that money to complete its acquisition of Level 3), plus the acquisitions of Cryptzone, Catbird, Easy Solutions and Brainspace. The company brands itself as the “secure infrastructure company” and is now one of the leading co-location players globally. Managed by most of the former senior management team at Terremark, which itself was acquired by Verizon (Oh, what a tangled web we weave in the tech world), Cyxtera is now something like a $2.8 billion business.

During our chat, Kurt gives us some great insight into how DevOps, automation and CI/CD have helped make Cyxtera’s product better. As usual, the streaming media of our conversation is below, followed by the transcript.

Audio

Transcript

Alan Shimel: Hi, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Today’s DevOps Chat has a distinctly DevSecOps/security bent to it, and I’d first of all like to welcome my guest, Kurt Glazemakers of Cyxtera. Kurt, welcome to DevOps Chat.

Kurt Glazemakers: Hey, Alan. Hi.

Shimel: Thanks for being here, Kurt. So Kurt, let’s start off with this first. What’s your title over at Cyxtera?

Glazemakers: I’m the CTO for our Secure Access product families, so I’m basically managing the whole development themes and the product for our Secure Access product family in Cyxtera.

Shimel: Excellent. And among the Secure Access products that Cyxtera is offering is something called AppGate.

Glazemakers: Yes, that’s correct.

Shimel: Give our audience a little background. What’s AppGate about?

Glazemakers: So AppGate is a tool that’s based on some of the fundamental principles of zero trust, to provide clients, wherever they are – in the office, in the airport, maybe in a Starbucks – secure access to their core applications and in such a way that the applications are securely accessed wherever you are and from whatever device you have. That’s basically in a nutshell what it does. It _____ a wide network _____.

Shimel: Got it. And Kurt, you know, bigger picture, Cyxtera, give me if you can, our listeners a little background there.

Glazemakers: Well yeah, sure. So Cyxtera is pretty new in the market. We’ve existed exactly one year and 25 days today, so it’s pretty new. And it’s an acquisition of 57 data centers that we acquired from CenturyLink, and where we added security software in order to provide secure _____ and hosting _____ _____ .

Shimel: Excellent, excellent. So is AppGate – I imagine it’s not offered just to your datacenter customers, or is it?

Glazemakers: No, actually AppGate came from one of those software acquisition teams, so we actually are widespread. We have widespread customers all over the world, actually. But most of the data center customers have a need for it, because they need to access their own data center _____ _____ requirements. Maybe they have access needs in the cloud, like the _____ clouds of this world, like the 80S or the ____ of this world. And with AppGate you can actually accommodate all of them with one solution. And with our footprint in the data center we can even offer it as a secure access service to our customers. So that’s a combination of the software and the data center footprint, which makes it very interesting from that perspective.

Shimel: Got it. So we’ve got the groundwork laid, Kurt. Let us now jump into what you and I really want to talk about, and that is that, you know, Cyxtera and the AppGate team have been on their own DevOps journey, their own DevOps transformation in how you’re actually developing and continue to develop AppGate as a product. And what’s really kind of unique about it – it’s like one of those Russian dolls where it’s a doll within a doll within a doll – is you’re using DevOps to help develop a product that helps DevOps. Right? Other DevOps _____.

Glazemakers: Yes, that’s actually correct.

Shimel: Tell us.

Glazemakers: Yeah, so what AppGate basically does, it provides secure access to applications, but the applications are dynamically discovered and added to the network, which is a real DevOps case, right? If you spin up an environment and you want to connect to that environment, even if it’s only lost for like a few minutes, AppGate is able to detect that and basically provide access in the moment that the environment is live. And when it’s gone, all of the access rules are gone as well. So it is nakedly a DevOps-driven security technology, which helps a lot of or actually most of our customers already in a public cloud or DevOps style of company, as a majority. Also we have enterprise customers, but this has actually been very well adopted in the DevOps _____. Yeah, so it definitely is a doll in a doll from that perspective, for sure.

If I go back to where we started, I started these tools about four years ago. And the reason why DevOps for us was so important is, first of all, it’s a network security product, which is very, very complicated in testing, because it requires a lot of security skills, a lot of networking skills and also software testing skills, which makes it very hard to basically perform the amount of testing in _____ hours, to give quick feedback to the user side or to the developer, in this case. So one of the things we’ve done in the very first place is we really spend a lot of time on creating our own tools, and that actually took even more than a year or a year and a half, to transform what, at the time when I entered the organization, was a more traditional way of developing with a developing process, a QA process, a delivery process. And that process was too slow and didn’t get or give the right outcomes.

So the first thing we’ve done – we spent about one and a half years on only developing the automations and the DevOps _____ _____ case. So yes, that’s where we spent a lot of time and actually that’s also helped us in gaining a lot of efficiency in the dev team after _____ _____ _____ in this case.

Shimel: Excellent. So Kurt, you know, we’ve spoken to several – more than several. We’ve spoken to a lot of organizations that have kind of undergone their DevOps transformation. If you can, share with our audience, how did this come about? Was it top-down, bottom-up, middle-out? You know, whose bright idea was it to do DevOps here?

Glazemakers: Yeah, okay. I think you need actually a little bit of both, right? So when I entered the company, I had some experience in the past and I really wanted to bring it to the same level, because first of all, the QA profiles are very hard to find and they don’t have the same throughput than if you do it in a proper DevOps way. So I definitely wanted to put guidelines in here, but you cannot do it if you don’t have buy-in from your own devs right now. And these devs were immediately onboard and we started actually as a _____. So basically I would say this is a top-down and a bottom-up approach at the same time.

But that definitely brings challenges, because if you go from a traditional way to a new way, it means that certain people probably will not be a fit in the reorganization, right? So if you have too many people that have never been a coder, that actually brings challenges on their skillsets. So that was not the easiest way to progress in the organization, but once everyone saw the benefits, I think we really shifted from a traditional-driven organization to a full DevOps and really a _____ _____ _____ organization. We did it in that year and a half I was talking about. So yes, that’s the guideline. But you need buy-in from both your developers as well as the management team, in this case.

Shimel: Excellent. And now, Kurt, since you’ve moved to a DevOps sort of framework here, have you guys done any sort of ROI or any sort of analysis as to what – I mean, because one of the things that we always see with DevOps is it just feels that it’s better, right? We’re doing it faster; quality seems a little higher. But have you actually done any benchmarks or metrics that really get to that?

Glazemakers: Yeah, that’s actually a very good question. Actually it’s always hard to measure exact benchmarks, but if you look from an overall perspective, before, we were literally doing maybe one release every year, and that shifted almost to a multi-year release when this was adopted, which is a huge difference in this case. And the way we release is typically we have some quarterly release that contains all of the new features and then a monthly release which contains smaller fixes and patches. But what the biggest outcome was for us in this case is, by having a quarterly release and these smaller releases, it’s very easy to follow up with your customers on requirements.

Especially in the beginning when AppGate was the complete new concept. So it’s _____ _____ _____, and you need to convince customers. At that very, very early stage, “Yes, it’s great, but I need this feature or whatever before I can work.” And if you can actually deliver that by the end of the quarter and even prove to the customer it actually works, that definitely helps driving sales and getting the numbers in, in the quarter. So I would say from that perspective it’s not only about releases but the fact that we were so dynamic and were able to convince customers. To inject a last missing feature before they could sign a deal is probably the most visible item that even _____ _____ _____ by sales or management. Because you are actually fulfilling needs from a customer at a much faster pace in each case, which results in better financial results and more happy customers as well

Shimel: Excellent. Excellent. So what’s been the feedback? You know, as you said, it makes for happier customers and everything else, but let’s concentrate on your own internal development team. What’s the feedback been from them?

Glazemakers: In the beginning, a little bit skeptical, because you need to do all this move and the work and also you don’t involve the right group files. The nice thing is, what happened is, when they start to see the power of a properly-done DevOps file – and actually we have a little bit of a benefit with our product, because we’re not only leveraging DevOps as the _____ _____, making sure that we have all of these automated tests _____ _____ feedback, but we’re also using always our latest code base to basically upload the codes and to work with it. So even the code right now, I’m actually using the latest version at this moment, through a secure _____, to basically provide _____ _____. So you see that you immediately get feedback from that perspective.

So the first thing that we really saw beneficial for the devs is that they get very, very quickly feedback, to see how the software performs. But secondly, also when we were _____ _____ the organization – you get a lot of new talent in and the new talent is typically a little bit shyer, because if they commit something and it breaks a process, then you get – that’s not how you want to start in a new company. And with this DevOps style, where people cannot commit code before it went to the test _____ and before it can be merged and all of those things, you have first of all a very strong development process, which is not followed by developers, because they hardly feel there’s any process. And so it gives the developer at the same time a lot of freedom and a lot of trust in whatever code they produce.

And those three elements are incredibly key to raising the amount of efficiency, because people are not blocked because someone has entered the wrong code that actually breaks the builds. We have a lot more freedom to basically optimize or _____ _____ certain codes in the products. And last but not least, also from a security perspective, you need very, very tough certification sometimes, even if you are producing for government agencies and those kind of things. And that automation also provides a lot of feedback there, positive feedback, for the certification process, because everything is automated and enforced by the DevOps system as well in this case.

Shimel: Mm-hmm, excellent. So Kurt, I told you the time goes so fast. We’re almost out of time. But I wanted to talk a little bit about the other side of the house, which is, how are customers using this to help their own DevOps initiatives and their own DevOps development and deployments?

Glazemakers: Yeah. Yeah, that’s actually a very good question. Yeah, what you have with DevOps environments is, when you’re deploying in DevOps environments, you basically always typically want to deploy and actually forget about it, unless there is an issue when you want to go in. And this is typically administrative access for the development outside the system. And in a real production environment, in a DevOps environment, you really, really want to have strict, strict controls of that. And we have a lot of customers, for example, that maybe _____ _____ _____ that actually have this kind of discipline. And what we were able to provide was when they – even when it’s their own dev environment and they test, or if it’s a production environment, we can actually enforce different layers of access in this case. Maybe for the public environments you need two-factor application and a company-approved device in this case, or a security device that has all of the endpoint protection software and stuff like that running. And maybe for the DevOps environment itself, where all they’re doing is pre-tests, we might be a little bit less restricted. So normally like a normal device, “Okay, it’s just _____ _____,” and you’re able to access without – with just login and password, as an example.

The nice thing is, what our software does, it can actually provide both of these things at the same time. And also, when the environment is being sped up, the metadata that you provide by creating the environment can be used as the security mechanism. And this is really where we bring a lot of value for customers. Because if you have a DevOps environment that changes all of the time – changes IP addresses, changes operating systems and all of those things – even if they’re lost for maybe 10 or 15 minutes, we can automatically detect those and be able to provide _____ _____ if needed. If they have an open ticket or whatever, we can all combine those elements. And once that is received, we also have a proper _____, the records for which developer has access with the system, even if the system doesn’t exist anymore.

And that has been a great value for DevOps, especially in the financial world where DevOps becomes now _____ _____ _____ interesting. Financials are seeing the need that they need to develop at a higher pace, so they’re embracing DevOps. But at the same time they are very, very highly regulated, and that doesn’t change. And what we can do with our software is really provide the same or even sometimes better control of these regulations at the same time they keep their agility on the DevOps process _____ _____ _____.

Shimel: Got it, got it. So Kurt, as I mentioned, time does go fast. We’re running out here. But just last question – what’s the future look like with this?

Glazemakers: Well I have no idea what it will look like, but the way I see the adoption right now, the way I see the need for DevOps and actually the DevOps embraced in many companies these days, I’m pretty sure that the old way of securing clouds or virtual environments, using a primitive _____ defense or _____ _____, it’s too dynamic ______. There are too many hacks going around. And so from our approach, I would say this is definitely a completely new way of securing DevOps environments and, they’re also the first signs of _____ DevOps are on the horizon right now. And this is a fit. I think the first product that really takes into account whatever security _____ _____ _____ DevOps environments is immediately enforced on the network, all the way down to the user device. And that basically extends whatever you’re programming in your DevOps environments, to make sure it’s always secured down to the device of the user itself.

And I think that is going to be a huge driver of better security, but also in a much more dynamic security type of approach, which – DevOps has done a lot of great work on deployment and infrastructure. The network and security elements didn’t go as fast, and I think this is probably one of the next new waves that will drive that and maybe be even more secure than traditional environments using the dynamic approach _____ _____

Shimel: Okay. Excellent. Well, that was a great kind of insight, Kurt. I appreciate it. We’ll be looking – you know, a year? What did you say, a year and 30 days or so?

Glazemakers: Yes, that’s exactly – a year and 25 days. That’s how old Cyxtera is right now.

Shimel: Well, continued success and we’ll be watching Cyxtera’s growth. Thanks for being our guest today on DevOps Chat, and we hope to have you back on again soon.

Glazemakers: Thank you very much as well, and have a great day.

Shimel: All right, Kurt Glazemakers, CTO for Secure Access for Cyxtera joining us today. This is Alan Shimel, and you’ve just listened to another DevOps Chat. Have a great day.

— Alan Shimel

June 20, 2018