devopsy.kinsta.cloud

Category: Enterprise DevOps

  • The Sociotechnical Path to High-Performing Teams with Charity Majors

    The Sociotechnical Path to High-Performing Teams with Charity Majors

    Every DevOps team wants to be successful, but how can you measure this success? What exactly defines a DevOps high-performing team? How can you help your team function at an elite level?

    In this interview, Charity Majors, co-founder and CTO of Honeycomb, explains what it takes to be an elite performer, how DevOps teams can become more productive and how to effectively measure your team’s performance.

    Charity is one of the keynote speakers at this year’s DevOps Experience. During her session, she will walk you through the social and technical strategies that great teams all around the world are using to be happier and more productive.

    For more insights and tips on how to be an elite performer, attend Charity’s keynote session at DevOps Experience 2020 on Oct. 22. To check out the full agenda or to register for free, visit the DevOps Experience website.

  • Cloud Orchestration Language Roundup: A Comparison

    Cloud Orchestration Language Roundup: A Comparison

    What cloud providers do you work with? Google Cloud Platform (GCP)? Amazon AWS? Microsoft Azure? Which services? Are you using a managed Kubernetes such as GKE, AKS, Openshift or EKS? How do you manage your cloud resources? How do you manage the release cycle of the infrastructure and applications that you deploy?

    If the above questions are the basic introduction to describe your work, then you are probably also familiar with the console, API or both of a major cloud provider. You probably know how to use a configuration management tool such as Ansible or Chef, Terraform or CloudFormation, or some other similar tool. Additionally, you are familiar with the languages of one of these tools. You probably have opinions on those languages, which inform your attraction to the tools you choose.

    Kubernetes and Ansible use YAML. CloudFormation and Azure ARM can be JSON or YAML. Chef and Terraform have their own languages. (To be precise, Terraform can also be expressed in JSON.)

    cloudify orchestration language comparison
    A comparison of cloud orchestration languages

    Whenever you start learning a new tool, it is helpful to already know the tool’s language. The strength of using a standard language is that new users will feel more at home learning to use a language if they already understand the basics of its syntax. In the same way that many English speakers will relate to cognates in French, German or Latin than in Greek or Sanskrit without using transliteration, developers that know YAML will find it easier to learn Ansible than a tool that relies on XML. However, just because you know the language doesn’t mean you know the DSL. A DSL might use a language in a novel or even strange way that contradicts what you believe is proper.

    A number of variables may come into play when a user develops an opinion of a tool. The most important is, “How simple is it for me to create something that does what I want and minimizes frustration later on?” The next often are, “Which I venture is dependent on the first, are apparent scientific and analytical reflections? Does it lend itself to convoluted data structures? Do efforts to remain readable flounder because of inefficient use of space or punctuation?”

    Some projects, such as HashiCorp’s (Terraform), abandon a standard language to avoid such issues and instead create their own languages. The main drawback here is that it is more difficult to integrate the tool with existing projects and software libraries (although, providing for input and output in standard languages such as JSON can alleviate such problems).

    Cloudify has a DSL, which is based on YAML. Cloudify uses YAML, because it is easier to read than JSON, but powerful enough to define new types when necessary.

    Whether using a general language such as YAML or a proprietary one, certain designations are necessary: the type of resource, the name of the resource and often even whether the line refers to a resource, a parameter or a dependency.

    To illustrate the differences between the languages, and associated products that have been mentioned, let’s take a look at a few examples. Let’s use a relatively simple example, an AWS VPC, named “myVPC.” This is a simple resource to define in any language because it has relatively few parameters and no dependencies aside from an AWS account.

    Terraform:

     

      resource “aws_vpc” “myVPC” {

        cidr_block       = “10.0.0.0/16”

        instance_tenancy = “dedicated”

        tags = {

          foo = “bar”

        }

      }

     

    Terraform, or HCL, is notable for two reasons. First, the HCL “block” syntax recalls method definition syntax in a number of familiar programming languages. This is a nod to how Terraform, among all of these tools, relates to packaging infrastructure definition as code. Second, Terraform is the most concise. It only takes seven lines.

    Also, Terraform syntax infers significance from string position through the use of identifiers, such as “resource,” “aws_vpc” and “main.” HCL knows that block type comes first, followed by type and then name. For readability, this may be an ideal and certainly elegant method for defining components. Inside of the block definition is the API payload accepted by AWS EC2 Service for the creation of a VPC.

    One drawback of HCL is the punctuation requirements. Braces are required to enclose blocks as well as dictionaries. Arrays require square brackets.

    Let’s compare HCL/Terraform to CloudFormation:

     

      myVPC:

        Type: AWS::EC2::VPC

        Properties:

          CidrBlock: 10.0.0.0/16

          InstanceTenancy: dedicated

          Tags:

           – Key: foo

             Value: bar

     

    CloudFormation utilitizes YAML as well as JSON. These are data serialization languages. So, we are looking at our resource definition, less as code and more as information. This results in greater verbosity and decreased readability. Less concise, CloudFormation is eight lines.

    Whereas HCL uses “blocks” for resources. CloudFormation templates just call them “resources.” Instead of positional arguments, we have keys and values. “Type” defines the type. Properties introduce the resource API payload accepted by AWS EC2 service. However, YAML reduces the need for punctuation. Dictionaries are introduced by indentation and lists with hyphens. This can result in improved readability, and if someone really likes to use braces and brackets, no one is forcing them not to. However, it increases the number of lines and characters needed, because even abstract sections of the DSL require keys for introduction. This is because YAML accepts JSON.

    Ansible also has a module for creating a VPC in AWS.

     

      – name: create VPC.

        ec2_vpc_net:

          name: myVPC

          cidr_block: 10.10.0.0/16

          region: us-east-1

          tags:

            foo: bar

          tenancy: dedicated

     

    Ansible also uses YAML; however, there is no separation between API payload and other parameters. For example, authentication parameters are on the same level as payload parameters. Ansible uses modules for infrastructure management the way it uses modules for managing applications, which, while novel, is implemented in a clunky and relatively useless way. For example, you need a playbook for creation and a playbook for deletion.

    Cloudify:

     

      myVPC:

        type: cloudify.nodes.aws.ec2.Vpc

        properties:

          resource_config:

            CidrBlock: 10.10.0.0/16

            InstanceTenancy: dedicated

            Tags:

              – Key: foo

              – Value: bar

     

    Cloudify also uses YAML. It also works with key-value pairs. Cloudify is even more verbose than CloudFormation.

    A node template can be a resource or a group of resources. In Cloudify, there are three types of properties. The resource_config, which contains the API Payload; the client_config, which contains the API Authentication; and orchestration properties,which are additional properties that enable you to describe how Cloudify will interact with the resource. For example, all resources have the use_external_resource, which means that Cloudify can use resources that Cloudify did not create.

    Whereas Terraform/HCL uses “resource blocks” and CloudFormation uses “resources,” Cloudify uses “node templates.” Node templates can be a VPC or other cloud resource, or even a CloudFormation Template or a Terraform template.

    Azure also sports an orchestrator, Azure ARM, and has its own DSL to describe Azure resources. This is how a virtual network is defined in Azure ARM:

     

      type: Microsoft.Network/virtualNetworks

      apiVersion: ‘2019-11-01’

      name: myVPC

      location: “[parameters(‘location’)]”

      properties:

        addressSpace:

          addressPrefixes:

          – 10.0.0.0/24

        subnets:

        – name: “[parameters(‘subnet_name’)]”

          properties:

            addressPrefix: 10.0.0.0/24

     

    One notable difference in Azure ARM is that the resource entry in the YAML does not have a key name with the definition being the value of the name key; instead, the entire dictionary is a list item. This is perhaps more concise, but it may forfeit a modest amount of readability. Also, Azure is similar to Cloudify in that the resource definition “properties” is not on the same level as other more general details, such as “apiVersion” or “location.”

    The syntax for accessing a parameter is also a tad obtuse. Accessing a key in a dictionary via square brackets and parentheses is probably one of the most unreadable methods in the DSLs we are looking at.

    Like Cloud Formation, ARM can be written in JSON or YAML.

    Terraform can define the same Azure resource using fewer lines.

     

      resource “myVPC” “example” {

        name                = “virtualNetwork1”

        location            = azurerm_resource_group.example.location

        resource_group_name = azurerm_resource_group.example.name

        address_space       = [“10.0.0.0/16”]

        subnet {

          name           = “subnet1”

          address_prefix = “10.0.1.0/24”

        }

      }

     

    Cloudify will define the same resource in 14 lines. However, this could be shortened using default values.

     

      network:

        type: cloudify.azure.nodes.network.VirtualNetwork

        properties:

          resource_group_name: { get_input: resource_group_name }

          name: { get_input: network_name }

          location: { get_input: location }

          resource_config:

            addressSpace:

              addressPrefixes:

                – 10.10.0.0/16

            subnets:

              – name: subnet1

                address_prefix: 10.0.1.0/24

     

    Azure and Amazon expose ARM and CloudFormation as API objects respectively. This enables orchestrators to manage those resource stacks as single resources.

    You can define an ARM deployment in Terraform like this:

     

      resource “azurerm_template_deployment” “deployment” {

        name                = “myArmDeployment”

        resource_group_name = azurerm_resource_group.example.name

        template_body = file(“${path.module}/environment.json”)

      }

     

    The type requires deployment name, resource group name and template body. The latter can be supplied inline or using Terraform’s file function.

    Ansible can also define ARM templates:

     

      – name: Create Azure Deploy

        azure_rm_deployment:

          resource_group: myResourceGroup

          name: myDeployment

          template_link: ‘https://…/azuredeploy.json’

          parameters_link: ‘https://…/azuredeploy.parameters.json’

     

    Cloudify can also orchestrate ARM deployments. Here is a simple infrastructure stack in ARM using Cloudify:

     

      deployment:

        type: cloudify.azure.Deployment

        properties:

          location: { get_input: location }

          name: { get_input: resource_group_name }

          template_file: ‘resources/arm/environment.json’

     

    Cloudify can also accept a file or inline JSON (or YAML).

    Having defined the source code for our infrastructure components, we can now connect other resources and processes to this infrastructure dependency. We can use the Terraform template to a CICD workflow or a networking application.

    Using the same approach, Cloudify can also call Terraform stacks:

     

      infrastructure:

        type: cloudify.nodes.terraform.Module

        properties:

          resource_config:

            source: resources/terraform/template.zip

            variables:

              access_key: { get_secret: aws_access_key_id }

              secret_key: { get_secret: aws_secret_access_key }

              aws_region: { get_input: aws_region_name }

              aws_zone: { get_input: aws_zone_name }

              admin_user: { get_input: agent_user }

              admin_key_public: { get_input: public_key }

     

    Cloudify also utilizes other Cloudify deployment stacks as service components:

     

      infrastructure:

        type: cloudify.nodes.Component

        properties:

          resource_config:

            blueprint:

              id: my_deployment

              blueprint_archive: { get_input: infra_archive }

              main_file_name: infra.yaml

            deployment:

              id: my_deployment

     

    To summarize, there are many DSLs for orchestrating cloud resources. Each has its own focus: Terraform on simplicity and repeatability, CloudFormation on Amazon, ARM on Azure, Ansible on setting up applications and Cloudify on enabling users to automate any task, including automating Cloudify. We call this “orchestrating the orchestrator.”

  • Q&A: Implementing DevOps at Scale with Akash Tayal and Bob Vuong

    Q&A: Implementing DevOps at Scale with Akash Tayal and Bob Vuong

    Enterprises may be successful adopting DevOps initiatives but adopting DevOps at scale could become a challenge for some organizations.

    In this Q&A session, Akash Tayal, principal and U.S. cloud strategy and operating model leader at Deloitte Consulting, and  Bob Vuong, principal at Deloitte Consulting, discuss the benefits and challenges of adopting DevOps at scale.

    Akash and Bob are two of the keynote speakers presenting at this year’s DevOps Experience. During their keynote session “Scaling DevOps Across the Enterprise,” Akash and Bob will take a deep dive into the typical DevOps journey and the ingredients for success.

    What is the first step toward implementing DevOps at scale?

    In order to scale DevOps across an enterprise, we need to shift our mindset as the key driver. It begins with people creating value-driven capabilities. In our experience, this is based on four key areas: PACE (Process, Architecture, Culture and Engineering). An organization needs to shift to adopting flexible Process (ways of working) with tight guardrails, modular and loosely coupled application Architecture, Culture shift through cross-functional Product teams with aligned incentives and Engineering driving everything as code.

    What are some of the key benefits of scaling DevOps?

    In addition to frequent code deployments and lower time from concept to actual release, DevOps also puts more responsibility on developers, leading to lower failure rate. Scaled DevOps across the enterprise can shift IT from a cost center to a value driver for the organization

    What is the main challenge organizations encounter when scaling DevOps?

    The two primary challenges we see organizations encountering with scaling DevOps are: One, multiple tool choices available with each line of business preferring their own tools, causing fragmentation and proliferation which makes stitching the DevOps pipeline problem even harder. We see organizations adopting at scale focused on standardization of tools as one of the key drivers. Second challenge is a complicated software delivery lifecycle that further expands the problem due to security, compliance and multiple other processes required to release code to production. We see successful organizations managing CI/CD pipelines as a product in itself and engineering the pipelines to help developers focus the majority of their time on building business value code.

    What are the main takeaways from your DevOps Experience keynote session?

    Adopting DevOps is not just a technology transformation. It requires a process and culture shift as well. Whether you are starting your DevOps journey or have already been on the journey but facing challenges, this session should help you understand how organizations adopting DevOps have transformed their software delivery approach and delivered Better-Value-Sooner-Safer-Happier (BVSSH) to achieve their business goal.

    Akash, what advice would you give to organizations looking to implement DevOps at scale?

    Several organizations get bogged down in tools debate when focused on DevOps and building CI/CD pipelines. I suggest you focus on the business outcomes and create a single view across the pipeline to monitor the bottlenecks and address them. Driving aligned incentives across the delivery and release value chain is essential to ensure frequent releases of high-quality code versus stitching together fragmented tools across each line of business to make the pipeline work. A single view of the entire process and pipeline helps identify these bottlenecks and solve for them.

    Bob, what’s your advice for organizations looking to implement DevOps at scale?

    Tools are generally an easy place to start. The implementation of tools and developing a pipeline can be seen as a fundamental part of how teams will engage. Also they are measurable and show progress. You can see what tools are being implemented, and you can gauge how far along they are. However, too often the focus moves away from the people and process changes that need to occur. I would focus on the people dynamic and how to integrate and improve on the years of siloed IT divisions, expecting to work together toward common goals and objectives.

    For more insights and tips on how to implement DevOps at scale, attend Akash and Bob’s keynote session at DevOps Experience 2020 on Oct. 22. To check out the full agenda or to register for free, visit the DevOps Experience website.

  • Bringing Agility to Mainframes in COVID-19 and Beyond

    Bringing Agility to Mainframes in COVID-19 and Beyond

    Of the many ways this pandemic has shifted resources online, financial transactions are among the most critical. With the use of cash and checks grinding to a halt, transactions generated with our devices are increasing, and most of them are being completed on a mainframe. It’s not hyperbole to state that mainframes—the systems of record for major banks, investment houses and insurers—are helping to keep the world economy resilient, all without a single glitch.

    Will the increases in online transactions be temporary while sheltering and social distancing are in place or does this mark a critical inflection point in the market? There are already signs that the online uptick is here to stay. J.D. Power research says approximately one-third of retail banking customers plan to increase their use of online and mobile banking services post COVID-19, with this percentage expected to increase with the duration of the crisis. It’s likely similar increases in online transactions will take permanent hold with commerce beyond finances and retailing.

    Bringing the Mainframe and Digital Transformation Together

    The main beneficiaries of this trend will be those organizations that have committed to better serving their customers through digital means and include their mainframe assets in their necessary digital transformation. While the mainframe is the most securable, reliable, performant and scalable platform, mainframe software development and delivery have traditionally followed slow waterfall processes, further hampered by archaic tooling. New and growing workload demands will require organizations to apply Agile and DevOps methodologies to their mainframe code and data to increase their overall agility. What are the keys to doing this?

    Articulate Your Vision and Identify Impediments: Articulating your vision starts with outlining your goals. Maybe you want to improve velocity (compressing the time between business need identification and code in production), agility (the ability to make more frequent changes to application code), efficiency (automating time wasted on manual execution of common repetitive tasks) and integration (better coordination of code changes across platforms). Or perhaps an important strategic focus for your organization is empowering technical staff with mainstream skill sets to assume responsibility for mainframe DevOps.

    The key to achieving these goals is to identify your organization’s unique constraints – these could be tools that lock you into slow, waterfall processes; entrenched habits that fail to place sufficient emphasis on speed and collaboration; or lack of funding. Once an organization knows where it wants to go and what it needs to do to get there, it can start crafting a rational, credible transformation road map without compromising the reliability and stability of core applications.

    Modernize Your Mainframe Development Environment: The “green screen” ISPF environments of most mainframe shops require highly specialized knowledge and problematically limit new staff productivity. Modernizing the mainframe begins with modernizing the developer experience, which should feature a user-friendly interface that allows staff to toggle easily as they work on both mainframe and non-mainframe applications. The modernized mainframe user interface should also support integration with best-of-breed DevOps solutions to help improve the quality, velocity and efficiency of mainframe software development.

    Automate Testing: According to a Vanson Bourne survey, 90% of application development managers say that automating more test cases could be the single most important factor in their success as the pressure to accelerate innovation increases. Yet currently only 7% of organizations automate the execution of test cases on mainframe code.

    Technical obstacles have historically prevented the kind of “shift-left” automated testing that is commonplace in Java from being applied to mainframe development. Luckily, these obstacles have been removed and reliable automated unit testing can become a mainframe reality. Once unit testing is automated, organizations can extend automation to functional testing (to validate the implementation works as specified) as well as integration testing (evaluating if the collaboration between two or more programs works as expected) and ultimately improve an organization’s ability to accelerate innovation.

    Empower Developers: As mainframe applications have been expanded and enhanced over many years, they have typically become large and complex. They may also not be very well-documented. This combination of complexity and poor documentation is a major block to core transformation goals—including agility, confidence and efficiency. The undocumented idiosyncrasies of some mainframe applications and data structures tend to make enterprise IT highly dependent on the personal/tribal knowledge of senior mainframe staff. Worse yet, if a seasoned mainframe developer is no longer available, IT may be fearful of making any changes at all.

    Empowering developers means more than modernizing the mainframe development environment, as discussed above; it means making it much easier for any new participant/contributor to quickly “read” existing application logic, program interdependencies, data structures and data relationships. This enables them to work on even the most unfamiliar and complex systems with clarity and confidence—in essence, to be less reliant and more independent. It also means empowering developers to take on jobs that may have traditionally been done by a testing team, e.g. unit testing, or a DBA, e.g. test data setup to remove bottlenecks and speed delivery.

    Training: Once an organization has the right development environment in place, it can start shifting its process from a traditional waterfall model with large sets of requirements and long project timelines to a more incremental model. The move from large-scale waterfall projects to Agile represents a significant change in work culture for most mainframe teams. Training in Agile processes and work culture is really a must.

    Technical leadership roles and product owners, in particular, need in-depth training and coaching. All team members should have at least some formal introduction to basic Agile concepts. To ensure that mainframe development is not left behind, organizations should consider pairing mainframe developers with agile-experienced developers from other platforms.

    Include Mainframe Code in All Aspects of the DevOps Toolchain: If an organization fails to include mainframe code in all aspects of the DevOps toolchain, there will always be one code component (mainframe) that slows down the rest of the DevOps process. To truly enable DevOps and Agile on the mainframe, mainframe code must integrate easily and seamlessly with other tools in the end-to-end toolchain, including Jenkins, Digital.ai, Slack, CloudBees and others.

    Among the processes that must be integrated and automated include source code management (SCM). The shift from waterfall-based SCM to Agile-enabling SCM is a pivotal moment in mainframe transformation—an absolutely essential shift if an organization’s goal is to increase the speed and frequency of new mainframe code drops, optimize developer productivity and simplify end-to-end management of the software development life cycle.

    Organizations also need to be able to pinpoint mainframe code deployment issues as soon as they occur, so immediate corrective action can be taken. If such corrective action does not produce its expected effect, there must be the ability to quickly and automatically fall back to the previous working version of the application. This automated fallback is, in fact, a key enabler of rapid deployment and particularly important for mainframe code, since it is the primary means of mitigating the business risk associated with the promotion of mission-critical code.

    Enable Coordinated Cross-Platform Continuous Delivery: Mainframe applications and data increasingly serve as a back-end resource for multi-platform customer- and employee-facing applications that include mobile, web and/or cloud components. DevOps teams therefore must be able to fully synchronize the delivery of new, approved code across all platforms.

     This is the desired state of enterprise DevOps: a de-siloed environment where the mainframe is “just another platform” that can be quickly and appropriately modified to meet the needs of the business.

    Conclusion

    From the changes in the daily commute to the way we buy food, the COVID-19 pandemic is likely to exert long-lasting, sweeping changes in the ways we live and our preferences. As more people become accustomed to conducting more of their day-to-day activities online—including banking but so much more—mainframe development will be required to exhibit higher levels of agility than ever before. The tips described here can help organizations transform their venerable mainframes into platforms for innovation and become an autonomous digital enterprise that can thrive during seismic changes. After all, those who do this the best are likely not to be hampered by COVID-19’s enduring imprint on society.

  • Mainframe and DevOps in Traditional Enterprise, With ASG Technologies

    Mainframe and DevOps in Traditional Enterprise, With ASG Technologies

    The assumption that large, established enterprises—from insurance companies to government agencies—can’t adopt Agile processes or DevOps is based on the falsehood that legacy technology stacks won’t allow for it; that existing traditional mainframe applications or legacy applications that large enterprises are built on are incapable of adapting to these approaches.

    Accelerated Strategies Group recently released the new research report, “5 Crucial DevOps Strategies For Cloud and Mainframe 2020,” sponsored by ASG Technologies. In this episode of DevOps Chats, Jeff Cherrington and Anna Murray with ASG Technologies joins Mitch Ashley, CEO of Accelerated Strategies Group, to explore how mainframe app teams embrace DevOps, its processes and tools to equip software teams so mainframe apps continue to provide businesses with vital systems and capabilities far into the future.

    The audio file of the conversation is below, followed by a transcript. Enjoy!

    Transcript

    Mitch Ashley: Hi. I’m joined by some special people, some folks that I really enjoy working with from ASG Technologies—different from the ASG that I work with. [Laughter] So, I’m joined today by Jeff Cherrington and Anna Murray. Thank you, both, for being here.

    Jeff Cherrington: Well, thank you very much, Mitch. I’m Jeff Cherrington, I’m Vice President of Product Management for Systems with ASG Technologies. Many of you may know ASG. We’ve been in enterprise infrastructure management software for over 40 years, and certainly hold a prominent position as well in enterprise content management. We’re very keen to have the conversation today around how traditional infrastructure—meaning the mainframe—aligns with new DevOps initiatives in the enterprise.

    Anna, if you would introduce yourself.

    Anna Murray: Sure. Hi, my name is Anna Murray, and I’m a Senior Product Manager with ASG Technologies, and I work with Jeff Cherrington. And I have extensive experience with automation across platforms and data centers, as well as agile transformation for teams.

    Ashley: Excellent. Jeff was saying before we started that he used to work in radio—you can tell. [Laughter]

    Murray: [Laughter]

    Cherrington: [Laughter]

    Ashley: You’re very comfortable behind a microphone—no doubt, no doubt. We were talking about everybody’s on video these days, so that’s awesome.

    Murray: Right. [Laughter]

    Ashley: Well, great. You know, we’ve been doing some work together and we do have a report coming out to kind of pre-announce that. We’ll be talking about that a little bit later. But there’s a lot of myth about DevOps and mainframes. I know even some analysts—I won’t name any names—have said they’re two different paths, you shouldn’t try to do both. I think the jury has started to change their mind on that.

    Why do you think some of those myths have existed of, “No, we can’t do DevOps on mainframe environments?” Do you wanna start, Jeff?

    Cherrington: I think I will, and then I’m sure Anna’s got some thoughts that she’ll want to contribute. You know, it’s certainly a reality within the industry that we’re going through a generational shift around our leadership or IT, whether it’s infrastructure or application development. There are those who are still working daily, like myself, who represent the traditions of IT from the very beginnings back in the 1960s, and then there are others who are certainly much younger and certainly have much different experiences, which may not include any exposure to the mainframe. And, as a consequence, there might be some resistance, there might be a little bit of anxiety about the technology, and it can be formidable to approach if you don’t have the appropriate background.

    The things that we’d love to talk to, though, is that the mainframe as traditional technology still performs incredibly important roles within the enterprise. And at the end of the day, DevOps is much more about technique than technology, and it can apply as easily to mainframe and should as it does to any other part of the IT infrastructure.

    Anna, do you have some thoughts to build on that?

    Murray: Sure. You know, as I think about the generation gap that you’re talking about, I kind of come on the other end, but I’m Gen X. And so, we were the generation that said, “Oh, the mainframe’s dying,” right? [Laughter] So, that—obviously, I’ve learned that’s totally wrong, and the generation coming after us is coming in to learn the mainframe and realize how powerful it is, right?

    And so, I think a lot of the leaders that are coming in are coming from this generation that didn’t even think about mainframe for a while, right? And so, they did all their planning and their agile transformation and their DevOps transformations thinking about the cloud and all of their Windows and Linux and Unix servers and didn’t even think about the mainframe.

    And so, I think that’s the other side of the gap that happens. As the younger leaders are coming up, you know, especially, I would say blame my generation the most, right? [Laughter] Because there’s this gap, and—learn more and make sure you’re talking to both ends of the spectrum and learn about crossing the gap.

    Cherrington: And actually, the way I like to phrase it now is far less to use jargon like “generational gap,” but instead talk about generational bridge, because that’s what I’m seeing.

    Murray: That’s so much better, yeah.

    Cherrington: We’re seeing that the younger IT professionals are identifying that there’s great opportunity to work with mainframe in the coming years. And so, we see Millennials, or is it Gen Y—the generation after yours, Anna—who are stepping forward and saying, “This is really interesting. The mainframe does all of the technologies, it supports all of the technologies that I learned in uni, university. I can do Java, I can do TCP/IP connections, I’ve got great sources for strong cryptography, it supports Unix, I can put Linux onto a mainframe LPAR—this is a good space to be in.”

    And so, more and more, we’re seeing that the people we engage with are a mix of people that are my age with the white beard or the gray beard and a mix of young, fresh faces that are really eager and really excited to get involved, and who come predisposed to new techniques such as DevOps.

    Murray: Mm-hmm.

    Ashley: You know, there’s so much important things that both of you said. One is that in DevOps, there is no technology definition of what it applies to, and it’s very easy to associate it with Cloud Native and maybe newer applications, because that’s where it sort of grew up initially.

    But DevOps is really about how we create software, not what technology we use to create software. And it’s about how teams collaborate, it’s about how you share information, it’s about how you get different functions from the business together in a collaborative team to kinda do things earlier in the process, do automation. All of that applies to the mainframe, of course, and there’s tools to do much of what we’ve talked about. Maybe you can say a little bit about how people approach DevOps in the mainframe environment.

    You wanna go, Anna?

    Murray: Right? Well, you know, when you approach DevOps in the mainframe environment, it’s not so much just about the mainframe environment, but the company. The whole organization has to be behind DevOps, and there has to be leadership saying, “Hey, this is something we need across silos,” right? And then you have to look at the tools available to you. DevOps is a lot about the toolchain itself. There’s hundreds of tools in that toolchain, and so, you have to start looking for solutions that are gonna meet your needs and help you cross those silos.

    Cherrington: You know, it’s certainly true that everybody resists change. I think that’s an innate part of human nature, but both Anna and I have seen that things of this nature can come forward, can be used with teams that are mainframe-centric, perhaps have been doing things the way they’ve been doing them for 10 years or 20 years or 30 years.

    And there’s natural resistance. “Gosh, you know, I’ve done things the way I’ve done them successfully for so long, why should I change?” Certainly, I’ve seen agile adopted by mainframe development teams, sometimes kicking and screaming, but once the resistance curve is overcome, it becomes very productive and becomes very natural.

    And I think we’re at that stage now in terms of adoption of DevOps for the entire enterprise infrastructure, from Windows all the way to the mainframe and onto the cloud and even onto mobile, even as there are initial reactions of going, you know, “How can this apply? This is not something I learned when I went to my classes to learn more about the mainframe at SHARE in 1995 or 1985.” But we have proof points.

    We have large international enterprises, we have small regional enterprises that are coming forward and saying, “I must have mainframe. It plays a critical role for things that I need to do, particularly around payments processing, anything that needs highly available, real-time online absolute reliable performance. And it is only part of my infrastructure, and I need to treat how I develop there the same way I treat developing anywhere else.”

    Ashley: You were talking about, also—so many apps are not just a mobile app, right? There’s a whole back end to it, oftentimes sharing data, even talking transactions between multiple systems, one of those or multiple may be mainframe applications. You know, and if I step back for a minute and think about our current environment and how much things have accelerated in doing sort of these digital transformation, digital experiences for customers, organizations are looking to both strategically move quicker, but also be able to react opportunistically and sometimes based on conditions. And it seems like some of the flexibility with DevOps makes it easier to coordinate some of those activities across multiple applications. So, if you do have to do three different release to make up one new capability, that comes together much easier.

    Cherrington: It does. You know, the thing that I always look to as I engage with anything around business is, to use an old phrase, “why is the juice worth the squeeze?” And while we talk about DevOps a lot because of its elegance, because of its collaboration, because of the ways in which it makes development easier, the real juice of the squeeze is time to market. The whole reason to consider DevOps is how can we get something we need to get in terms of new technology enablement to market quickly, more quickly than we did before, but not sacrifice quality.

    And that’s what we see time and time again is, we have something we need to get to market. I want to present new capabilities to my customers through an app on the phone because that’s where people live their digital lives. But at the back end, it’s dependent upon the mainframe for things such as account balances, customer statuses—an unending list of capabilities that still remain on the platform as the best place for that type of activity to occur.

    Ashley: Mm-hmm. You know, I’m thinking about just the recent experiences with the reactions to COVID and contactless delivery, inventory, product inventories are often something that’s still on the mainframe, has been for a long time, and now, you know, retail stores, as well as a lot of others, have to be able to maintain a really accurate enough inventory and also present that to the customers so they know, what store can I go at to pick up whatever I’m looking at buying.

    I’m curious, too—I know that ASG Technologies has some of your own products, your own technology around this idea of orchestration across platforms because you work both mainframe and non-mainframe environments. Talk to us a little bit about how you approached coming up with that product and maybe a little bit about how it works and what it does.

    Murray: Sure, I’ll jump in for a little bit here. You know, you talk about orchestration—that’s combining your toolchain, right? You’ve got all the little pieces of your DevOps toolchain, and you need to figure out how to connect all the dots and bring it together and, you know, ASG has been doing automation and orchestration for a long time, but we’ve changed our focus into bringing in the development part of that toolchain, right?

    Operations has been kind of a focus of automation for a long time, and now we have to pull in all of the development pieces that happen and the configuration management that happens, and all of those—there’s lots of little tools there, right?

    So, we haven’t tried to come at the market as trying to provide all the tools, but we’re trying to provide some of them, right, and we definitely want to orchestrate as many as possible, right, and cover the entire environment for the customer. On the mainframe, the most popular thing we’ve been working with recently is JCL Management. Every mainframe’s running JCL, right? Nothing happens on the mainframe without it, and so making sure that there’s a DevOps interface to your JCL Management solution is really important. And so, we’ve made an investment in making sure that ours has both an Eclipse plug-in that makes it easier for the developers to interface with that JCL as well as a RESTful web service API so that it can be integrated with building of the products and crossing across the silos to other products.

    Ashley: Mm-hmm.

    Cherrington: And certainly, in the approach that we’ve taken, we look to be a good citizen of the DevOps enterprise community, and the work that Anna and her team have done, we ensure that we support the most popular integrated development environments for doing this sort of work. So, the JCL quality assurance and management offerings that we have for the mainframe are also certified for the Compuware Topaz integrated development environment and for the IBM—what’s the name of it again, Anna? It’s—

    Murray: IDZ.

    Cherrington: IDZ. What was the rational development environment that’s now rebranded?

    Murray: Yes. [Laughter]

    Cherrington: As well as any other Eclipse compatible IDE that a customer may want to use.

    Ashley: You know, it’s interesting, just thinking about all the, a number of the terms that you both used in just those last two comments, you know, mainframe 10 years ago, you wouldn’t have been talking about, I don’t think, RESTful IDE—all the tools that we kinda think of as sort of in cloud applications, much of it is the same toolset, a lot of the same ideas, just working with integrating some other different tools that are specific to the mainframe environment.

    Cherrington: It is, and you know, I certainly want to encourage those who are listening and watching—and particularly, those who may be ASG customers now or are considering becoming ASG customers—to join us at our worldwide customer conference, a virtual conference this year, EVOLVE, that will be occurring on October 6th and 7th, because we will be making some significant announcements about extending support in this area, including opportunities for creating interfaces to mainframe applications that can extend all the way to mobile, if that’s of use to a customer.

    We’ve had a lot of excitement coming into this, we have a lot of partners and customers who are going to be presenting, and there’s a great deal of energy that we’ll be putting forth around our DevOps support and DevOps enablement.

    Murray: And can folks sign up? How do they register to attend the virtual conference? Is that on your website?

    Cherrington: It’s on our website if you come to www.asg.com, I’m sure you’ll find something right on the home page that says EVOLVE 2020 and it’ll give you the opportunities to get, well, involved.

    Ashley: [Laughter] EVOLVE and involved at the same time.

    Cherrington: Exactly. [Laughter]

    Murray: [Laughter]

    Ashley: You know, the fact that you get to work with so many organizations that are adopting DevOps, I’m kinda curious about two things. How does the mainframe teams approach wanting to learn about DevOps and coming up to speed and trying it, and then how do the existing practitioners maybe outside of the mainframe group that are also using DevOps—how do they see what’s happening in the organization and how do they…do they want to participate, do they support it, are they kinda not sure? What do you see happening, there?

    Murray: So, yeah, you know, there’s a mixed feeling. You know, there’s definitely differences between, you know, if it’s led from the top down and people are being told they have to change, right, it depends on how you’ve adjusted the expectations in your team, right? Helping them learn what’s coming and why instead of just telling people what to do makes a huge difference, right?

    Ashley: Mm-hmm.

    Murray: We’re all much more interested in solving problems and learning new things together. So, it’s really important conversation is held properly, right?

    So, we have some that are really excited that they want to learn and they want to jump in from the mainframe side and grow, and then there’s others that are really just struggling and pulling their mainframe teams along, right? So, one customer I think of, you know, is standardized on Compuware Topaz Workbench, but the developers are less interested in switching over. They have some of the older generation who’s very comfortable with the green screen and they think, “Why bother switching to Topaz?” You know? They just don’t even get it.

    Ashley: Mm-hmm.

    Murray: And so, you know, the truth is, we really need to have solutions that meet the needs of all of the people that are part of the DevOps environment, right? So, it isn’t—you know, a very experienced mainframe programmer doesn’t have to use Eclipse, right? They can be quite happy on the green screen and we should let them stay there, right? [Laughter] And we do, our JCL Management solutions have a very robust green screen interface, and then we bridged the gap, as Jeff was talking about earlier, with having those APIs, right?

    And so—yes, so the DevOps toolchain is still brought together with something like our ASG Enterprise Orchestrator pulling in the code and grabbing with the API the JCL and making sure that the standards are applied and then bringing them across for compiles and distribution into another environment, right? Not that you compile JCL, but there’s other parts that are related.

    Ashley: Mm-hmm.

    Murray: So, you know, you asked—it’s kind of a mixed bag. And we see that, too, right? And as the conversation becomes more common, right, I think we’ll have more people who are more comfortable having that conversation and learning together.

    Ashley: Excellent. Well, Jeff has been bitten by the Zoom bug, so he had to call in from his call dropping, so glad you’re still with us, Jeff.

    Cherrington: Mm-hmm.

    Ashley: You know, we were just talking about the adoption process, and Anna, you were talking about how mainframe teams kind of approach this. I’d like the other side of it. DevOps teams that maybe aren’t in the mainframe group that have been practicing this for a while, maybe a few months, a few years—how do they see this happening, and is there collaboration? Do they pitch in, do they tend to work together or not? How does it go?

    Cherrington: Well, some of the things I’ve seen actually goes to either end of the spectrum. For the teams working with the more modern technologies and have to adopt DevOps very frequently, we find evangelists, those who have gotten to the point where they believe in the techniques and the approaches so passionately that they’re out there actually promoting them everywhere they can. It’s much like what we saw with the adoption of agile in the last decade. We’re seeing that same sort of passion surround this approach to development in this decade.

    You know, it’s one of those things, we have to keep in mind—DevOps was not even a term within the industry until 2009. I mean, it’s barely a decade old, and it’s in these last five years that we have seen the acceleration for adoption.

    Now, having said that, you know there certainly are always going to be pockets within any enterprise where, again, there’s resistance. There are those who are not looking for change and those that, perhaps, while they have embraced the DevOps approaches for their distributed systems or cloud development, look at the ideas of what they have to change or adapt to on the mainframe side and really don’t want to go there. The idea that there might be a long compile that has to be done on the mainframe before the next step in the DevOps process can occur will cause some—a little bit of agita.

    And that’s why it’s so important we need to take a look at the strategies that are necessary for DevOps success. I think that’s something that you speak to very eloquently, Mitch. And out of those steps, the one that I think is so critically important is culture shift. Just like with agile adoption, DevOps adoption needs support from the top, and it needs to be constantly vocal support to help people pull through these resistance curves. Resistance curves are natural and the quicker an enterprise gets through them, the quicker they get to a point that they’re delivering new capabilities to market much more quickly.

    Murray: Right.

    Ashley: Thanks for your kind words about the culture, too, and I want to get your thoughts on this, Anna. Culture is a lot of things, but I think we’re all human at the end of the day and none of us want to look dumb, right? We don’t want to tackle something we don’t know if we can learn or maybe not kinda look so good in front of our peers if we’re the ones behind the curve.

    And I think something that can help combat that is, one of the principles of DevOps is sharing, is really—it’s collaborating, but it’s also sharing. Sharing scripts, process, tools, content, methods—all of those kinds of things which, if you truly adopt DevOps, as you said, Jeff, you can become an advocate and then also help with that transition and very quickly, you know, they kinda get over that curve of, “Okay, alright, I’m not—I’m familiar with this,” as you mentioned, Anna, I can still use my green screen or many of the tools that I’m already using and I’m just adding to kinda what I’ve been doing.

    So, your thoughts, Anna?

    Murray: Right, well, I’ve recently been having other conversations with partners about this culture shift and it’s become really clear with other companies that are supporting DevOps and those initiatives that you really have to have not just buy-in from your senior management, you’ve got to have active support. You know, they have to sponsor the change.

    Because we’ve also seen companies who don’t go through the change, they fail. If it’s from the bottom up only and the senior leadership says, “Okay, yeah, sure, that’s a great idea,” but they’re not actually investing in it themselves, the team, when they hit road bumps—because they will. It’s not, you know, switching to DevOps doesn’t happen overnight. I think we all know that. And over time, you’re gonna hit roadblocks and you’re gonna get discouraged. And who is it that’s gonna lift you up?

    Now, hopefully, there’s evangelists that’ll help keep pulling you through and encouraging you, but at the end of the day, if your senior management isn’t coming back in to say, “Hey, guys, we believe in this process, it’s worth fixing, we’re gonna invest in whatever it takes to solve this problem,” then they’re encouraged to keep moving forward, right?

    But, you know, there is the difference happening out there where the leadership isn’t always invested in it. And so, that’s what we’re really encouraging when it comes to that culture shift that has to happen, make sure that you get not just buy-in but investment from your senior leadership.

    Ashley: Mm-hmm. Hugely important and it goes back to the, “Why are we doing this question?” that you talked about also, Jeff. You talked about really responding quickly and getting software out to market or quickly in today’s situation with COVID and uncertain as well as very quickly changing conditions, you know, something could very easily come down from Product Management or whoever to the development teams and say, “Okay, we need to add this capability or change how we’re doing something.” And the team’s ability to react quickly—I mean, they already do today, but even more quickly under these circumstances, I think, demonstrates the value not only of DevOps, but also those teams.

    Cherrington: Absolutely. Absolutely. I mean, it’s always a virtue to be able to get to market quickly. And in the current period of the pandemic, it’s a virtue that actually can impact lives on a broad scale.

    As the different national governments are taking the steps that they need to take to provide stimulus and secure the safety of their populations during all of this disruption, one of the things we’ve seen is that there have to be changes to critical traditional mainframe systems for all of this to happen. Certainly, the unemployment compensation that was distributed here in the U.S. touched legacy traditional systems at the state level that perhaps have not been actively developed for some period of years.

    And certainly, those government enterprises or commercial enterprises that were pre-prepared to apply their DevOps techniques to making those changes to their traditional offerings, traditional applications were better prepared to deal with this and to deal with the ongoing change as our government’s tried to figure out how to stabilize economies and get us through this challenging time.

    Murray: Mm-hmm.

    Ashley: You’re absolutely right, and that’s one example of many. I mean, there’s insurance claims processing to get your request fulfilled quickly, you know, new medicines—all of that kind of thing. There’s so many areas where mainframe technology is involved today.

    Well, I wish we could keep going. Maybe I have to come to the conference to continue the conversation. [Laughter]

    Cherrington: [Laughter]

    Murray: Yeah, we would love that.

    Cherrington: You would always be welcome.

    Ashley: Well, I appreciate that very much. And so, just a reminder for our audience, the EVOLVE conference is on October 6th and 7th. Go to the ASG.com website to find out how to register; I absolutely recommend doing that. And as I mentioned earlier, we have a research report coming out and the working title of that report, I think, was “Five Critical Strategies for DevOps and Mainframe.” So, we’ll see, maybe that title will stick or something close to that. I’m excited to get that out because that’s been a great effort working with you.

    Well, Anna Murray, thank you very much; Jeff Cherrington, also—thank you for joining us today.

    Cherrington: Thank you so much.

    Murray: Thank you, Mitch.

    Cherrington: And folks—stay safe.

    Murray: Yeah.

    Ashley: Alright.

    Murray: Alright, thank you.

    Ashley: You bet.

  • Bringing DevOps to SAP, With Basis Technologies

    Bringing DevOps to SAP, With Basis Technologies

    DevOps has not only reached mainframe groups in enterprise but also to large applications such as SAP. Organizations are moving away from waterfall methods and mega releases that take many months to deliver. What’s needed are many more rapid release cycles and deployments that support the accelerating pace necessary to do business.

    In this conversation on TechStrong TV, David Lees, CTO of Basis Technologies, joins MediaOps CEO Alan Shimel to explore how organizations implement DevOps into their SAP integration and deployment cycles. Having lived through this transition, David shares his unique perspectives on the necessity to break through bottlenecks and make changes in supply chains, finance and many other business processes needed to support the business.

    The audio file of our conversation is below, followed by the transcript. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone. Thanks for joining us on another segment here for TechStrong TV. In this segment, we are joined by David Lees. David is the CTO at Basis Technologies. David, welcome to TechStrong TV.

    David Lees: Thanks, Alan. Great to be here.

    Shimel: Great to have you here. So, David, I don’t think we’ve done an interview here with Basis Technologies before, so I think we should start right there.

    Lees: Okay. So –

    Shimel: Go ahead.

    Lees: Basis is a company that’s been around for about 20 years. We are a global organization that works with hundreds of customers around the world, and the thing that they all have in common is that they run SAP software, as I’m sure many of your audience do.

    Shimel: Yep.

    Lees: We specialize in solutions around the application life cycle management space. We kind of started up the whole trend in terms of the DevOps for SAP by really helping people to manage their change in a much more Agile way than SAP is traditionally known for.

    Shimel: Excellent. And of course, you know, David we were talking off-camera before we got started, I’m doing DevOps.com seven years, right? And when I first started everyone said, “Oh, DevOps is something for startups; I don’t know about large organizations.” And then sure enough every large – not every, but most large organizations in the world started recognizing the benefits of doing things in a DevOps fashion, and we fought this battle with DevOps in the mainframe, DevOps on things like SAP. How could something like SAP benefit from DevOps?

    But of course they can, of course they can, and I think SAP themselves has recognized it and they’ve come out with a lot of DevOps-related solutions, products, services, but also companies like Basis are recognizing that, hey, my customers are asking me about DevOps but they’re not going to throw away tens of millions of dollars and years and years of tribal knowledge that they’ve developed in doing things on SAP. It’s just impractical. And so, you know, they have to put a little chocolate in the peanut butter and it’s got to work together, right? I would imagine, you know, Basis has – this is a real specialty that the market’s calling for and Basis has a real role to fulfill here.

    Lees: Yeah. I think it’s as relevant in the SAP world as it is elsewhere for exactly the same reasons; customers are looking to become more Agile, they want to be able to deploy in kind of just in time, moving away from the whole annual or six-monthly mega release delivered in a very waterfall way in order to respond to market changes, customer needs, in order to drive more efficiency within their application development and application management space and to deliver that with quality that a business-critical system like SAP mandates, to be honest.

    Shimel: Sure. So David, I always like to ask our guests a little bit about their own personal background because people out here are wondering, right? So they look at David Lees, the CTO of Basis Technologies, they’ve been around 20 years in the SAP space, they deal a lot. David, what’s your personal background like?

    Lees: So I actually joined Basis only about 18 months ago, and prior to that I spent the majority of my career on the other side of the fence. I was with Proctor & Gamble, a large global consumer goods company, and pretty much most of that time was connected to SAP in some shape or form from implementations through support, upgrades, getting ready for transformation to things like S/4HANA, and it was in that role as a customer that I first came across Basis a few years ago and actually brought in one of their products into Proctor & Gamble. So I kind of first had that experience as a customer of Basis before deciding to kind of make the step in to working here as CTO.

    Shimel: Excellent. So you literally have a career in SAP that you bring to Basis, and as you said, from the other side of the fence; not as a vendor but as a user, a consumer, a customer of SAP.

    Lees: And like you were saying before, I think many of the customers of SAP that have been running with SAP software for now 10 if not 20-plus years have developed the knowledge, they’ve developed their solutions and their processes exactly how they like them, but that’s come with massive investment, massive investment in custom code, custom solutions, investment in the way they’re managing those developments, those projects and maintaining them on a going basis, and so I lived through firsthand this whole lifecycle, let’s say, plus the last few years where the old way of managing things was simply not going to be the right way to continue to manage in the future because at the end of the day, while the rest of the architecture around SAP is evolving at a much faster rate you can’t kind of retain the bottleneck image that SAP has and you have to find a way of breaking that bottleneck and being able to move at a similar pace to the other elements in the architecture. It’s not as easy as saying, okay, well let’s just not touch the back end and keep that totally frozen. It’s simply not possible. You need to make as many changes in your supply chain and finance and legal entity structure, et cetera, as you do in your ecommerce platform.

    Shimel: Fair enough. Excellent. Again, the parallels to what we saw in the mainframe space is also – but I think there’s something else you gotta remember. People don’t use SAP just because of their prior investment or just because it’s what they’ve done before, right? Organizations of a certain size use SAP because it offers real advantages and allows you to do things in such a way that you can’t have or you can’t get with just about any other solution out there. So it’s not just because this is what my grandpa did or this is what we’ve done for 10 years, 20 years; it’s because we are an organization of a certain scale that we require this.

    Lees: Yeah. I think they’re a market leader for a reason.

    Shimel: A reason, right.

    Lees: They have the products that, like you say, run some of the largest enterprises in the world; many of the Fortune 500 or FTSE 100 or what have you. And it’s in spite of that that we need to find a way of being able to manage that in a much more modern way. There’s certain elements of SAP that I’m sure some of your kind of more pure DevOps listeners or audience would struggle to understand in terms of, for example, the way version management is handled in SAP inside like a single database, hard to manage branches in terms of parallel developments, the way changes are deployed through the use of things like transports, create to some extent an ecosystem in SAP that is different than a lot of the cloud native and more modern applications, but at the same time we want to be able to help customers to manage the risk, to manage the agility, and to be able to move things through with confidence and with speed in keeping their changes across their architecture orchestrated in a controlled way.

    Shimel: Absolutely. So David, if you don’t mind, I think we’ve laid the groundwork here well, let’s look at, if you will, the anatomy of an SAP-DevOps engagement, right? We spoke about maybe it’s an existing SAP customer who – right? – doing that big yearly release or twice-a-year release is not going to cut it anymore. They need to be more agile – nimble agile, not necessarily Agile software development, though that too, but they need to be more nimble, they need to be more responsive, they need to – they want to utilize a modern CI/CD pipeline type of delivery system.

    Lees: Yeah. I think as with anything here you’ve got the three normal components. It’s about the people, the process, and the tools. So there’s no kind of silver bullet that’s going to say, yeah, I’m suddenly DevOps in my SAP space. You need to have similar best practices around automating as much as possible within that pipeline, and some of that’s available natively inside SAP to do things like automated unit testing, automated code inspection, but the piece of the jigsaw, let’s say, where we come in is to create effectively the pipeline portion for SAP using one of our products called ActiveControl, and that’s about being able to deploy in an automated way within the landscape to the point where the customer is comfortable and being able to kind of highlight and manage all of the interdependencies or identify where it is safe or isn’t safe to move changes in a more accelerated way.

    So I think some of the best practices I would say are common across the SAP and the cloud native world, and when it comes down to some of the tooling you need to start looking at SAP-specific tooling where it’s not possible to leverage some of the kind of off-the-shelf open source best practice tools like best-of-breed ones such as Jenkins or Git, but equally this is where we can integrate and we can help a customer in managing their SAP side of their estate, their architecture, in a coordinated or orchestrated way with the non-SAP world that they’re managing using some of these more traditional DevOps-based pipeline tools or CI/CD tools.

    Shimel: Yep. Agreed. So David, when Basis comes in – let’s talk about the engagement now, right? Is it more of like a classic consulting where we come in with bodies or is it more of an architectural and here’s the processes and kind of maybe software we’re going to introduce or both?

    Lees: Yeah. So we are primarily a software company in terms of providing the solutions, although we do recognize and we do work with some of our customers that they also need help on what are the process changes or architectural changes that they should make in order to go further, in order to become more Agile, what are some of the, again, best practices that they should be doing without switching on or without investing in? They won’t be able to go as far as they want to or need to. So whilst we are today primarily a software company and we will come in to help our customers activate those solutions and deploy them, we are starting to kind of branch out a little bit more into the consulting side to help customers on that journey, to define what that journey looks like for them based on where they are today and based on where they want to get to.

    Shimel: Fair enough. So I’ve got to kind of ask it only because you have to in these days – how’s COVID affected all of this?

    Lees: I think we’re affected to some extent like many companies; however, we are to a certain extent well insulated. We have a subscription-based model, so the companies that tend to deploy our solutions continue with those solutions. We have an incredibly high renewal rate which we’re very proud of, and that gives us a very strong cashflow and a very strong platform in which we can continue to invest in new products and solutions as well as to continue to invest in identifying and adding new customers. I think to some extent there is – some of the pursuits, some of our prospects have been impacted by budget restrictions, but I think at the same time COVID is accelerating significantly the pace at which companies realize they need to transform. So I think it’s probably as much as one side kind of slowdown and budget restrictions as it is kind of companies coming in saying we have to modernize, we have to change the way we’re doing things and we need our SAP application development to be as flexible as we have elsewhere in our organization.

    Shimel: Agreed. And, you know, I kind of suspected that but I wanted to kind of confirm it with you, is yeah, you know, on the one hand it definitely – everyone working remote and everything that went on you could see it slowing down, but on the other hand it becomes very much a catalyst for transformation, right? There’s no waiting for tomorrow; we’ve got to do this now, and so it happens in there. What about working remote though, David? I mean you’re obviously in your home office right now.

    Lees: I am and I [laughs] was always set up in a home office kind of gig here at Basis, so I’m based in Spain whereas the headquarters is in London. So even pre-COVID I was kind of used to working a few weeks from home and then going into the office for a week or so every month. Now it’s just all at home for the foreseeable future. We’ve had to adapt. Development teams that used to be very – used to kind of working together, whiteboards and daily standups and that sort of thing have found ways of doing that remotely like everyone else has had to do, and yeah, I think we’re all getting used to a very interesting new world, and I would be very surprised if we go back to exactly how it was previously.

    Shimel: I don’t disagree with you. But the good news is, you know what, you’re still able to do your work, stuff gets done, and it could be worse, as they say. Hey, we’re about out of time but I wanted to mention one other subject. You guys are doing a webinar here on DevOps.com. It’s probably about a month from now, maybe even a little more than a month from now. It’s on SAP and DevOps.

    Lees: Yeah.

    Shimel: I’m not going to put you on the spot here and spill the whole beans, but who should be – you know, talk to us about it.

    Lees: I think the intended audience for that is people who are traditionally on the DevOps side of the fence who’ve grown up outside of SAP who need to or are realizing that SAP should become part of what they’re including in their plans and in their strategies. Now I would still say SAP kind of long-timers would get some value out of that webinar, but it’s more about helping people understand how SAP is relevant, why it’s relevant, and how we can help customers bringing the SAP world together with the more modern side of the application house for customers, and so I think it’s primarily tailored towards that audience.

    Shimel: Cool. More information on this will be available on DevOps.com under our webinar section. David, I look forward to that webinar. I want to thank you for joining us on TechStrong TV today. Where in Spain are you based, by the way?

    Lees: Near Málaga on the South Coast, so a nice little town.

    Shimel: Oh, it’s terrible, terrible, terrible.

    Lees: Like yourself in Florida.

    Shimel: Yeah, I was gonna say, in Boca Raton I really can’t complain either. But anyway, hey, thanks for joining us, look forward to the webinar in October, and keep up the great work.

    Lees: Great. Well, thanks a lot, Alan. I look forward to coming back on, talking to you again in the future.

    Shimel: Absolutely. David Lees, Basis Technologies, SAP and DevOps. It’s real. It’s something you need to be thinking about, especially if your organization is already an SAP shop. This is Alan Shimel. We’ll be right back with our next guest here on TechStrong TV.

  • DevOps Deeper Dive: IBM to ‘Maniacally Focus’ on Hybrid Cloud, AI

    DevOps Deeper Dive: IBM to ‘Maniacally Focus’ on Hybrid Cloud, AI

    IBM this week announced its intention to spin out a new company next year focused primarily on managed infrastructure as part of a plan to focus more on hybrid cloud computing and artificial intelligence (AI) initiatives.

    IBM is combining the Red Hat assets it gained last year via a $34 billion acquisition with its investment in Watson AI technologies, while an as-yet-unnamed company will assume control over IBM outsourcing services currently provided by the Managed Infrastructure Services unit of IBM’s Global Technology Services division.

    IBM CEO Arvind Krishna, appointed last April, on a conference call with analysts said IBM will primarily focus on high-growth opportunities driven by Red Hat OpenShift, Linux, Kubernetes, containers and DevSecOps software technologies that will drive a trillion-dollar hybrid cloud computing opportunity, while the new company will become the world’s largest IT services provider with more than 90,000 employees serving a base of more than 4,600 clients generating more than $19 billion in revenue. Today IBM generates a little more than half of its revenue from those services and claims to have a services backlog of $60 billion.

    The new approach will enable IBM to “maniacally focus” on hybrid cloud computing and AI opportunities, Krishna said. That shift will also create a separate company capable of generating double-digit growth that should result in a higher stock valuation at a time when investors are pouring billions of dollars into software companies. IBM this week disclosed it has 2,400 hybrid cloud platform clients and that the number of larger deals driven by Red Hat software has increased by a factor of two.

    To achieve its financial engineering goal, IBM will incur multiple charges, including $2.5 billion to spin out the new company and another $2.3 billion to set it up.

    IBM has a long history of spinning out companies. In its new form, the company will grow both organically and inorganically as it makes additional acquisitions, noted Krishna.

    The “new” IBM will look and feel a lot more like Red Hat than it will IBM prior to its acquisition of Red Hat, said Mitch Ashley, CEO and managing analyst of Accelerated Strategies Group (ASG).

    “It’s starting to head toward looking more like Red Hat acquired IBM,” he said.

    The degree to which IBM will be able to dominate hybrid cloud computing is unclear. IBM is making case for unifying the management of IT by standardizing on the Red Hat OpenShift platform based on Kubernetes that can be deployed on any public cloud or on-premises IT environments, including those that also house mainframes and x86 servers. In the wake of the economic downturn brought on by the COVID-19 pandemic, the rate at which IT organizations are expected to reduce costs by centralizing the management of cloud computing platforms is expected to increase.

    Adoption of multiple cloud computing platforms in the enterprise has tended to be reactive and any effort to centralize the management of those platforms is still in the planning stages, said Judith Hurwitz, president and CEO of Hurwitz and Associates, a research and consulting firm.

    “It’s not easy,” she said. “It’s not like you can go out and buy a control plane.”

    Ultimately, however, IT teams will have multiple options to choose from that don’t necessarily require them to adopt the Red Hat OpenShift platform.

    Similarly, IT organizations have access to a wide array of open source AI frameworks via cloud services that provide alternatives to Watson offerings.

    In the meantime, the rate at which organizations are transitioning to hybrid cloud and AI platforms is increasing. The issue IBM will need to contend with is making sure it doesn’t become distracted by its own internal issues over the course of the divestiture, which might take well over a year to ultimately complete.

  • New Survey Highlights Codebase Size Problems

    New Survey Highlights Codebase Size Problems

    Sourcegraph and Dimensional Research have released a survey of developers at large organizations, which shows a massive growth in codebase size, number of repositories in use and complexity concerns.

    “The Emergence of Big Code – A 2020 Survey of Software Professionals” is definitely intriguing reading, and a few of the results are eye-opening—such as the difference between what development managers think developers are using to search code and what developers say they are actually using. But most of it simply validates what we all knew: Codebases are growing at an alarming rate, through a variety of growth vectors—support for new platforms, use of open source and internal development. Adding environment to code à la GitOps, systems reliability engineering and/or environment automation is adding a layer of completely new source and a layer of complexity not normally in the developer’s realm of immediate concern.

    I’ve been working with Accelerated Strategies Group over the last few months, and we’re looking at tools in this market. The ability to quickly get up to speed on large codebases and the ability to find a specific area in a codebase that is massive and/or spans repositories is a very real need that is not currently well-served. This piques my interest in what Sourcegraph brings to the table, but at the moment we’re focused on the survey, so perhaps in a future blog we’ll talk about Sourcegraph.

    While there is a lot packed into the survey, I think my favorite part is crammed in with other “What would you find useful?” results (the slide is below). Fifty-eight percent of respondents—all of whom are developers—chose, “Finding code by querying semantic relationships, not just matching a string.” As developers, these respondents no doubt are aware of the complexities of this type of feature, particularly in environments with a variety of programming languages and scripts (be they bash, SQL, whatever) all working together. This is huge, and first iterations would be shallow, but is a worthy goal. I’m intrigued to see how well SourceGraph et al solve it.

    Source: The Emergence of Big Code – A 2020 Survey of Software Professionals

    It is also intriguing to see more than half of respondents want the ability to explore ” … both known and unknown code with code intelligence that provides contextual understanding.” That, too, is a tall order. Code analysis has gotten better over time, but contextual analysis of large codebases is notoriously difficult. I’ll be intrigued in the near future to play with this concept and tools that offer it to see how reliable they are and how much human guidance is accepted and/or required to make it a reality.

    Code change velocity reporting and contextual information about code are both available and pretty solid from the majority of full-stack DevOps vendors. Perhaps that is why that particular response only netted 45% and 43% of responses, respectively—the other 50+% are already using them.

    We’re in an interesting time when consolidation appears to be on the upswing and the needs of developers and DevOps teams working in large codebases are becoming more clear and more complex at the same time. Over the next few years the needs reported in this survey will likely be replaced by more specific needs as these are fulfilled and find general use. The question of databases and database integration in large codebase migrations, for example, has these needs, but has other needs closer to the problem domain. As these general issues are resolved, expect your vendors to turn to those more specific, but every bit as complex, problems.

    And just keep rocking it. Find out what the tools and companies already in use at your org have added, and if those capabilities fit with your needs or can enhance your Dev/DevOps exercises. Keep the lights on, keep customers happy and watch for tools to help you make it even better.

  • Financial Services Rise Above in Database DevOps

    Financial Services Rise Above in Database DevOps

    Financial services, pat yourselves on the back. A new study from Redgate shows financial services have superior database DevOps and database monitoring compared to other sectors.

    Financial IT appears to outperform other industries with high-quality database monitoring benchmarks consistently. For example, financial services on average are far quicker to detect and remediate failed deployments.

    Below, we’ll cover the main takeaways from Redgate’s latest 2020 State of Database Monitoring in Financial Services report, and bring in Grant Fritchey, Product Advocate at Redgate, to better understand why the financial sector is performing so positively in database DevOps.

    2020 State of Database Monitoring in Financial Services

    Redgate has released a special financial services edition of its 2020 State of Database Monitoring Report, a study that surveyed 971 database professionals across a wide range of sectors. This financial segment report highlights how database monitoring practices within banking, investment and insurance groups compare to other industries. Here are the main takeaways:

    Frequency and Remediation

    Financial services deploy more frequently and detect and resolve issues more rapidly.

    Financial services are quickly updating their databases. Sixty percent of financial services deploy once a week, whereas 43% of other sectors deploy once a week and some (10%) only update their databases once per year.

    Financial services are quicker to detect issues and respond. For example, 49% of financial institutions detect failed deployments within 10 minutes, compared to 39% across other sectors. The average Mean Time to Recovery (MTTR) is less than 10 minutes for 32% of financial services compared to 24% for different sectors.
    [su_note]Want to learn more about DevOps in Financial Services? Join us Thursday, Dec. 3, for FinConDX, a daylong virtual event dedicated to the latest in DevOps, DevSecOps and Digital Transformation practices and tools to help FinServ companies thrive. Register today![/su_note]

    It is impressive that financial services deploy more frequently yet still maintain higher Mean Time to Detection (MTTD) and MTTR than other sectors.

    Growth and Tools

    Financial services have a larger data footprint and a higher demand for database monitoring tools.

    The survey also demonstrates significant growth in overall database footprints, reflecting the sheer accumulation of data year after year. Whereas 26% of other sectors have 50 to 500 database instances, 36% of financial services have this many. Large financial data estates with more than 1,000 instances have grown 8 percentage points year over year.

    To help track these data estates, 66% of financial services use paid database monitoring tools. In other sectors, only 39% use paid database monitoring tools. The report predicts ongoing cloud migration and hybrid cloud modes will push these rates higher.

    Sixty-eight percent of customers report general satisfaction with database monitoring solutions. Yet, financial services cite a lack of features and time-consuming processes as top drawbacks, reflecting a need for financial services to utilize advanced functions and innovate quickly.

    Database Usage

    Financial professionals perform more tasks and grant more non-IT members database access.

    Working with more rigid security benchmarks, database professionals at financial services are often responsible for an increased number of tasks.

    Across all sectors, performance optimization and backups are the most common tasks performed by 70% and 60% of database professionals, respectively. However, if we look at financial services, tasks such as optimization, availability checking, user permissions management, patching and auditing are more common, all 8% to 11% higher.

    The report also found financial service databases, on average, are more widely accessed across the whole business, including database admins, management and business teams. According to the report, this could reflect a higher skill standard across the board at financial organizations.

    Issues

    Human error spikes moderately as financial IT innovates.

    Human error, capacity problems, bad deployments and software failure are top database issues across sectors. However, human error raises slightly within financial services, to 27% from 23%.

    “This spike [in human error] is just showing how fast our financial services institutions are changing to meet the needs of a changing business environment,” said Fritchey. Though there is a high demand to fill roles with data management skills, there is a talent shortage. “Recruitment is one of the biggest challenges,” he noted.

    That said, financial services do report fewer issues in other areas. For example, database access management is handled more efficiently at financial services. Whereas ad hoc user access issues have doubled in other sectors, financial services reported no significant change.

    Looking to the future, respondents indicate cloud migration, migrating to new server versions and improving performances as the top three impending challenges.

    Why Do Financial Services Outperform?

    Data demonstrates financial services on a superior overall curve when it comes to database DevOps. But why is this?

    “The answer is pretty simple,” said Fritchey. “Finance is driven by data. Therefore, they’ve always put the time and effort into protecting that information, and monitoring your systems is a fundamental aspect of data protection.”

    The financial sector is also prone to more security exploits and data privacy issues. Such concerns amplify the need for quality monitoring.

    “Organizations with good monitoring in place either also have better security or can spot vulnerabilities faster,” said Fritchey. With such measures in place, if a breach does occur, such organizations can react rapidly.

    International regulations such as GDPR or PSD2 mean financial services must meet stringent compliances. For Fritchey, active investment in quality database monitoring is part of this process.

    “The need to be able to operate across borders means that your systems must meet multiple compliance regimes. It simply makes sense to set the most stringent standards to ensure you can easily operate in the international sphere,” he said. “Monitoring is a fundamental aspect of meeting these compliance requirements.”

    The Future of Database Monitoring

    Financial services inherently require greater fault tolerance, and database monitoring is helping such services reach bank-grade security. As most respondents estimate their deployment frequency to increase in the next year, a greater focus on database integrity will be essential to keep pace.

    The financial services sector appears to be well-positioned for continued growth. With a shorter MTTD and a faster MTTR, financial IT is significantly more advanced than other sectors when it comes to database change frequency and issue remediation.

    “The fact that those with monitoring in place are also those who can more quickly deliver value through some type of DevOps process should cause people to pay attention,” added Fritchey. “All of this combines to make for a better overall organization who does more for their clients.”

  • Microsoft Advances DevOps Agenda

    Microsoft Advances DevOps Agenda

    Microsoft, at its online Ignite 2020 conference, has launched a bevy of updates that collectively further adoption of best DevOps practices on the Microsoft cloud platform, including for the first time a preview of an ability to store artifacts created using low-code Power Apps tools on GitHub.

    In addition, Microsoft announced a preview of an update to Visual Studio 2019 16.8 that will add support for GitHub Codespaces, a previously announced capability that automatically creates repositories on GitHub. GitHub Codespaces is currently available in beta and soon will be accessible directly from within Visual Studio.

    Microsoft also revealed it has enhanced the Git tooling experience in Visual Studio to enable more asynchronous collaborations. A GitHub extension for Visual Studio Code enables developers to work with GitHub Issues and Pull Requests directly in the editor. Development teams that need to work in real-time alternatively can employ Visual Studio Live Share.

    A publish experience in Visual Studio also now has the option to generate a GitHub Actions workflow for continuous integration/continuous delivery (CI/CD) environments in Azure resources using the deployment secrets configured in a GitHub repository. GitHub Actions for Azure can now also scan Azure resources for policy violations and vulnerabilities in container images and issues involving Azure Resource Management (ARM) templates.

    Microsoft CEO Satya Nadella told conference attendees the velocity at which applications are developed and deployed has become even more critical as organizations embrace digital business transformation in the wake of the economic downturn brought on by the COVID-19 pandemic.

    GitHub support for Power Apps is especially significant because it will make it easier for so-called citizen developers to collaborate with professionals developers as they jointly develop applications, he said.

    Other notable updates to the Microsoft tools portfolio include a preview of an instance of the Azure Logic Apps workflow platform that can be deployed as a containerized runtime.

    A .NET 5 Release Candidate is also now available, with general availability expected next month. This update adds support to smaller, faster single-file applications that use less memory when employed within microservices and containerized applications. It also includes significant performance improvements, support for Windows ARM64 and new releases of C# 9.0 and F# 5.0 languages.

    Microsoft also announced several updates to App Service to make it easier and more cost-effective to migrate and modernize .NET web apps on the Azure cloud. A new Premium v3 (Pv3) App Service Plan can handle large-scale web apps, supporting more apps per instance and larger, memory-intensive apps with up to 32GB per instance. Microsoft is also making Windows Containers support in App Service generally available and will soon make Reserved Instance (RI) Pricing for App Service available to reduce costs.

    Finally, Microsoft made several Kubernetes enhancements, including a preview of a start/stop cluster feature that will be added to Azure Kubernetes Service (AKS), and announced general availability of an Azure Policy add-on for AKS, which makes it possible to audit and enforce policies across Kubernetes clusters. Microsoft also made generally available Bridge to Kubernetes extensions for Visual Studio and Visual Studio Code that allow teams to develop against microservices within a running AKS cluster to enable debugging existing services without having to reconfigure or deploy a new cluster.

    Nadella said keeping track of developer velocity and overall “tech intensity” within an organization is critical to success. It’s not yet clear how many organizations have put the metrics in place to measure either. However, it is clear that organizations that have yet to fully embrace best DevOps practices are already being left behind.