Tag: ibm

  • Dependency Based Build Promotes the Freedom to Program

    Dependency Based Build Promotes the Freedom to Program

    Whenever I want to be amazed, all I need to do is reflect on the fact that the continuing development of the Linux operating system is done essentially by a community of volunteers. That’s right! One of the most popular and important operating systems is updated and maintained through donated labor. Any programmer anywhere in the world can make a contribution to improve the Linux kernel.

    That such a herculean undertaking is done though volunteer labor is mind-boggling. What’s more amazing is that the software created has an extraordinarily high level of quality. Let’s face it, working on the Linux kernel is not something a kid in high school with a year’s worth of experience programming in C can do. But, any kid in high school can make a contribution to the Linux code base, provided the code passes muster. That it happens is almost magical, in a way. But it does, every day.

    What enables such freedom? To my thinking, it’s the concept of the the pull request.

    The Powerful Elegance of the Pull Request

    The pull request is a simple yet important part of the open source development process. A developer creates a feature branch off the Master branch of the Linux repository, then adds to or modifies the code in that feature branch. Of course, the developer writes tests that verify the new code works. Once the code is complete, the developer sends a pull request to the project, which is typically hosted on GitHub or another popular Git repository platform. The project maintainers, a group of people who have expert knowledge of the code base, review the pull request using tools that are baked into the Git repository platform. Each maintainer inspects the code and, if the code passes inspection, the reviewer votes to approve. If the code has shortcomings, the reviewer makes suggestions for improvement directly in the code using the Pull Request Commenting features, which are available in practically all the Git Repository Platforms including GitHub, GitLab and Bitbucket.

    It’s a simple yet powerful process and one that has changed the way enterprise-worthy software gets created. Any developer can implement an idea any way they want, as long as the implementation is compatible with the code base. It’s up to the developer to figure out how to do what they desire; nobody is dictating anything. The process is straightforward: Figure out how to make your contribution to the code. Make a feature branch. Do your work. Do a pull request. If your contribution is useful and the coded well, you’re in. If not, we’ll try to help you make it better.

    Bringing Git to Mainframe Development Using DBB

    The pull request is a compelling approach to making software—so much so that IBM has made it a central part of software development on the mainframe. And, its product, Dependency Based Build (DBB), streamlines the mainframe pull request process by reducing the work reviewers need to do in the code review process.  [su_pullquote align=”right”]A Dependency Based Build trial is available in the IBM Z Trial Program at zero cost, and with no installation required. The trial environment includes hands-on tutorials.[/su_pullquote]

    Git version control is supported by practically all the modern IDEs. For example, developers can configure Visual Studio Code, JetBrains products and Eclipse to work with remote Git repositories automatically. Once integrated, Git operates behind the scenes, allowing developers to work under version control without having to issue Git commands directly. IBM’s mainframe integrated development environment, IDz EE, provides Git integration as well. This is a big deal, as Git is now part of the mainframe ecosystem. The developer accustomed to using Git version control when working on a standalone x86 Java app now can move over to developing for a mainframe without having to learn a new source control management (SCM) system. But what’s even more impressive that Git is used as the SCM for more traditional mainframe artifacts; for example, COBOL source code.

    Also, Git integration goes beyond developers working on source code; Git is used throughout the mainframe build process—which, by the way, can be controlled by Jenkins. And, Git is a foundational technology used by IBM DBB, a dependency control agent that works with Git to make sure that all files—source and dependencies—in the mainframe build process are current. Again, this is a big deal: Having all the moving parts in the mainframe deployment process, from programming to build to release, use Git as the common code repository allows z/OS mainframe components to be part of a platform-agnostic deployment process. Use of DBB overcomes a significant hurdle between the mainframe and distributed world.

    So, what does this have to do with the power of pull requests?

    Adding Pull Requests and Code Review to the Mainframe Experience

    The pull request review process is more than just “looking at code.” When you have a project that might have millions of lines of code, such as the Linux kernel, no developer is going to pore over each line of code. They’ll read the documentation, run the unit tests, look at the lines of code that have been added or removed and search for blatant problems and inefficiencies. Now, on a PC, compiling something such as the Linux kernel is straightforward—all the code is in the single repository. On mainframes, however, it’s a bit different: The code is more widely dispersed and dependency management can get tricky. DBB takes care of tracking dependency changes in various Git repositories, so when it comes time to do the pull request, the reviewer doesn’t have to waste time resolving dependency issues to get mainframe code to compile. DBB will take care of that. With regard to the pull request, reviewers can do what they are supposed to do: make sure the code works and the quality is such that it can all be merged back into a master branch.

    This might not seem like much, but anybody who has stayed up until 3 a.m. trying to resolve dependency issues understands the importance of having code that builds all the time, any time. This is the power that DBB brings to the table.

    The Freedom to Program

    Programming is a special vocation. It requires an unusual combination of art, science, creativity and engineering discipline. Also, it’s not a vocation that lends itself to well to prescription. Each programming project is special, requiring new ideas. And new ideas come about when developers are free to use their imagination to think differently. The pull request is one of the best ways to ensure developers have the freedom to program in way that produces useful, high-quality code. DBB extends the freedom to program to the mainframe community.

    History has shown that when a developer is given the freedom to code and a community in which to code, the result is great software. Just ask Linus Torvalds.

    — Bob Reselman

  • DevOps Chat: ‘Day 2 DevOps’ with IBM’s Eric Minick

    DevOps Chat: ‘Day 2 DevOps’ with IBM’s Eric Minick

    Now that the concept of DevOps has been around for a few years and more organizations have embraced it, the natural question for many is, “What now?”—especially considering DevOps success is measured by different yardsticks. IBM’s Eric Minick is has been grappling with the concept of “Day 2 DevOps”—enterprisewide rollouts, multiple toolchains, etc.—and the  best way to get organizations from point A to point  B.

    In this DevOps Chat, we discuss Day 2 DevOps and what IBM is doing in the tool space to help organizations move forward, as well as what other projects Eric and his group are working on.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    ​Alan Shimel: ​Hey everyone, it’s Alan Shimel devopsy.kinsta.cloud and you’re listening to another DevOps chat. This episode of DevOps chat features a friend of devopsy.kinsta.cloud, frequent contributor, author, podcast guest – none other than Eric Minick of IBM and UrbanCode. Eric, welcome to DevOps chat.

    Eric Minick: ​Hey, it’s good to be with you Alan as always.

    Shimel: ​Fantastic. So, Eric, you’ve been with UrbanCode since like about 2008 but your role has changed a little bit. What exactly is kind of the title role these days?

    Minick: ​​Yeah, I’m looking after product management responsibility across the UrbanCode portfolio as well as rational testing. So have just a wonderful team and boy we’re doing some good things, so having fun.

    Shimel: ​Very cool. So Eric we only have 15, 20 minutes here – I wanted to jump right into a couple of topics I want to talk. The first thing that I wanted to bring up was this concept of like a Day 2 DevOps as you call it or DevOps Day 2. Let’s explore that. First let’s tell our audience what do you mean by that?

    Minick: ​I think, you know, we look at how things were a couple years ago and there were a lot of organizations running their DevOps pilots, trying to figure out, “Is this going to work for us?” and all that sort of stuff. But I think we know it works, don’t we, by this point?

    Shimel: Well, I hope so but we’ll just keep publishing on it until everyone finally agrees, but yes, you’re right.

    Minick: ​So I think people are looking at like, “All right, I’ve got little pockets of DevOps here, some DevOps teams over there. How am I going to roll this out across my enterprise? I think we’ve got good stuff here, how are we going to do it at scale?” So there’s some scalability challenges, there’s also, you know in organization that had some really good ground-up work – like you have a couple of different teams who built stuff ground up and then they look across the way and they’re using totally different toolchains.

    ​And then you’ve got some poor guy who’s been dubbed the VP of DevOps and is being asking, “Well, how’s the DevOps going?” And so it kind of makes sense out of teams that are on different toolchains and try to pull data out of that, get new teams onto maybe one or both or some other toolchain. And so the scaling and trying to reconcile across all these different tools seems to be the challenge of the hour.

    Shimel: Yeah, I do agree. You know Eric it’s funny you mentioned this whole thing like “Can we agree it works?” and what have you because you, like me, we probably live in a little bit of a DevOps bubble where we’re not really talking to companies who either haven’t already started their DevOps journey or are contemplating starting their DevOps journey. But there are people outside of our bubble, right?

    Minick: ​There are. I think I saw one of the analysts who just said, “Yeah, but it’s,” – 40 percent are well on their way through their journey; 40 percent are seriously kicking it off now; and then there’s 20 percent– I spoke to a different analyst who said, “Yeah, I just think that 20 percent is just going to go out of business.” And you saw my article the other day: I agree.

    ​So yeah, if you’re not at least getting ready to start the journey – well, I guess I should just say I’m really worried about you. I was going to say I’m not that worried about you but it’s go time.

    Shimel: Yeah, it is, no doubt about it. So Eric for those folks who are sort of entering day 2 of DevOps – and I think this is a problem, so many people prepare for that D Day assault of day 1 and don’t really have the day 2 plan in place. What words of sage advice do we have for them? Where can they go to get information on this? What can they do?

    Minick: ​So I think it’s really important not to disrupt what’s working. If you’ve got teams that are out on some weird toolchain that’s not the enterprise standard but it’s really, really working: let them run. I think that sort of data has come out – we saw in the Accelerate book by ______ it all that, yeah, you want to empower teams, you want to let them run with good tool chains that are working – the ones that are – hey, this is why I have a very active tools business – this is replacing tools that don’t work with tools that work really well or helping teams that don’t have good automation capabilities around continuous delivery or testing.

    ​But then I think you’ve got to really look at, “How am I going to get a view across what’s going on? How do I normalize some data?” If we know that the key metrics for DevOps are things like lead time from code to production – all right, “How am I going to understand that across a number of tools and normalize that?”

    ​So it’s an area we’ve been doing a lot of work on in the tool space – and some other folks are doing that as well – it’s pretty achievable these days.

    Shimel: Agreed. So I guess when we start talking about issues around – and blueprints and plans for day 2 – the logical next step is, “What about day 3?”

    Minick: ​Well, let’s see what breaks in day 2 first. I don’t know it yet. I guess my dream, right – if day 1 is you have a bunch of DevOps pilot projects and day 2 is you hire a VP of DevOps to spread these new ways of working across your enterprise – day 3 is you don’t need that VP anymore, right – that you’re dedicated – you know, we bring the DevOps group within your organization – isn’t needed because your transformation is complete, you’re an agile technology powerhouse within your business helping the business along – you don’t need that transformation team anymore; this is just the way that you work.

    ​So I’m hoping that’s day 3 – that all these people do transformations and move onto the next big thing.

    Shimel: ​Fair enough. You know I’m hoping so too Eric, though I hope that doesn’t put me out of a job. Anyway –

    Minick: ​​I think we’ve got a decade or two, man.

    Shimel: Yeah, I think I’ve got enough runway. So Eric let’s turn from DevOps day 2 and DevOps day 3 to what’s going on specifically with UrbanCode. You’ve got some new releases out both community and enterprise or commercial editions, so what’s up?

    Minick: ​​Yeah. So UrbanCode Velocities are kind of a brand new star. So we shipped a community edition earlier this yar and then in the last little bit we came out with the full commercial edition. And I mentioned earlier there’s tools that pull together data from different tool chains – yep, that’s where we’re running with Velocity – you know, looking at things like a lot of our customers have anUrbanCode Deploy for a huge chunk of their workload and they’ve got some teams doing something else – oftentimes it’s simpler apps, they’re running it just on a Jenkins pipeline or something – and they want a view across that.

    ​Very often they need to coordinate a delivery across the two where, “Hey, I need to kick this thing to Jenkins and that thing and maybe they could deploy at the same time.” So we want to make sure that you’ve got a common view of what’s in your test environment even if different pieces and parts of your application are being delivered by different tools, and that you’re able to understand things like lead time, cycle time, deployment success rates – kind of the heartbeat pulse/health of your continuous delivery flow.

    ​So really excited about Velocity. It’s in this brand new market space. Some people are calling it Value Stream Management, others are calling it DevOps Tool Chain Orchestration – but it gets into this idea that lots of people are using lots of different tools to get value out the door as part of your organization, and having a view across that and a way to kind of orchestrate across that is really powerful.

    ​So yeah, people are checking it out, they’re loving it – it’s a ton of fun – the funnest time in a product manager’s life is launching that new product, so good times.

    Shimel: Absolutely. So in a way though this kind of goes back to Urbancode’s roots, right, with UrbanCode’s roots in open source and free software, commercial editions and all that – nostalgia Eric in that or lessons learned doing it better?

    Minick: ​​Yeah. I think a little better. We did start out with good old Ant Hill as an open source product – you know, to have a community edition and just say, “Yeah, here’s what you get for free,” which is really a lot of reporting right now for UrbanCode Deploy, “And here’s what you get when you step up,” that feels good and a lot cleaner than the press but – you know, we had tried 15 years ago and we tried to build an open source business.

    Shimel: No doubt about it. Eric, then you have another version of UrbanCode out – was it 7 or something?

    Minick: ​​Yeah, we shipped 7.0 for UrbanCode Deploy – and that’s a big deal for us. You know UrbanCode Deploy started at like 4 so 7 is not – you know, we do big, chunky versions for this – 6 came out a few years ago.

    ​So what got us over to a 7 is some re-architecture under the hood – that’s getting us up from being able to manage in the neighborhood of 10,000 machines on a master cluster of UrbanCode Deploy to being able to deploy to something closer to 100,000. So often 10X is a pretty good improvement.

    Shimel: Not too shabby.

    Minick: ​​Not too shabby. And you know that’s where we’re ______ of the day 2, right? You know, when we were shipping this thing five years ago we asked clients, “Well, what’s the most you’d anticipate ever deploying to?” and they’d say, “I don’t know, a couple thousand machines might be appropriate for this.” But now you walk into a bank and they’ve got 100,000 VMs under management and they want to get to all of it – they want to scale.

    ​And so I guess the two sides of the coin here – so UrbanCode Deploy saying, “Hey, if you’ve got something that works in UrbanCode Deploy and you want it everywhere in your organization we’re going to make sure there aren’t barriers to that,” right? Big emphasis on that.

    ​All right, if you’ve got a little of everything and you want to make sense of that we don’t want to tell you you’ve got to throw it all out and adopt UrbanCode Deploy: we want to bring in something like Velocity and say, “All right. You’ve got a mess. You’ve got 97 instances of Jenkins with 50,000 jobs across them. Let’s bring some order to that chaos. Let’s give you a view across that. Let’s help you orchestrate across that.”

    ​So that’s kind of the two sides to the day 2 coin from our perspective. A bunch of good stuff in Deploy 7 so it’s not just the scalability we redid the UI to make it a little easier to work with, a little cleaner – I think it’s really beautiful.

    ​You know, we made it easier to kind of manage your processes – your automation processes that could easily be shared across a bunch of different applications. It lets you kind of change them in a little sandbox and code review them and then publish them out to all of those applications that share them – we’re calling that a safe edit capability – we’ve added a graphical designer for Terraformdocuments – so you want to describe how you’re going to publish out your workload we’ll do that nicely with Terraform.

    ​So just a ton of great stuff in there. Big emphasis on helping our customers scale really cleanly and then making sure we pick up all those new tech stocks like Terraform.

    Shimel: Got it. Cool stuff. So Eric we continue to see IBM moving forward with UrbanCode and obviously you’ve spoken a lot about a lot of the big developments there within the context of the continuing maturation of DevOps. But you mentioned that you’re also doing or helping to manage some of the testing and – I’m drawing a blank now –

    Minick: ​​Yeah. So testing and service virtualization – so rational test workbench, rational –

    Shimel: Rational. Excuse me. That’s what I was thinking of. I apologize.

    Minick: ​​Yeah.

    Shimel: You know, we only have a minute or two but give us a little update on that.

    Minick: ​​We’ve been doing a lot of good stuff, expanding some integrations for mobile testing. The service virtualization is always really nice particularly – you know, we’ve got a lot of customers trying to modernize their apps – they say, “Okay, I’ve got some big workload. I like to bring it over to Kubernetes, containerize it,” and then you’ve got like the one thing that doesn’t fit in a container – some crummy appliance from a vendor or – maybe it’s your mainframe that’s part of the app – and so service virtualization is really having a good day to say, “Okay, we’re going to stub out, we’re going to virtualize out,” you know this thing that’s holding you back from being able to really leverage cloud or dynamic infrastructure, and then you’re going to – you’ll be able to leverage it into all these lower test environments – we’ll bring that component back in for late testing – and obviously it’s there in production.

    ​So yeah, the test area is really dynamic. A lot of fun. I’m surrounded by a bunch of great people in that area too. So, yeah, it’s a lot of fun.

    ​And I’d say how I look at it is the build/deploy automation you have in something like UrbanCode that’s the skeleton for your continuous delivery – that’s not the path. All the work you do is testing, right? You’re doing performance testing and security testing and functional testing and API testing and unit testing – we could go on for hours – and so these things come together to really be the heartbeat of your continuous delivery.

    Shimel: Cool. Well, Eric it seems like you know you’re certainly busy enough, huh?

    Minick: ​​Not bored.

    Shimel: Absolutely, man. Hey, we’re about out of time here but I wanted to thank you for joining us today and we’ll have you back on soon – we’ll probably be ramping up for IBM Think in San Francisco in a couple months so maybe before then we can catch up.

    Minick: ​​Absolutely. I’m going through session proposals now. I’m super excited.

    Shimel: Cool beans. Eric Minick always a pleasure to have you here on DevOps chat. Thanks for the updates and keep doing what you do, man, it’s great.

    Minick: ​​Cheers Alan.

    Shimel: ​All right. That was Eric Minick, UrbanCode and IBM Rational. And this is Alan Shimel of devopsy.kinsta.cloud. You just listened to another DevOps chat. Have a great day everyone.

    — Alan Shimel

  • Open Mainframe Project Launches Zowe to Advance 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

  • IBM Boosts On-Premises Clouds with Cloud-Native Development Capabilities

    IBM Cloud Managed Application Services synchs with IBM Cloud Private for Next-Gen Application Development

    ARMONK, NY – 21 June 2018: IBM (NYSE: IBM) has announced that for the first time, its industry-leading IBM Cloud Private application platform, will be made available to run on the company’s enterprise Cloud Managed Application Services (CMAS).

    Hundreds of world-leading banks, airlines and government organizations already rely on IBM Cloud Managed Application Services for managing enterprise applications on security-rich clouds. IBM is now enabling its CMAS customers to help extend their capabilities and maximise existing investments by synching with IBM Cloud Private – a new solution based on Kubernetes containers designed to rapidly build, modernize and deploy applications in client-managed environments.

    By bringing the two together, clients taking advantage of the security rich and production-ready cloud environment that CMAS offers, can now reap the benefits of the latest cloud-native DevOps capabilities of IBM Cloud Private, accelerating time to market for innovative, cloud-native applications.

    “We see that organizations are aggressively transforming to respond faster to changing market, customer and competitive demands,” said Mark Slaga, GM for IBM Cloud Managed Application Services. “To support them in their journeys, IBM is continuously innovating and adapting its cloud offerings. By combining the power of IBM Cloud Managed Application Services and IBM Cloud Private, customers will be able to benefit from a highly-secure and versatile environment for managing and modernizing apps and turning decades of data into competitive advantage.”

    Launched late last year, IBM Cloud Private is front and center of IBM’s hybrid cloud strategy. Thanks to the flexibility of container technology, it can be installed on a wide range of enterprise systems to create a private cloud with an architecture and capabilities consistent with the public IBM Cloud. IBM Cloud Private’s combination of innovation, flexibility and control is particularly important to companies in regulated industries such as finance with high standards for security and reliability.

    Coupled with CMAS’ built-in security, disaster recovery, and automated infrastructure and application management, IBM’s clients can now have a powerful combination that  helps provide the security, flexibility and speed they need to compete in the most dynamic markets.

    The solution uses the power of Kubernetes container technology to add self-service Platform-as-a-Service capabilities to IBM’s managed CMAS cloud infrastructure. In addition, IBM’s CMAS clients can benefit from faster access to IBM’s analytics, data, middleware and Watson portfolios available through the IBM Cloud Private platform.

    IBM Cloud Private running on CMAS will be fully operational by July 2018 and will be fully supported by IBM services.

    Contacts:

    Jonathan Jessop Batty
    IBM Europe
    jjbatty@ibm.com
    +44 7741 113871

    Scott Cook
    IBM US
    scotty@us.ibm.com
    +1-312-669-4743

     

  • Machine Learning: Essential in Cloud Service Management

    Machine Learning: Essential in Cloud Service Management

    As businesses today compete more and more on digital experience, you need to ensure that what’s delivered performs optimally and provides an outstanding customer experience. With increasing complexities, growth and change in your IT infrastructure, you need complete visibility into the performance and availability of IT infrastructure, and also the applications that ride on it.  To succeed in this modern domain, your IT operations team needs to be more proactive than reactive.

    Proactive operations management have long been a goal of client-centric operations: the ability to avoid issues rather than simply reacting to issues more effectively or more efficiently. It is time traditional IT service management transforms to remain relevant. The good news is that machine learning has advanced to a stage where this is achievable at scale.

    Machine learning may have been a distant dream, but not anymore. Almost every system or gadget, whether complex or simple, is getting smarter using basic pattern recognition and computational learning, which is the basis of any machine learning technology. Today, public cloud service providers offer machine learning services that make this technology affordable. So, you are not too far away from making your IT operations management more client-centric.

    Machine Learning Meets IT Service Management

    Applying cognitive and machine learning capabilities to service management will help accelerate diagnosis of events and patterns, extract deep insights from IT systems and provide early warnings of anomalies that could cause service impact or poor performance.

    Machine learning will enable your IT service management to:

    Continuously learn: Cognitive service management uses machine learning to learn the behavior of applications and resources and get a true understanding of how it should function normally. With machine learning, you can continuously learn application and infrastructure behavior and then use those insights to set and dynamically manage thresholds for all monitoring data. You can understand the relationships across applications and resources to anticipate service impacts. With these deeper insights, you can quickly and efficiently resolve issues, improve overall operational efficiency and significantly reducing operational costs.

    Anticipate and adjust: With every outage is a potential service degradation. This is exactly where machine learning capabilities help proactively detect and avoid, which traditional service management capabilities lack. Insights from recurring anomalies help forecast potential service degradations. This information is used to proactively alert on potential problems so that organizations can adjust to the rapidly changing environments and intelligently prioritize their resolution.

    Recommend action: Efficiency is critical when it comes to finding and fixing application and systems problems. A skilled service organization backed with machine learning capabilities helps provide expert advice for taking corrective action and can offer greater service assurance. Applying cognitive capabilities turn terabytes of data captured from their IT infrastructure, into relevant and actionable insights for quicker problem solving and better service.

    Because machine learning uses algorithms that can learn by observing data, identifies important patterns in your data and by clustering them, you get to focus on the most urgent issues. It enables you to automatically detect problems and separate real issues from the noise. You gain faster time to resolution for troubleshooting problems that impact service to clients.

    To learn more, join us as we present “Cloud Service Management: Why Machine Learning is Now Essential.” During this informative webinar, you’ll learn why IBM believes adaptive automation, delivered through innovative machine learning, is now essential to achieving cloud service management at scale.

    — Eric Minick

  • DevOps Chat: Trends in Cloud Service Management – ML/AI, ITSM, DevOps, ITIL & SRE w/ Sinead Glynn

    DevOps Chat: Trends in Cloud Service Management – ML/AI, ITSM, DevOps, ITIL & SRE w/ Sinead Glynn

    In this DevOps Chat, we speak with Sinead Glynn of IBM about some coming trends in Cloud Service Management, ML/AI, ITSM, DevOps, ITIL and SRE. A lot of buzzwords in there, but there is also some good information here. Sinead is a great interview.

    As usual, the streaming audio of our conversation is directly below, followed by the transcript of our conversation below that.

    Audio

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel and you’re listening to another DevOps chat, and – here on DevOps dot com. Our guest for today’s chat is Sinead Glynn, Offering Manager, IBM Operations Analytics, IBM Hybrid Cloud. Sinead, did I – did I get that right? 

    Glynn: Yes, you did, Alan. Thank you. And thank you for having me.  

    Shimel: Thank you. It’s our pleasure to have you. So Sinead, you know, IBM titles are always kind of very descriptive but why don’t you give our audience a little bit more here. What exactly is your role with IBM? What do you work on? What do you do?

    Glynn: Sure, yes. Yes, so I’m an offering manager here with IBM. Offering managers would be known as product managers in other companies. We focus on offering because it’s more – it’s more than just a technology discussion. We kind of go broader and look at the full solution.

    In terms of my own area of specialty, it’s around the operations management and the broader management capabilities from an IT perspective, so it’s your centralized IT operations teams, your DevOps teams, and the management capabilities that they need.

    In terms of the offerings I specialize in and the area I specialize in, I have a background myself in development and, in particular, the development of machine learning and cognitive technologies. So my own focus is in terms of bringing those capabilities to market and, you know, explaining how that – they benefit the IT operations teams and the DevOps teams. 

    Shimel: Great. So Sinead, you know, machine learning and its, you know, its Siamese twin, AI, seem to be on everyone’s lips these days whether we’re talking about Dev, DevOps, Ops, security, testing, or big data, or hybrid cloud, or cloud private or whatever, everyone has a story around ML, machine learning. 

    Glynn: Yep. 

    Shimel: But we’re really here today to really focus in on machine learning as it relates to cloud service management. Right? You know, I – my personal belief is that over the next five, ten years, machine learning and artificial intelligence, AI, is going to have a profound input – impact on a lot of different things that we do. But at a high level, Sinead, talk to us about, you know, what kind of impact machine learning is having on cloud service management specifically, and why it’s sort of become an essential piece of your cloud service management.  

    Glynn: Sure, yeah. So I suppose, you know, there’s two dimensions or two primary dimensions to cloud service management. There is the complexity of what you’re managing, you know, hybrid cloud was something we all talked about, you know, 12, 18 months ago that has morphed into multi-cloud. So, you know, management organizations, they’re handling their kind of traditional systems of record and they might have a number of public clouds and a number of private clouds that they’re using.

    So there’s the – there’s the complexity dimension and certainly machine learning provides the ability to manage that complexity when you don’t have the ability to suddenly grow your teams. So you can’t add people.

    But the other – the other dimension is how you manage. So it is that change in the process and the change in the culture that is required to be successful when you’re doing cloud service management. So, you know, it’s that move from, you know, months or even a year of preparation for a new application to be rolled out, it’s very much that agile versus traditional model and that, you know, DevOps stroke Lean versus your ITIL view of the world.

    So it’s enabling at the roles and it’s enabling those roles to be successful in cloud service management in terms of how you manage, not just what you manage. 

    Shimel: Fair enough. So, you know, Sinead, I – I’ve – we both have been in this – in this business for more – a couple of years. Me longer than you, probably – you’re much younger. But, you know, we’ve seen sort of the rise of – of IT service management and things like ITIL, and, you know, traditional ITSM, and they’ve kind of ruled the roost here 15 years or more, 20 years or more. Right?

    And now all of a sudden we’re seeing, you know, things like DevOps and Lean IT, and even sort of some of what we take from Agile. Right? From the Dev side of the house. You know, almost Agile for Ops if you will. And they – you know, and they’ve all been kind of chipping away at that ITSM model.

    And then most recently, of course, we’ve introduced this term of SRE, site reliability engineering. And now this, along with things like machine learning, really seem to be changing, you know, traditional ITSM at – at its core. I mean, it’s really kind of rewriting the book or – I mean, really forcing us to reexamine some of our ITSM, you know, core values and principles, ways of doing it. What do you think about that? 

    Glynn: Oh, absolutely. You know, ITSM was very much focused on – or is, it’s not a was thing. Is very much focused on operational excellence about, you know, being that gatekeeper to ensure that only high quality applications are deployed and very, very process-centric and control-centric, typical kind of waterfall type methodologies, and that was very effective before the real transition in terms of how business is running.

    So business – business must have digital engagement. Business must have agility in order to innovate, in order to keep your clients and grow your client base. And that, you know, operational excellence stroke, you know, very process-centric risk adverse way of managing just – just doesn’t work. So that’s where, in line with – in line with that digital transformation, the DevOps practices and the Agile Ops has to emerge with it.

    And, you know, from an Agile Ops perspective, that’s much more about how can technology help me be agile while still managing the risk and delivering exemplary service? How can technology help me rather than how can I be very process-centric.

    Shimel: Yep, and Sinead, though, I – you know, I almost feel compelled to caution the audience that I don’t think your saying, IBM’s saying it, I’m certainly not saying that ITSM is dead. You know, it’s more like ITSM is dead, long live ITSM. Right? And, you know, it’s just – it’s changing, it’s morphing, it’s evolving with – with, you know, new things like AI machine learning, but also with new frameworks like DevOps and Agile for Ops and Lean and so forth.

    And this kind of gets at the heart or _____ of SRE. But another fundamental, I think anyway, another fundamental shift in this is – and I’ve heard you talk about it – we – we had the pleasure of doing a video at – I think it was IBM Think a couple months ago – is the kind of the – not the changing customer but the changing kind of world view that – that we need to have over in Ops, and that is the – the, you know, the changing into a skilled service organization rather than the center of the universe. 

    Glynn: Absolutely. So, you know, it’s – it’s moving the mindset from, I’m the center of the universe, I control everything, you know, with process and controls, et cetera, to, I have to support the required agility in the business. And in order to support the required agility in the business, I need to be much more about being a skilled services organization.

    And just on the topic of, you know, is ITIL dead or, you know, it’s usually a coexistence. So, you know, we frequently see, particularly in larger organizations, you know, your traditional IT Ops remains and they need to have a – you know, they may need to have visibility and control across both the traditional and the cloud environments, whereas the software reliability engineer, they tend to service maybe a number of DevOps teams, supporting them in their agile work practices and they’re very much focused on automating rather than throwing people at it.

    So it’s very much – maybe 50 percent of the time is worked on – or spent on kind of traditional operations and 50 percent is really looking at, you know, how I can scale this better. How can I automate this better and how can I support? So it’s really that services view.

    And there is a transition, you know, there isn’t really clear lines. They might emerge over time but there is – there’s really kind of two types of organizations frequently emerging in the larger organizations and – and it’s because the larger organizations typically have been around for some time. So there’s already a tradition of that – that centralized IT operations.

    From a technology provider perspective, there’s a challenge because everyone is trying to do the same job ultimately, you know, deliver exemplary service, but because of the cultural differences and because of the skill differences, they have slightly different views in the world.

    So it’s the same thing – they’re managing but they need different views in the world. And I guess our challenge is to ensure that they – the right experience and the right insights are made available to the right types of users to do their job most effectively. But definitely there is that transition towards the site reliability engineer and their needs. 

    Shimel: Yeah, I’ve heard – I’ve heard people say that, you know, this whole SRE kind of role becomes the Ops in DevOps but, you know, in listening to the way you talk about it, Sinead, again it – it reinforces a continuing maturity sort of view of the world. You know, as a dad or as a parent, you know, every child is the center of the universe. Right? The child believes that they’re the center of the universe. And I think part of the maturation process and growing up is realizing perhaps you’re not the center of the universe. Right? But you are, you know, there’s a big world out there that you’re part of.

    And I think that kind of really – when you think about it that way, that’s – that’s the journey for Ops. Understanding they’re not the center of the universe and they’re a part of this bigger world. And – and – but they still have a – a vital role to play, a very important role to play and – and I think that SRE role is in there. 

    Glynn: Absolutely, absolutely. 

    Shimel: So, you know, we have this webinar coming up on June 21, 2018, and it – it is, you know, along the lines of cloud service management and – but it really comes from, you know, I’ve seen anyway, a – a changing view of cloud from IBM itself. And, you know, IBM’s not a small company so when their – when their world view shifts, there’s usually good reason for it. Right? And it tends – and it tends to change a lot of others’ world view as well.

    And you mentioned it rather casually earlier. You said something like, “Well, we’ve gone from an emphasis on hybrid cloud to a multi-cloud.” You know, dropped that in there. But, you know, that’s – that’s a profound – you know, that – there’s really something here. 

    Glynn: Absolutely. 

    Shimel: Talk with our audience a little bit. What do you mean by that? 

    Glynn: Absolutely. I suppose in the – in the early days, you know, there was a focus on, we have cloud. It’s fantastic. Come buy our cloud. Let me show you what our cloud can do. And I guess through many interactions and learning process, it’s obvious that, you know, no one cloud does all jobs. So it’s about picking the right tool for the right job.

    So what we see is that the complexity in the environments that are actually being chosen. So it’s a multi-cloud strategy. It’s not a, I’m going to put everything into one particular vendor, or, you know, I’m going to move all of my workloads exclusively to cloud. You know, they – it’s much more granular decision. Certain parts of the business, you know, usually the systems of record, they may be kept on existing infrastructure and continue to be managed there, whereas the systems of engagement may go to public clouds, they may go to private clouds, depending on your security and data requirements.

    What businesses are doing and what smart businesses are doing is, depending on the type of application modernization they’re driving, they’re selecting the right strategy. Which is great for business, it’s a heck of a challenge for your centralized IT operations because of that complexity. So they need machine learning and adaptive automation to help them manage that complexity, to do their more traditional roles in a much better way, particularly when there isn’t that long handover.

    You know, apps are pushed out, particularly in cloud, the scaling out of those apps on the infrastructure is, you know, highly dynamic and, you know, when you’re trying to troubleshoot things, you need to get insight. So you need to have insight and analytics and machine learning to help you understand because there hasn’t been – you know, there hasn’t been a communication that this has happened. So all of those technologies are required.

    So that’s the – the multi-clouds _____ traditional IT Ops, they, you know, the infrastructure is – is agile, there are multiple clouds that they need to be able to see, and then you have some parts of the organization, maybe growing parts doing your DevOps type practices. And they have slightly different needs. You know, the – the DevOps persona just need to see their own project or the – the applications. The SRE engineer probably services more than one DevOps team.

    So they – they have different views and we’re very much focused on ensuring that the management capabilities that we have, particularly around the machine learning and the analytics, that, you know, it’s providing those insights to help those groups do their jobs effectively. So it’s definitely multi-cloud, Alan. It’s not – it’s not hybrid. Not just hybrid. Yeah. 

    Shimel: I – I agree with you. I think that was a good explanation. While we’re doing definitions and glossary terms, let me break – throw another one at you and that’s IBM’s what you’re calling adaptive automation.

    We’ve touched on it, we spoke a little bit about it, but let’s make sure we’re clear for our audience. What do you – what do you mean by that?

    Glynn: Okay, well, I suppose traditional automation and, you know, obviously something that’s been around for 40 years, I don’t know, I think we need to go back – that’s about, you know, I know something, there’s a condition, I kick it off on and that condition happens again. Whatever you’re doing. So it’s very much a rule-based or a condition-based automation, absolutely very effective and very valuable.

    But in – in the cloud world where things are dynamic, we need to think much more about adaptive automation and there are, I suppose, different types of adaptive automation. Does the type of adaptive automation, you know, if we think about, just as an example, the types of machine learning and analytics that would do things like event grouping. So that’s, you know, looking at real-time – real-time machine learning to reduce the number of events in your environment through machine learning, et cetera, et cetera. So that’s kind of a real-time adaptive automation.

    You take it further and you can look at things like maybe proactive automation where you’re using, you know, machine learning to actually learn what is normal and – in your environment and proactively tell you when things have gone abnormal. So that’s more about being able to predict that things are going to happen rather than react elegantly to things that are happening in real time.

    And then taking it further, Alan, I mean, there’s a big push – and obviously IBM is leading this in terms of cognitive capabilities, so not just looking at machine learning on the machine data in your environment, but going beyond that and using machine learning perhaps on your human data, your knowledge corpus, and really imbuing those workflows – workflows with, you know, cognitive – to help humans make those decisions even faster.

    So there’s different levels of it. Practically, you know, folks tend to start off in that reactive way, using kind of, I suppose, automation in real time to reduce the number of events and to trigger maybe standard automations. And then it’s about moving beyond that to really start gaining the value from the machine learning. 

    Shimel: Got it. It’s a great time to be alive in Ops, isn’t it Sinead? Right? Think about – you know – 

    Glynn: I – I think so, yeah. I think so. And I know we – you know, I know some might fear things like automation and machine learning and analytics but I’m fully confident that the complexity of the environments we’re managing is rising much faster – you know, it’s getting so complicated you do need automation and machine learning to manage it. 

    Shimel: You need it. Right.

    Glynn: Yeah, so, you know, I think it is. It’s an exciting time. Yeah, skill set changes, most definitely, but, like, if you – if you look at even, say, something simple like microservices, so, you know, everything is moving to microservice architectures, as far as can tell at least, and yes, that makes the job of development much easier and much more reuse, et cetera. But the – you know, the job of Ops gets a lot harder because it’s a lot less predictable, there’s a lot more data, you know, there’s – how do you see the wood for the trees? How do you pinpoint the, you know, there’s these obscure names on things, et cetera.

    So you need insights, you need help to do the job you did, to do it much better. So, and again, it’s always about supporting that digital transformation.  

    Shimel: Sure. I mean, and it’s really necessity is the mother of invention. Right?  

    Glynn: Absolutely. 

    Shimel: No one – no one does things as much as we’d like to think, you know, no-one does things because they’re cool or, you know, just – you don’t do new for new’s sake. You do new because there’s an advantage to it and so much of what we’re seeing around machine learning and automation and these new frameworks and so forth is a response to the complexity, to the changing nature of the way we’re doing business in IT. 

    Glynn: I wholeheartedly agree. And I have personal experience of this because I’ve been doing this particular role for some time, particularly on the development side, and you know, I would say hand-on-heart, we were probably to market too early with some of this. 

    Shimel: Yeah. 

    Glynn: You know, and – you know, a few years ago it used to be an experience of, wow, that’s really cool, but I don’t need it. It really was, you know. 

    Shimel: Exactly. Right. 

    Glynn: And it was, you know, quite surprising, particularly because I – myself, at the time, I was in development so I was very, why – why do you not see this? It’s like, what’s wrong – but you’re right. 

    [Crosstalk] 

    Shimel: Well, and it is so cool. Right? 

    Glynn: Exactly. It’s very cool, but not needed. 

    Shimel: So that was, like, you know, that was something else that – Sinead, I learned early on, I – you know, my history is I’ve done a number of venture-backed startups in technology over the last 25 plus years and, you know, a hard lesson that I think every entrepreneur learns is you are never going to be successful selling something that’s nice to have. Like, no-one buys things that are nice to have. They look at things and say, wow, that is cool. It’s nice to have. 

    Glynn: Yep. 

    Shimel: But they don’t write checks until it’s a must-have. 

    Glynn: Exactly. 

    Shimel: And – and that’s really the key. Sinead, we’re almost out of time, here. We’re probably over time already, but before we go, I want you to just give our listeners a place to go. They’ve heard – they’ve heard kind of a little bit about what you’re doing and what IBM is doing around this. Where can they find out more? Where can they engage with your team and – and, you know, start living this and doing – you know, they’re probably all – many of our listeners are faced with this very reality. How can they engage with IBM on this stuff? 

    Glynn: Absolutely. Well, just from a – I suppose from a Google-search perspective, there’s an IT Operations Analytics page. So if folks do a search on that, you’ll be brought in, and folks can reach out to me, of course, as well. We’ve an IT operations management page as well. For me, I – you know, it’s very hard to separate one from the other because we’re moving more and more towards that, you know, that AI-driven operations. That’s becoming essential – not a nice bolt-on to have and – on your operations management.

    So certainly that’s the place. Again, if you go to IBM Marketplace and you look for IBM Operations Analytics you’ll find the details of the machine learning technologies around the, you know, the events and the performance that I’ve mentioned, and indeed, you know, the cognitive stuff.

    But probably just to reach out to me, Alan, is a good start. And I can certainly point them in the right direction. 

    Shimel: Great. Okay, so let me ask the magic question. How do they reach out to you? 

    Sineed:Certainly. Well, my e-mail address is Sinead.Glynn@ie.IBM.com. 

    Shimel: And that is S-I-N-E-A-D dot Glynn G-L-Y-N-N at IE dot IBM dot com. 

    Glynn: That’s me.

    Shimel: Got it. Sinead – Sinead, thank you so much for – for being our guest here today. I know I told you it was just 15 minutes and we – we’re probably double that. But I think it was a worthwhile conversation and I’m sure our audience will find it very interesting. 

    Glynn: Okay. 

    Shimel: Our webinar on this, by the way, devopsy.kinsta.cloud webinar sponsored by IBM is on June 21, 2018, at 1 p.m. Eastern – it’s actually Eastern Daylight Time, not Eastern Standard Time. Right? Because we’re in daylight saving time. And 1 p.m. East Coast time.

    So you can log on from wherever. If you go to DevOps dot com and under webinars, you could register for the webinar there. We’ll – we’ll have a link for it in our notes.

    Sinead, thanks for appearing. Hope to have you – you know, the webinar I’m sure is going to be great but maybe we can continue this chat another time on another DevOps Chat. 

    Glynn: Certainly, certainly, Alan. And thank you. It’s always a pleasure. 

    Shimel: Thank you. All right, this is Alan Shimel for DevOps dot com, DevOps Chat. You’ve just listened to another chat. Have a great day everyone.

    — Alan Shimel

  • CA, IBM Partner to Drive DevOps on the Mainframe

    CA, IBM Partner to Drive DevOps on the Mainframe

    CA Technologies and IBM announced today at the Built to Change Summit they are combining their tools and platforms to bring DevOps process to mainframe environments.

    The two companies are extending their existing relationship to include a partnership to jointly develop and sell new services for IBM’s Cloud Managed Services on z Systems (zCloud). Included in that effort is CA Brightside, a platform for bringing DevOps processes to mainframes using existing open source tools and frameworks such as Jenkins, Gradle and IntelliJ via a command line interface and CA Mainframe Resource Intelligence, a software-as-a-service (SaaS) application for monitoring consumption of mainframe resources.

    Other managed services will be based on CA Service Virtualization software for rapidly testing and modifying applications in place; CA Mainframe Operational Intelligence to monitor applications; and CA Data Content Discovery to find, classify and protect data.

    The services are available today to all IBM Managed Cloud Services for z Systems clients in North America and will then be rolled out globally throughout the rest of 2018.

    Greg Lotko, general manager for mainframe at CA Technologies, said that although CA Technologies competes with IBM when it comes mainframe software, it has a vested interest in making sure mainframes stay relevant at a time when organizations are looking to replace less agile forms of application development that use waterfall and ITIL processes with DevOps methodologies that speed application development. From a practical perspective, end customers are demanding that CA Technologies and IBM work more closely together, he said.

    Barry Becker, vice president of hybrid cloud services for IBM, added that as the line between mainframes and distributed applications continues to blur, it’s clear organizations want to be able to treat mainframes as back-end platforms that make a wide variety of enterprise data available to those applications. That need is driving many those organizations to extend DevOps processes to mainframes.

    Historically, competition for control over application workloads within internal IT organizations between mainframe advocates and proponents of distributed computing  has tended to be fierce. But Becker said that as digital business transformation gains traction, there’s now a greater appreciation for the need to leverage transaction processing and big data applications that are widely deployed on mainframes. Not only is it not practical to rewrite all those applications, he noted, applications running on mainframes are more secure. The creates the need to extend out to the mainframe the DevOps processes that are being used to build distributed applications, he said.

    Zealotry that tends to focus on the merits of one platform above all others is usually counterproductive. The rise of DevOps presents organizations with an opportunity to bridge a divide within their organizations that, in some cases, is decades old. Of course, mainframe proponents are not likely to abandon waterfall and IT methodologies overnight. But DevOps processes can mainframe environments a lot more agile at a time when senior business and IT leaders are now judging the merits of one platform versus another increasingly on how flexible it allows the business to become.

    — Mike Vizard

  • DevOps Chat: Modern Apps in DevOps w/ Andrea Martinez Crawford, IBM

    DevOps Chat: Modern Apps in DevOps w/ Andrea Martinez Crawford, IBM

    Andrea Martinez, now Andrea Crawford, is the CTO for DevOps for IBM Hybrid Cloud. In this DevOps Chat we had a great discussion on what is “modern apps in DevOps,” how to upgrade your legacy apps, what to do if your legacy apps are not upgradeable and what this all means for DevOps.

    Great discussion and as usual, the streaming media audio of our conversation is immediately below, followed by a transcript of our conversation.

    Alan Shimel: Hey everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. DevOps Chat today is going to be a good one. We have with us Andrea C. Martinez who is the CTO for DevOps for IBM’s hybrid cloud.

    Andrea, welcome to DevOps Chat.

    Andrea Martinez: Hey, thanks for having me, Alan.

    Shimel: Thank you. Did I get that all right?

    Martinez: So, I’m mostly known as Andrea C. Martinez but I’ve recently gotten married so my new last name is Andrea Crawford. Different last name but the same cowboy hat. So I always wear my cowboy hat in my profile pics. If you’ve got the hat you’ve got the right gal.

    Shimel: And it’s the right Andrea. Okay. No hyphen – Martinez-Crawford or something like that?

    Martinez: Nah, I’m not that fancy. It’s just Crawford.

    Shimel: I’ve got to tell you I just got back from China last week and I was with my partner Jayne Groll, one of the co-founders of the DevOps Institute, and one of my co-founders there, Jayne Groll, is actually now Jayne Groll-Ray because she’s also recently married and what a mess on the – hats off to you – getting your passports done and redone and what name to use because you know it has to match exactly and all your other IDs – I didn’t realize what a –

    Martinez: Alan, that’s why we get the diamonds in our ring.

    Shimel: I guess so. Yeah, and well-deserved. Anyway, congratulations on your recent marriage but we’re going to talk DevOps and we’re going to talk a little bit about modern applications here today, okay?

    Martinez: Awesome. Sounds good.

    Shimel: Great. All right. So I should mention that we have a webinar coming up on June 28 at 1 p.m. Eastern time on this topic and really this chat is just sort of a lead-in to the full hour-long webinar and that webinar is on DevOps for application modernization and we’ll put the link to it in our show notes here but if you find what we’re talking about today interesting by all means check out the webinar.

    But let’s dive in. So Andrea, let’s talk a little bit about modern applications versus non-modern applications: Do we have archaic applications, are they obsolete applications? What do we mean when we say a modern application?

    Martinez: Yeah, I think to – and by the way, I like your archaic reference there. I think to really appreciate the modern application we really have to understand how applications use to be designed and built not all that long ago.

    So, if I were to go back to the N-1 generation of applications I could make some pretty broad characterizations of how they were designed, built and delivered. So, if we were to like take it back to around the late-Clinton era of post-dot.com boom, world wide web and the internet, you know, that was really becoming the network platform where enterprises were exposing business function and really more of nascent digital economy.

    So some of the characteristics of what I’ll call “heritage applications” were, No. 1, they were monolithic so the applications lived on these things called “application servers,” typically running on maybe like higher end commodity infrastructure – think like X86, power hardware with large amounts of disk and memory, we had big centralized databases and these memory hog application servers.

    So the applications ran inside these app servers and they were fairly monolithic – that means they basically bundled the presentation or the view, the business logic and the data model components all together.

    The second characterization I would say for heritage applications is that they lived on these app servers that resided on these sort of heavyweight operating systems and although at the time Linux was very much on the scene overall. The trust in Linux was not yet solidified so you had these operating systems that were sort of these enterprise, server, big and bold editions of this OS – and it was pretty prevalent, you know? Windows and proprietary Unix based operating systems pretty much ruled the day.

    And, No. 3, the – in terms of the infrastructure on-premises data centers ruled the roost. I mean virtualization technology’s around, we had this notion of logical partitions, L-pars, VMware, virtualization, but it was mostly a hardware OS story, okay?

    And then we had, in terms of looking at the actual heritage applications themselves, we had the rise and dominance of function-rich languages like Java and dot-net because the application server middleware pretty much dictated the language of what an application was coded in, right? So we still have a lot of these skills around today.

    And I think the last characterization of a heritage app was in the way that they were delivered. So we had the waterfall delivery – very sequential, big-bang releases with siloed organizations, dev teams didn’t really talk to the operations teams and having that kind of silo was pretty much the norm.

    So, that’s how I would sort of characterize the heritage applications.

    Shimel: Yeah, dead on for me Andrea. We didn’t talk about this but in my background I had started a web hosting company in those dot-com days and I sold it to a company and started to work with them and we were one of the first big, what they called ASPs, if you remember those days – application service provider – and so this is – we wound up doing the whole IPO and all of that – this is 1997, ’98, ’99, 2000, into 2001 –

    Martinez: Absolutely. Yep.

    Shimel: Oh, they were glory days. We were probably one of the largest Lotus notes, if you – you know,

    Martinez: Yeah, all right.

    Shimel: So, picture this: We’re hosting – we are offering hosted Lotus notes as a service – it’s not even IBM WebSphere yet, I think it was still notes server –

    Martinez: Domino?

    Shimel: No, it wasn’t even Domino. What came before Domino? I mean this is old. And then Domino came out and it kind of rocked our world because it was really a big thing for us. But there’s no – it was on dedicated hardware, there was no cloud, T1 lines were about $1,200 a month, and so you had to deliver it over a T1 line oftentimes – you know, a dedicated T1 line point to point – and then we expanded to PeopleSoft and Oracle apps and stuff like that, and what a disaster. I’ve got to be honest. I mean we went through about $500 million – a half-a-billion dollars in monies raised between the IPO and so forth – but it was hard. It was really, really hard.

    And then we tried to get into the whole custom app kind of hosting with ISVs and so forth.

    Martinez: Oh boy.

    Shimel: So, what you just described I had a déjà vu to my bones and, yeah, I wouldn’t call those modern applications but I think we’ve done a good job.

    Now contrast that, though, with what modern applications are like today, Andrea.

    Martinez: Yeah. So there’s sort of been an inflection point where some pretty emergent things have happened since those days, right? And you know we dealt with all of those issues around the heritage environments and applications. And now all of the sudden if we take a look at what I call “modern applications” today – Alan, you mentioned the cloud – No. 1, modern applications live in the cloud. So these applications leverage the elastic, infrastructure and platform that comes with it.

    When we develop modern applications – you also may have heard them referred to as “cloud-native applications” or “born-on-the-cloud applications” – and really what has happened here is to leverage that type of virtualized infrastructure we’ve started to breakdown the monolith and the applications that run on them.

    So, now we’re taking our bundled model-view controller applications and frameworks and we’re deploying them separately as components and hopefully we’re using architectural styles like microservices so that the monolith becomes broken down into choreographed microservices that can be managed separately, okay?

    So, we have technologies that actually support this today. And so Docker, Kubernetes are some of the technologies that have come on the scene since that have allowed us to have a control plane and an environment to manage smaller-granularity applications which are hopefully services.

    So, the other thing about modern applications that I think is interesting and has fostered the adoption of these microservices and smaller components is the fact that the solution stack has become more and more commoditized, right? And so, when you think about the solution stack of network hardware, operating system, middleware layer and so on, we’re seeing a commoditization of the solutions stack from the bottom up, okay? And that is – the whole notion of cloud computing, right? – We’re no longer concerned so much about CPUs and CPU architecture, you know, X86 versus Power P Series, this or that – it sort of doesn’t matter as much anymore, right?

    And because of that, I think that has also fostered in some cases where critical proprietary software was not necessarily needed for enterprise applications. And so, when you start to break down the monolith and deploy smaller services, you’re isolating your risk because you’re isolating business functions and smaller chunks that are lighter-weight and it’s really analogous to the difference between deploying a 10-ton gorilla and deploying a colony of ants. If one ant dies it’s not a big deal, right?

    But commoditization has even spread to the way that these little ants or microservices talk to each other with the advent of API interfaces and as long as you use rest APIs over HTTP or a lightweight messaging protocol that’s pretty much the lingua franca of modern applications today.

    So, I think there’s probably this notion of componentization and that is actually fed into the notion of polyglot programming, and so enabling modern apps to be programmed in just about any language. So, you’re no longer bounded to this big, proprietary application server; you can program in just about any language, and as long as you can talk – rest over HTTP or send an A-synch message over a lightweight message hub – it sort of doesn’t matter.

    You know, you can be a Java or a dot-net bigot but, hey, the new guy who knows Python and is really good at it, he can get in on the action, too. It’s all good.

    Shimel: Absolutely. So, Andrea a lot of what you – you know, it was more than a mouthful there – and a lot of what you’re talking about really describes DevOps, right? This idea of chunking down stuff so it’s not the monolith, right, and doing small – you know, lots of smaller, little things rather than one large, bigger thing and learning and feedback looping and all of that – I mean this is – it’s DevOps 101, right?

    And to me – and this is – you know, I speak to a lot of people obviously around the world about this stuff – but to me there’s a chicken-and-egg relationship between DevOps and modern application infrastructure, development and deployment as you’ve described. I don’t know if you could have one without the other. I just don’t know which one comes first. But they’re intrinsically linked, right?

    And this is why, in my mind anyway, we need – you know, there’s a special relationship, if you will, between DevOps and modern application and how we do modern applications today.

    Martinez: Spot on, Alan. I mean, when you think about the gorilla versus colony of ants analogy. Think about having to deploy the 10-ton gorilla – it’s typically pretty complicated but there’s a lot of dependencies and release management is of utmost concern – but deploying the colony of ants you’re deploying a lot of little things at different times – so you’re achieving the multispeed IT – if you don’t have DevOps, if you don’t have that kind of automation to do the build, compile, package, test, deploy and you’re doing it intra daily – if you don’t have that automated then your cost case is going to fly out the window.

    DevOps is essential for modern applications. Period.

    Shimel: Dead on. Dead on. Amen. You know, you’re preaching to the choir here, Andrea – we’re devopsy.kinsta.cloud – but it really is essential and there is this sort of hand-in-glove type of relationship.

    We are, as I promised you when we started – the time goes so quickly and there’s more I want to cover. So we talk about how DevOps fits into the story on the how and why of modern applications.

    You know IBM has this history now – and as I mentioned to you four or four-and-a-half years ago when I launched devopsy.kinsta.cloud IBM was one of the leading advocates for what was kind of the rise of the DevOps community and culture. And then you guys had the garage method, which was really kind of intrinsically again all about DevOps and DevOps ways, if you will – how does all of that fit in to modernizing applications and the way we’re doing it now?

    Martinez: So the IBM cloud garage method is IBM’s opinionated view on how to deliver especially modern applications: It combines Agile, DevOps, Lean and our enterprise-design thinking and sort of rolls it all up into this wonderful burrito of reference architectures, practices and techniques – you know, it’s lunchtime, so I’ve got food on the mind – but it’s basically a way to help our clients act like a startup so that they can achieve the kind of agility that they need.

    So, DevOps is also about organizational and behavioral changes because that’s really paramount. At the heart of our method is culture – how to organize our teams, the collaborative practices, social coding, pair programming – breaking down the silos, right – that’s what DevOps is all about, having product owners sit with the squads, right? – sit with them. You know, DevOps is a behavior story – a tool automation story – and it’s all in the name of enabling business agility.

    Shimel: Absolutely. Andrea, I’ve got another final area I want to click on if you don’t mind. And that is for our folks listening out here – and it’s a worldwide audience at devopsy.kinsta.cloud – and I’ve traveled the world doing this, and though we all want to do DevOps we move at different speeds and we’re at different stages of our journey.

    What advice, if we can kind of give blanket advice – what advice around DevOps would you give to our listeners who – and again, Andrea, this is something you’ve probably learned, right? – I wish we all had a greenfield to play in, but we don’t, right? We have brownfields and there’s heritage apps, as you call them, and there’s modern apps, there’s old and new, fat and skinny, ants and gorillas – even burritos – what advice can you give our listeners on how to deal with all of these things?

    Martinez: I think just recognizing that you may have to approach DevOps a little bit differently depending upon whether you’re modern or heritage or even somewhere in-between. Typically DevOps for heritage applications, you’re retrofitting automation in situ, right? So, you’re sort of bringing the automation to the app. Whereas for modern applications, you definitely want to have a DevOps Day One approach, right?

    Because the ability to create a cloud-native application and have the automation in your mind right on day one is critical. But just know that you may have instances where you may not be able to bring a heritage application all the way to modern – you might be somewhere in between Fred Flintstone and George Jetson, right?

    Shimel: Two of my favorites.

    Martinez: But that’s okay, right? I mean that’s real-world. Because it may not be cost-effective to automate everything but that’s all right, you know?

    So I think we can engineer our way through some of this – and there are products out there – you know, you mentioned before that hybrid cloud was really sort of the area that I was focused in terms of DevOps – and we have proprietary products, open source products, we have our Urban Code Deploy, our IBM Cloud Private – that really sort of helps bridge the gap between applications living in this cloud or that cloud – whether they’re modern or heritage there is an answer.

    It’s not cookie-cutter, but we have the piece parts and the emerging technologies on the scene to help navigate.

    Shimel: Yep. Excellent. So Andrea that is important for people to know but where do we go – where can people go to find out more about this?

    Martinez: So I think the first place I would point them to is the IBM Cloud Garage method website – and I’m sure we’ll be providing links as part of the podcast references – but at that site you can definitely find reference architectures for DevOps, reference architectures for microservices in cloud-native development – and one of my favorites – the practices and techniques that we employ with our garage method for automation, tooling and social collaboration throughout the software delivery life cycle.

    Shimel: Perfect. So, Andrea, as I mentioned, the time here it goes so quick. It was delightful, refreshing and fantastic having you as a guest here. I’d love to have you – you know, where else are we going to learn about gorillas, ants and everything else? I need to have you back on the show. We’ll talk off-mic about it, but if it’s not too much – and we’re Florida neighbors – so I’d love to have you back here. But we’re going to wrap it up for this episode of DevOps Chat.

    Andrea Martinez-Crawford, welcome and thank you for being our guest on DevOps Chat today. We will have links to a lot of what you’re speaking about in our show notes, so folks, please take a look at that. But for now, we’re going to call it a wrap on this episode of DevOps Chat.

    You’ve just listened to another DevOps Chat and hope to see you soon everyone. Have a great day. Bye-bye.

    — Alan Shimel

  • ADDI Addresses the Problem of Dependency Management

    ADDI Addresses the Problem of Dependency Management

    Want to know what a bad day looks like? Imagine you’re a developer working your way up the career ladder. One day your manager comes by your cube to tell you that you’ve been assigned to implement a critical, new feature in the company’s premiere application. You’re elated. At last you get to show off your coding mettle.

    You spend the next two weeks working day and night to get the feature out. Finally, it’s time for release. You send out a pull request to merge your code into the codebase. Everything should be peachy. You can taste the stardom at hand. The next thing you know, your inbox starts to fill with emails complaining that your new code has broken the build. Turns out that the third-party libraries your code uses are older versions that have long since been deprecated. The code that works fine on your local system is causing havoc in the general codebase. Everything is going haywire. What should have been your hour of glory has turned into an episode of embarrassment and shame.

    You Have Entered Dependency Hell

    Anybody who has been coding for any amount of time has been in dependency hell. Those of us who programmed in early versions of Windows called it DLL Hell. Java developers have been burned by third-party .jar files that just don’t jibe as code moves down the release cycle. To this day, there is a legion of Python developers out there who are still struggling with the challenges of getting Python 2.7 code to work in newer Python 3 environments. Node developers face ongoing issues transitioning legacy code from ECMA 5 to ECMA 6. Dependency mismatch issues have been a problem throughout the history of software development. Mainframe developers have been blindsided by unknown dependencies since early batch jobs were run under JCL. Dependency mismatches are real and they hurt, sometimes too much.

    So, What’s to Be Done?

    The software industry has not been asleep at the wheel when it comes to solving the problem of dependency management. In fact, making dependency management easier—degrading it from likes of extreme dental pain to an addressable issue akin to an annoying muscle ache—has been a mostly successful undertaking.

    One of the early goals of the .NET framework was to do away with DLL Hell. (DLL Hell is a corruption condition in DLL dependency referencing caused when COM objects declared in the Windows Registry are out of sync with the calling code.) .NET avoids the Registry altogether and references DLLs directly using the file system or the more easy-to-manage Global Assembly Cache (GAC).

    Maven, a very popular Apache Project, brings a significant degree of order to dependency management for Java developers. Maven’s Project Object Model (POM) allows developers to declare exactly which version of .jar files their code needs to use. (See Figure 1.)

    maven-pom-01

    Figure 1: The Maven Framework for Java development allows projects to declare dependency versions

    Babel allows Node developers to move between ECMA 6 and ECMA 5. 2to3 is a program that will convert code written in Python 2 to version 3.

    Clearly, most programmers have confronted the issue of dependency management when developing new code. And, the industry has been active trying to lessen the burden of dependency management when introducing new code into an existing codebase. But addressing ways to management code dependency is not confined to PC-based computing; the mainframe community is actively addressing the issue, too.

    Which Brings Us to Mainframes

    The fact that code quality degrades of over time is not so much due to incompetent programming but rather the demands of continuous revision and the fast fixes put in place to meet the requirements of the moment. Sometimes down-and-dirty code that works today is preferable to more elegant approaches that will take months to implement.

    In the mainframe world, there can be decades’ worth of these type of fast fixes in play. Trying to improve code can be a roll of the dice. Usually what gets broken is a dependency well beyond the immediate scope of programming activity. As mentioned earlier, dependency management has always been difficult. That’s the bad news. The good news is that the mainframe community is keenly aware of the problem dependency management and has done something about it. IBM’s solution, System Z’s Application Discovery and Delivery Intelligence (ADDI), is particularly adept at addressing the issue.

    ADDI is a big product with a lot of features. One of the more interesting features is the Analysis Browser, which allows a mainframe developer to get a detailed understanding of all the dependencies in a particular application.

    Analysis Browser

    Figure 2: IBM Z ADDI Analysis Browser allows developers to visually understand code dependencies and program accordingly.

    Having a clear, visual picture of all the dependencies in mainframe application is a very big deal. Mainframe code is by nature onerous. There are a lot of parts that are hidden due to the immensity of the technology. Using human intelligence to try to figure out all the dependencies in force takes too much time. Hence, a tool such as Analysis Browser is indispensable when it comes to addressing the age-old problem of dependency management.

    We’re All in This Together

    In the past, identifying dependency problems usually resulted in someone getting woken at 3 a.m. to fix a mission-critical problem. Using a proactive tool such as ADDI’s Analysis Browser allows more people to get a lot more sleep. Comprehensive dependency management does not need to be the result of ongoing catastrophes in production; rather, quite the opposite.

    The first step to reducing the risks and calamities caused by dependency misalignments in code is to make a commitment to address the problem. The world of software development is littered with teams who just want to get through the current release and are more than happy to repeat the insanity dependency hell all over again in the next one. The excuses vary from, “We don’t have the time to do a solution,” to, “It may not be the best way to do it, but I’ll always have a job.”

    Once a commitment is made, then it’s a matter for tools and process. You use the tools to determine risky dependencies. You follow process to improve the release.

    Whether you’re in a distributed shop that embraces ephemeral, on-demand provisioning or a more mature mainframe shop working with Big Iron, the fact is that reliable dependency management is critical for the well-being of the enterprise. Yes, while it’s true that the details of coding and code management will vary from an IBM Z to an AWS cloud instance, the underlying thinking that brings good dependency management together is strikingly similar. As just mentioned, it’s a matter of tools and processes.

    In terms of implementing ways of dependency management that work, we might be speaking different languages. But, when you take a close look at the basic concepts behind effective dependency management, you’ll find we’re all saying the same thing.

    — Bob Reselman

  • IBM Unfurls Cloud Platform for Building Microservices

    IBM Unfurls Cloud Platform for Building Microservices

    IBM has unveiled a new development environment in the cloud designed to make it easier to build microservices.

    John Duimovich, IBM CTO for Java, said Microclimate provides a complete framework building applications based on microservices written in Java, Node.js or Swift.

    Microclimate runs on an instance of IBM Cloud Private, a private cloud based on Docker containers that is hosted on the IBM public cloud. Once those applications are developed, organizations can either deploy them on-premises or in a public cloud of their choice.

    Microclimate makes use of Kubernetes and Docker containers to create and orchestrate the microservices development process, which can quickly become a complex endeavor. Because of the issue, Duimovich said, more organizations will be pushing development of microservices into cloud computing environments that provide access to what amounts to a turnkey application development pipeline.

    Duimovich noted it’s possible to more closely mirror the production environment an application will be deployed on using compute resources that can be invoked on demand. Instead of developing an application on a laptop, developers can stress test microservices in the cloud by, for example, engage in “chaos monkey” testing, wherein developers allow a microservice to fail to see how the overall application reroutes requests to other microservices, said Duimovich.

    Developers also can engage in A/B testing in a way that would not be economically feasible to engage in when applications are developed on-premises simply because of the amount of additional IT infrastructure that would have to acquired and provisioned, said Duimovich.

    The cloud also makes it easier for teams of developers to collaborate on the development of microservices-based applications regardless of geographic location, Duimovich added. Developers may still choose to write code on their local PC, but when it comes time to load it into an application, the Microclimate platform makes it easier for everyone on the team to observe how that microservice behaves within the context of a larger application.

    IBM will also make available diagnostics tools to enable developers to more easily discover why their applications might be behaving in a certain way.

    While not every application may lend itself to being constructed using microservices, many organizations are now concluding they are simply a better way to develop reliable software. In addition, developers can be given ownership of specific sets of microservices end to end, which not only gives them more control but also makes them accountable for their overall quality. Of course, building applications made up of hundreds of microservices is going to require organization to implement DevOps best practices, which Duimovich said IBM is more than willing to share with customers.

    No one knows for sure when most applications running in a production environment will be made mainly of microservices. But given the rate at which they are now being used to develop applications, it’s now only a matter of time before such applications become dominant.

    — Mike Vizard