devopsy.kinsta.cloud

Tag: ibm

  • IBM Advances DevOps for AI Applications

    IBM Advances DevOps for AI Applications

    IBM today made its first foray into applying DevOps methodologies to building artificial intelligence (AI) applications. Announced at the IBM Think 2018 conference, the latest IBM tools and services for building AI applications include a Deep Learning as a Service capability that has been embedded with IBM Watson Studio development tools and Watson Data Kits that come prepopulated with data for specific vertical industries.

    IBM also announced it has extended its alliance with Apple to combine IBM Watson machine learning with Apple Core ML to make it easier to build AI applications employing machine learning algorithms developed and curated by both companies.

    Finally, IBM announced IBM Watson Assistant, a voice-enabled digital assistant that can be embedded into enterprise applications.

    Ruchir Puri, chief architect for IBM Watson, said IBM is delivering a combination of services and tools that collectively will create a set of DevOps processes for managing the both the development of AI models and managing the complex data pipelines that need to be created to feed data into those models.

    The IBM Deep Learning as Service offering is essentially a managed service that provides developers with access to hundreds of AI models based on neural networks that IBM has developed. IBM also revealed that the core technology employed to create the Deep Learning Service will be made available as an open source project called Fabric for Deep Learning (FfDL).

    IBM also announced an open source Model Asset eXchange (MAX) online service, through which developers can discover free machine learning models, and the Center for Open Source Data and AI Technologies (CODAIT), which expands the mission of its Spark Technology Center to include building such models.

    Puri noted that via all these offerings and services, IBM is moving to substantially lower the barrier of entry for building AI applications. Longer term, IBM also plans to make use of event-driven architectures enabled by serverless computing frameworks to make such models available on demand, he said.

    Puri added that AI models require DevOps processes because, over time, organizations will find a need to either update or change the models as new data becomes available. In addition, AI is giving rise to a DataOps discipline for managing data pipelines that needs to become integrated with a comprehensive approach to DevOps, he said.

    Puri said IBM expects AI models soon will be infused into every application being built or legacy application that needs to be updated. Given the scale of the task at hand, organizations will need to consider carefully how internal and external data flows into the models, which require continual access to data to learn. At the same time, organizations also will need to focus on ensuring the quality of that data to prevent machine learning algorithms from coming to the wrong conclusions.

    Adoption of DevOps processes has been spotty so far. But as organizations begin to incorporate AI into their applications, many will discover it’s simply not feasible to implement AI without a robust set of DevOps processes in place to support the models.

    — Mike Vizard

  • Mainframe Computing and the API Economy

    Mainframe Computing and the API Economy

    The API economy has come a long way since the days when I worked at a very well-known automotive website back in 2007. Back then, APIs were the thing that application programmers used at a very low level. Programming using web-based APIs was a rarity. In those days, we downloaded libraries into our local codebase and programmed against those binaries. I was programming in Java at the time, so the general practice was to use an application management framework such as Maven to get .jar files from the internet and incorporate those .jars into my code.

    Yes, there were technologies such as RPC that allowed us to access functions running on other machines directly and there were shops that used the technique extensively, but in my little corner of the world we accessed services directly through in-memory binaries. Also, we—the automotive website—published our data as HTML in web pages.

    Then something happened around 2010. It turns out that other developers outside the company wanted to use our automotive data. In fact, a lot of developers wanted that data. My employer saw the writing on the wall. Within a year, we were publishing an API that provided all the information we had on just about every car sold in the United States. We were in the API Economy big time!

    It was a transformational undertaking. It was also incredibly taxing. The company had to alter a lot of its development processes to meet the demands API publishing. Not only did we need to support publishing the data under XML and JSON, we also had to put in a security layer to make sure only those developers who were entitled to use the API had access. And, we had to provide comprehensive documentation that provided the support necessary so that a developer could use the API to full efficiency. The work beneath the surface of the API to keep data flowing and current was even more daunting. And, this was only for V1. We had yet to develop any sort of road map that described future versions.

    Was it hard work? Yes. Was it worth it? Yes. We were at the forefront of the API Economy. Moving our data out of HTML and into machine-readable formats such as XML and JSON provided a lot of commercial value, to the company and to other developers. It was a game-changer then. It’s game-changing now.

    The good news is that technologies have emerged that make API publishing easy compared to those early days. Today, most of the major players in the technology landscape realize that to stay commercially viable, they need to represent their services as robust APIs in a way that is easy to publish and easy to consume at web-scale. This is particularly true in the realm of mainframe computing.

    IBM Z Systems: A Significant Player in the API Economy

    There’s a lot of mainframe technology in force in the world today. A very large number of banks, financial services, governments and large-scale transportation entities have major mainframe installations. Many of these installations are IBM Z Systems. IBM is major force in this landscape—always was, always will be. With a workforce of more than 300,000 people, how can it be otherwise?

    One of the things that IBM has been very good at doing is devising technologies that allow services that reside in their Z System installations to be exposed as APIs. The way they do this is using a technology called z/OS Connect EE. z/OS Connect allows developers to expose Z System applications as APIs accessed via HTTP (See Figure 1.)

    Figure 1: z/OS Connect EE serves as the intermediary between an HTTP based API and a IBM Z mainframe

    Developers create an API using the z/OS Connect EE API Editor. The API Editor is an Eclipse-based IDE that allows developers to define the endpoint URLs for an API. (See Figure 2, below.)

    Figure 2: The z/Connect EE API Editor allows developer to define the HTTP methods and associated endpoints to that make up an API

    Then, once the endpoints are defined and HTTP methods (e.g., GET, PUT, POST and DELETE) are bound to services that reside in the Z System installation. (See Figure 3.). Each service maps to an application, such as a transaction in CICS, IMS, DB2, etc.

    Figure 3: z/OS Connect EE provides a way to directly bind an HTTP request to mainframe resources

    Not only does the z/Connect allow developers to represent services in a Z System as fully functional APIs, but it also has a feature that exports API definition as fully compliant Open API specifications.

    This is a big deal.

    Open API is one of the three most prominent API specification formats in use today. (The other two are RAML and API Blueprint.) A developer can use the Swagger specification that z/OS Connect generates to create interactive documentation for use by third-party developers. (See, Figure 4.)

    Figure 4: z/OS Connect EE has the ability to generate an API specification in Open API format that can be used to create interactive, online documentation automatically

    Again, this is a very big deal. One of the key factors for publishing a successful API is to provide comprehensive documentation. An API that is poorly documented rarely becomes a hit in the API Economy. The more comprehensive an API’s documentation is, the more widely used it will be.

    z/OS Connector EE + Eclipse = A marriage made in heaven

    I am a big supporter of using tools to reduce the labor of working with complex technologies, particularly with something as broad and multi-faceted as mainframe computing. The z/OS Connect EE API Editor fits the bill. It’s embedded within the Eclipse IDE. If you know how to use Eclipse to make a Java program, you’ll find using z/OS Connect EE API Editor to create Z System API to be an inviting experience. Yes, you might have to spend some time get up to speed on mainframe technologies such as CICS and COBOL. But, the good news is you won’t have to learn a new programming environment to do it. Just think of the API Editor as Eclipse wrapped around z/OS Connect EE and the IBM Z System computing environment.

    This 10 minute video does a really good job demonstrating how to use the Eclipse based z/OS Connect EE API Editor to create a full blown REST API using services provided by a IBM Z System mainframe. It’s pretty amazing.

    Once an API is published from a z/OS system, it can be used internally or exposed for public consumption. Representing Z System services as an API – is a significant step toward making mainframe technology a first-class contributor to the API Economy. In the API Economy, consumers care little for the underlying technology. What matters is the service. It’s striking in a way: What may look like a cloud-based API on the outside is really an IBM Z System underneath the covers.

    The API Economy Moving Forward

    The API Economy has come a long way since those first days almost 10 years ago when we wrote our first GET /make/mode/year request at the automotive website. The days of hard-coding routes and manually creating documentation have come to an end. Good riddance. To be honest, that type of development was not only a waste of labor, it also was questionable programming.

    Today, modern tools such as z/OS Connect EE API Editor allow developers to focus on the challenges of designing APIs that make a difference. The focus on design is critical, particularly as we move into the era of the internet of things (IoT). In the not too distant future, most API activity will be conducted between machines—small devices, many pushing the boundaries of miniaturization, talking among themselves and to other larger systems. The volume of data these devices will create will be well beyond today’s norms. Interestingly enough, mainframe technology is geared to handle this extreme volume of data.

    Mainframe technology will play a major role in the IoT ecosystem and the API Economy. If I were a gambling man and I wanted to position myself to be in the right place at the right time as the API Economy evolves, I would place a significant bet on getting involved in Z System development now. Technologies such as z/OS Connect EE and its API Editor open the doors to many lucrative opportunities. It’s up to us to make the decision to walk through them.

    — Bob Reselman

  • IBM Looks Toward Cloud Unification

    IBM Looks Toward Cloud Unification

    Now that IBM is achieving some critical mass in the cloud, the next major focus will be unifying the management of disparate cloud services.

    IBM recently reported revenue of $79.1 billion for its most recent fiscal year, a decline of 1 percent year over year. But within that revenue mix, Big Blue also reported that cloud revenue now accounts for $17 billion, an increase of 24 percent year over year. All told, cloud services now accounts for 21 percent of IBM’s revenues, and the company’s “as-a-service” annual exit run rate was $10.3 billion, up 24 percent year over year. Those revenues include $9.3 billion delivered as a service and $7.8 billion for hardware, software and services.

    IBM may not be in the same league as public cloud service providers such as Amazon Web Services (AWS). But the company is in a unique position to unify the management of public and private cloud computing services, said Rob Thomas, general manager for IBM Analytics.

    Most organizations are implementing a multicloud computing strategy. That decision creates significant data management issues that need to be addressed by a more holistic approach to DevOps, Thomas said, noting that IBM is betting that being able to consistently port applications and data between clouds will emerge as major theme in the enterprise in 2018 that it is in a unique position to address.

    Rob Thomas, IBM

    Today, most organizations are managing each cloud service they engage in isolation. But, rather than decreasing costs, each cloud service engaged brings with it additional overhead. In fact, each new cloud service conspires to increase the total cost of IT ownership for IT organizations as they move to master the tools required to support it. Despite that issue, the inherent business and IT agility cloud services provide are too compelling to ignore. Thomas said the result will be a continued proliferation of cloud services that enterprise IT organizations will want to unify under a common data strategy that also extends to their legacy IT environments. Otherwise, there ends up being too much duplication of data and effort, he said.

    Much of the effort to centralize the management of multiple cloud begins and ends with sound DevOps practices. The need to centralize the management of multiple clouds goes well beyond simply achieving cost synergies. Managing public and private clouds alongside legacy applications won’t be sustainable unless organizations modernize how they build, deploy, update and manage applications, Thomas said. Given the fact that each of those applications in turn increasingly will be made up of multiple microservices, modernizing the way the data that each of those services can access by extension also becomes critical, Thomas noted.

    Of all the major cloud services providers, IBM is the only one focused on providing the tools and services needed to help IT organizations make that transition at the level of scale required, Thomas said, noting that, in addition to a raft of DevOps and data management tools IBM provides, the company has extended the DevOps managed services it provides to enable organizations to accelerate that transition.

    It’s too early to say just yet how the rise of multicloud computing will transform enterprise IT. But it’s clear the days when the local data center was the primary focus of enterprise IT are long over.

    — Mike Vizard

  • IBM CTO Sees Bright Future for Java in 2018

    IBM CTO Sees Bright Future for Java in 2018

    Significant advances in microservices written in Java, as well as tighter coupling between Java applications and containers, are set to transform the way most organizations build and deploy Java applications by the end of the year.

    IBM Java CTO John Duimovich, as part of five Java predictions for 2018, noted that The Eclipse Foundation has taken over the development of MicroProfiles, a baseline platform definition that optimizes Enterprise Java for a microservices architectures, and the EE4J project, an effort to create standard application programming interfaces (API) for Java runtime. This, he said, will make it much easier to build next-generation Java applications using programming tools based on the Eclipse integrated development environment (IDE).

    In some instances, those applications will take the form of a microservice that gets deployed using a Java runtime. In other instances, those applications will be deployed using containers such as Docker. Duimovich said it’s not only a matter of time before containers and runtimes including Java will become more tightly coupled. That will result in more consistent memory management and easier wiring between Java constructs and containers. For example, Java applications will be able to determine automatically how much memory is available to any given container. That’s critical because the reason most containers fail is they exceed available memory limits, he said.

    Duimovich also predicted that Kotlin will be the next big variant of Java to be adopted in the enterprise. Concise coding syntax plus interoperability with other instances of Java have already made it popular for many developers. Now that Kotlin can be used to build applications for devices running Android, this year will see much broader usage of Kotlin to build greenfield applications, Duimovich said. However, he added, it won’t be too long before other variants of Java start employing similar concepts.

    Related Content:

    Hopes and Fails in DevOps 2017

    DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    Other major Java predictions for 2018, Duimovich noted, will be optimization of Java runtimes for serverless computing frameworks and a more regular six-month release cycle for incorporating new functions in Java. The rise of serverless computing frameworks will also result in more Java applications being deployed on public and private cloud services, he said.

    Duimovich noted that, from a practical perspective, a Java runtime is simply another type of container. The challenge facing DevOps teams will be determining when and where to use Docker containers instead of traditional Java runtime to deliver an application. Whatever the outcome, it’s unlikely any IT organization will standardize on one approach to the exclusion of all others.

    The increased rate of Java innovation can be attributed to an Oracle decision made last fall to place Java Enterprise Edition under the auspices of the Eclipse Foundation, said Duimovich. At the same time, IBM moved to open-source its implementation of a Java virtual machine. This has resulted in something of a Java Renaissance, as more developers and organizations are contributing expertise via the Eclipse Foundation.

    There’s no shortage of programming language options available these days. But in many cases, if Java is able to build modern applications, then it’s probable many developers will continue to use Java rather than take the time to learn something new.

    — Mike Vizard

  • Application Discovery and the Value Proposition of IBM Z ADDI

    Application Discovery and the Value Proposition of IBM Z ADDI

    Discovering how an application works can be a difficult, expensive undertaking. That’s why architectures based on REST are so popular. The architectural style provides an easy-to-implement interface that allows consumers to use an application productively without having to understand anything at all about its internals. All a developer needs to know to work an application is how to interact with the resource represented by the given endpoint. What’s going on behind that endpoint is another matter.

    That’s the good news.

    The bad news is that when it’s time to make changes to the application’s internals, things can get difficult. Many times a well-defined interface is hiding a pile of spaghetti code. Sometimes a developer might be able to find an analysis tool that will help make sense of things. Or, maybe there’s documentation that explains it all. But, it’s not unusual for developers to have to bite the bullet and go through the source code and deployment scripts line by line to figure out how the application works. Such work incurs significant expense.

    Discovery: Understanding Dependencies in an Application

    Mainframe developers have been solving the problems of application discovery for years. IBM has been at the forefront of addressing application discovery with a comprehensive solution called Application Discovery and Delivery Intelligence (ADDI). ADDI allows a developer to inspect a IBM Z mainframe application and analyze its performance.

    Application discovery is accomplished using Application Discovery Intelligence (ADI), which is part of the ADDI toolset. Developers and system analysts use ADI, which integrates seamlessly into the Eclipse integrated development environment (IDE), to discover the assets used in an application and also to determine the dependencies between them once discovered.

    Figure 1 below shows an example of the ADI graphical interface. The IDE provides a high level overview of the application (1) as well as a listing of its components (2). Developers can drill down to look at details in a central viewing pane (3). The IDE provides a detailed listing of  a component’s connections and associations, such as subscriptions to message queues or SQL calls (4). Also, developers can view details about a particular assets, such as a SQL query (5).

    Figure 1: Application discovery intelligence describes components in an application and describes interactions between them

    Having immediate insight into the structure and operation of an application reduces the expense required to improve it. Developers save a lot of time not having to peruse code on a line-by-line basis. Yet, this is only part of the cost-saving. Understanding the composition of an application is an important first step. Understanding how an application performs is essential for implementing improvements. This is where delivery analysis comes in.

    Delivery: Providing Quality Service 24/7

    Ensuring quality service on a 24/7 requires that availability of up-to-date runtime information. A good performance monitoring tool provides the ability to to drill down to determine the cause of an issue. IBM Z provides such as array of tools. Remember, meeting service agreements to specification is and has been a critical activity in the mainframe computing culture. It’s part of a mature business process.

    IBM Z Application Delivery Intelligence provides mission-critical insights on a drill down basis. As shown below in Figure 2, IBM Z Application Delivery Intelligence Analysis reports a dangerous condition (1). Then, engineers can drill down to view associated metrics (2) and then even deeper, to view a timeline that shows environmental conditions such as response time from the database and CPU time consumption (3).

    Figure 2: IBM Z Application Delivery Intelligence provides drill-down reporting that allows engineers to identify root causes

    One of the drawbacks of architectures that aggregate heterogeneous systems is that relationships between components become opaque. For example, an application that uses a database service to store and retrieve data has no direct insight into the underlying query behavior of the database service. All that can be accurately reported is the request and response time to and from the service. However, when both application logic and data storage reside inside the same location, reporting details becomes easier. But still, drill-down correlation between systems is still difficult when components are in a common location, such as a virtual machine, yet isolated from one another due to strict encapsulation. Mainframe systems, however, do not have the problem because all components reside in a single location in which access to components is transparent. Thus, cross-component drill-down is easier to accomplish.

    Built to Scale in the Modern Cloud

    When it comes to computing at scale, mainframes were always meant to handle multiple users in a high-volume, transactional environment. Mainframe computing does not lend itself to the type of latency bottlenecks that come about when there are racks of commodity PCs operating with with varying degrees of reliability. The hurdle that mainframe computing had to overcome was making it so it could be accessed using standard web-based standards, most notably REST. IBM addresses the problem with z/OS Connect, a technology that allows IBM Z application functionality to be represented by a REST API. Once a REST layer is added onto an IBM Z system, it becomes just like another resource in the cloud computing ecosystem. And, an IBM Z mainframe computer is designed to be fault-tolerant and highly available. There are IBM Z systems in production that have run without interruption or downtime for decades.

    Making Discovery and Delivery Less Expensive

    Discovering how an application works and ensuring that applications in production meet performance expectations are two of the most important activities in today’s modern enterprise. Application Discovery and Delivery Intelligence provides the tools to meet these needs in the IBM Z cloud computing ecosystem. Using ADDI provides the insights necessary to ensure that service level agreements are met cost-effectively to the satisfaction of all. When it to making applications that matter in a world of web-based computing, ADDI provides an essential value that is difficult to match.

    — Bob Reselman

  • DevOps Chat: Rosalind Radcliffe, IBM, on DevOps and Mainframe Systems

    DevOps Chat: Rosalind Radcliffe, IBM, on DevOps and Mainframe Systems

    In this DevOps Chat we sit down with a frequent guest on DevOps Chat, Rosalind Radcliffe, distinguished engineer and mainframe expert from IBM. Rosalind talks to us about the latest generation of Big Iron from IBM, the z14 systems. Also, we discuss some of the new API and functionality that allows you to do just about anything with your mainframe that you do with your other computing platforms.

    Rosalind is always an interesting interview with lots of great information.

    Note: There are references to a video chat throughout the conversation. We tried to record this chat as a video, but unfortunately, the technology just didn’t work out well for us. But, as usual, the streaming audio of our conversation is below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone. This is Alan Shimel of devopsy.kinsta.cloud, and you’re listening to perhaps the first video chat or video DevOps Chat from devopsy.kinsta.cloud. And I’m happy to have as my first video chat guest none other than Rosalind Radcliffe of IBM. Rosalind, welcome.

    Rosalind Radcliffe: Happy to be here, as always.

    Rosalind Radcliffe

    Shimel: Well, you’re not going to be able to sit and make faces while you’re talking because we can see you. But thanks for joining us. Let’s jump right into things. First of all for our audience who may not know Rosalind, Rosalind is a distinguished engineer with IBM and works within the IBM Enterprise Systems division, mainframes, e-systems, author, engineer, well-known speaker and just a great resource for anyone who is interested in DevOps, mainframe, systems of engagement, systems of records kind of stuff, and a frequent guest here of ours on devopsy.kinsta.cloud.

    So, Rosalind, the last time I saw you was over at Gene Kim’s DevOps Enterprise Summit in San Francisco. And I thought it was a great show this year. Had a chance to do a bunch of interviews. I did a panel on DevSecOps. But more than that, I really enjoyed speaking to a lot of the people in attendance there, a lot of the attendees. Any key takeaways from you on it?

    Radcliffe: Well, I think it was another really good conference, but it was one year next. So there was a lot of people who really have done the DevOps transformation or are a good long way on the DevOps transformation. And so there were a lot more stories about the value that they’re getting and how they’ve transformed, and more about the organizational transformation that happens after you start a DevOps transformation. So I thought that was very good.

    We also had more mainframe customers talking about their transformations, and it was really good to hear the stories about mainframe is really just part of the DevOps pipeline, and more and more customers are starting to see that.

    Shimel: I think so. And Rosalind, if you don’t mind, I actually wrote an article coming home from Gene’s event called “The DevOps Cha-Cha.” And it’s about this sort of undercurrent. I didn’t necessarily see it in the presentations, but I got it in speaking to people there. And that is this sort of whispered thing that hey, this DevOps thing isn’t that easy. Right? We thought it was going to be easy.

    And you know, my DevOps transformation is not going as planned, and it’s not going as fast as we wanted. And it’s not—there’s a lot of work involved here. And I don’t know what gave people the impression that it’s a hockey stick. You know, it was straight up. Things seldom are. I think DevOps can be lumpy, or DevOps transformations can be lumpy. And it’s a little bit of three steps forward, two steps back, cha cha cha, and so forth. Your opinion?

    Radcliffe: Well, I would absolutely agree. I don’t think people understand the cultural challenge to this transformation. Because it really is all about culture. And it’s not just bringing in tools, and a lot of people think, “I’m going to bring this toolchain in and it’ll all be fine.”

    And maybe some of the teams that works for. But there are a lot of teams that that’s really just not going to work for. And there’s just no way that we can just have this continue in the environment. We really have to make sure we are understanding that this is culture, and that the culture is really, has to change. And it’s across the entire organization.

    I think the other thing people didn’t realize is that it is a … what’s the best way to put it? It’s not just culture and you’re done, or it’s not just do it and you’re done. It really is a continuous improvement process. And we like to talk about the kicks team because they’ve been doing this for 15 years or something, and they know they’re not done.

    Shimel: Mm-hmm.

    Radcliffe: So it’s not something that ends. You learn your lessons. You get better. And you learn a new lesson, and maybe you didn’t get better. And so you learn the lessons. And it really is this continual improvement. And so it’s not easy. It’s not a piece of cake. But it delivers real value if you move down this pipeline.

    Shimel: Yep. I mean, takeaways. Dev ops is never done, right? You’re never done with DevOps. And it’s only a failure if you stop trying, right? Anything else is just feedback loops. [Laughter] Everything else is feedback loops. So I think those are great takeaways from that.

    So I went from Gene’s to another event to another event. And we’re rapidly, you know, Rosalind, approaching event season. And, of course, IBM’s big event this year is a little different than years past. It’s called IBM Think, right?

    Radcliffe: Yes.

    Shimel: It’s in March in Vegas. Can you –

    Radcliffe: Yeah. It’s going to be an interesting event. We’re bringing everything together in one. So we used to have in our connect, and Watson’s event, and internet of things. You take your choice of names. Now it’s all one. So we’re going to have one big IBM event for all of our technology, all of our parts of the product. And they’re really trying to bring it in a focused way to make sure it’s a set of customer stories on what they’re doing and how they’re doing things.

    Shimel: Do you know the exact dates, perhaps, off your head? Or if not we’ll –

    Radcliffe: Yeah. See, it’s March 19th. It’s March 19th. The first day is an inner-circle day. And the next Tuesday, Wednesday and Thursday are the main days for the conference. And so it’s a shorter week this time, not making people come in on a weekend and giving you a chance to get home, which I think is a very good thing. But it’ll be a fully packed set of days.

    Shimel: Fantastic. Hopefully we’ll see you out there. I’m not sure about devopsy.kinsta.cloud’s plans yet around it, but we will be making plans, for sure. So Rosalind, you spoke a little bit about Gene Kim’s event. We spoke a little bit about the upcoming IBM Think event. Let’s focus in now on Z systems, enterprise systems. I know you guys are, you released a new generation. What was it, around September or August?

    Radcliffe: It announced in July, July 16th or 17th, and became available in September. And yes, the Z14 with the latest announce.

    Shimel: Yep. And it’s brought a whole bunch of stuff to the forefront, probably some of the biggest might be around security and encryption from my point—humble point of view—anyway. But you’re excited about some new stuff coming up with the Z systems we were talking. Why don’t you share it with our audience?

    Radcliffe: Yeah. I’m really happy. We’ve been doing a lot of work to make the dev ops pipeline work for z/OS software. And a lot of customers are turning to open source. And so they want to use Git. And so I got Rocket to port Git to z/OS, so that’s the first step. And that’s great. That’s been available this year. But we have to have a build system. And so we have made available something called dependency-based build, and it’s in beta, and it will be GA by Think. The idea is you can use Groovy Scripts to write your build definitions for z/OS.

    So think about that. It’s not, you know, JCL. It’s not different. I can use Git just like any other language. I can use Groovy just like any other language. I could write my build scripts. And it’s not different. It can make our COBAL and PL/1 in assembler look just like all those other modern, fun languages.

    And really they—okay, assembler might be a little hard. But, okay, other than that, COBOL is just English and PL/1 is a pretty good language. So why not? The fact that you have to do things so differently, we want to get rid of all that. And so this new capability, it’s in beta. Anybody’s well—it’s an open beta. Think about this. IBM open beta? Yep. There it is.

    Shimel: IBM –

    [Crosstalk]

    Radcliffe: Go play with –

    Shimel: That would be neat. [Laughter] Where can people go play with it? Did you have a URL or section?

    Radcliffe: We have a URL. I’ll get it to you so you can post it. It’s not a friendly URL.

    Shimel: You know, I can’t help but smile, Rosalind, and think about some of my friends and family who aren’t in the tech industry listening to this, or watching this, and hearing that we’re going to be playing with some Groovy scripts, what’s going through their head. But that is great news. And it’s part of this bigger movement.

    You touched on it a little bit. We started at Gene’s event, and it does show. And that is initially with DevOps we’ve been through the binary IT mode, the multi mode, multi speed, binary speed, all this nonsense where let’s treat the mainframe folks as special, and all of that.

    But I’m glad to see that—and Rosalind, I think I ran into you at CA World, perhaps, right, where IBM was a major sponsor. And that seems to be the message coming out of the enterprise world now, the mainframe world, which is that’s nonsense, that we’re not going to stand for being labeled special or anything like that. We move as fast as the next guy does, or as fast as the other systems do. We use the same languages in a lot of instances. And we’re even updating the languages that we do use to make them more relevant in today’s world.

    So to me that’s a huge message, right? That we need to continue hitting home, though. Because I still hear people talking about multispeed and all of that stuff.

    Radcliffe: Yeah. But bimodal is something that needs to go away.

    Shimel: Uh –

    Radcliffe: It just needs to go away. We’re done with it.

    Shimel: Okay.

    Radcliffe: The idea that things are going to go at different speeds is true, but it’s not based on platforms. If I build an API, I really hope I do a good job of that API. And it doesn’t matter if it’s running on a system of record or a system of engagement, it’s running in Java, or it’s running in Cobalt. If I write good code, I’m not going to be changing it 1,000 times a day. So the point is if you’re building APIs, you’re going to build them. But you need to be able to change them as fast as possible.

    So it doesn’t matter the platform. I should be able to deliver that code today. I need to make a change, let me deliver it. And I really—I guess I want Z to be considered special for its qualities of service, i.e. its reliability, its scalability. Not because it’s different in the way you do work for it. So if it’s just another node in your pipeline, it’s just another node. It just happens to have a different set of qualities of service. And if you build your node, or your Java, whatever, and you end up needing the qualities of service of Z, run it on Z. Why not?

    Shimel: Agree.

    Radcliffe: And let’s get the differences because you think a system of record has to be slow, or the differences because you think Z has to be slow. I mean, it’s funny to me. We call the mainframe an old system, but really with the Z14 and the LinuxONE announcement, it’s the most modern platform that exists out there. It’s the most modern chip. So how is it old?

    Shimel: Yeah. Yeah. I hear ya. A hundred percent agree. Rosalind, you know, we’re almost at the end of our time on this experiment and I do hope the video comes out. But if not, the audio will. And if you’re listening to this without video out there, it’s because the video didn’t work out so good. But at least we’ve got the conversation imparting the references to the video.

    Rosalind, we hope to see you soon. Maybe between now and Think we can do something a little more in-depth, a webinar or something about what we’ll see from Enterprise Systems at Think and what else we have coming down the pike as we move closer to Think. And until then, though, have a merry Christmas, happy new year, happy holidays, and thank you for always being available to us here at devopsy.kinsta.cloud.

    Radcliffe: Well, thank you. Thank you for your time. And you enjoy the holidays, as well as everyone who is listening if they hear this before the holidays. Merry Christmas.

    Shimel: Yes, yes, yes. All right. Rosalind Radcliffe, IBM Enterprise Systems, distinguished engineer, and our guest on our very first video DevOps Chat. I guess they’re not DevOps Chats. All right, Rosalind. Thank you. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: IBM’s Cloud Private with Mike Kaczmarski, CTO DevOps and Service Management

    DevOps Chat: IBM’s Cloud Private with Mike Kaczmarski, CTO DevOps and Service Management

    In this DevOps Chat we discuss IBM’s Cloud Private. Cloud Private is the new offering from IBM that encompasses much of the different cloud offerings the company has developed over the years. Our guest on this DevOps Chat is Michael Kaczmarksi, an IBM Fellow and CTO of DevOps and Service Management. In his distinguished career at IBM, he has obviously seen technologies come and go. Michael gives us an inside look at IBM’s Cloud Private offering and how it relates to DevOps, service management, hybrid cloud and so many other contemporary technologies in the market today.

    As usual the streaming audio of our discussion follows immediately below. Below that is the transcript of our conversation to follow along.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. We’ve got a very interesting chat lined up for today, with a great guest. Let me introduce him. We have today Mr. Mike Kaczmarski of IBM. Mike, welcome to DevOps Chat.

    Mike Kaczmarski: Thank you, Alan. Glad to be here.

    Shimel: So, Mike, you have a CV résumé full of accomplishments, and I don’t mean to embarrass you, but why don’t you just share with our audience kinda what you’re doing now with IBM and a little bit of your background?

    Kaczmarski: Alright, I’d be glad to. Well, my title is IBM Fellow, CTO of DevOps and Service Management, in a unit inside IBM called Hybrid Management—Hybrid Cloud Management. I’ve been with IBM—well, in February, it’ll be 35 years.

    Did a lot of work in the storage portfolio—a lot of the Spectrum products, Spectrum Protects, Spectrum Control. I came into a business unit that was called Tivoli at the time, became very familiar with all of the service and systems management products, and then into products like Maximo and others that we acquired or built out organically. And then became involved in a lot of the cloud technology—IBM Cloud and now I’m working very hard on DevOps technology and service management technology in a new offering that we have out called IBM Cloud Private.

    Shimel: Excellent. Excellent, excellent, excellent. And we’re gonna try to get to as many of these as we can, Mike. But in order to do that, I think we need to lay down a little sort of baseline, if you will. And how I wanted to do it was, you know, let’s talk about really what I think is one of the primary drivers behind the whole hybrid cloud transition that we see, and that is that traditional applications—you know, everyone would just like to move everything to the cloud, perhaps, make it easy, and be done. But that’s not the way the world works, right?

    Kaczmarski: [Laughter] Right.

    Shimel: You know, customers are beginning that migration, but that migration will probably take—Mike, you said you were with IBM 35 years. I’ve been around awhile myself. We’ll be long gone by the time that migration is over, I suspect. [Laughter]

    You know, so in the meantime, customers are faced with sort of this hybrid period where, you know, some of the applications and some of the application infrastructure may still be on-prem, may still be maybe a private cloud on-prem, maybe on a public cloud, maybe on a private cloud in a data center. You know, truly, a multi-cloud and hybrid environment. Is that what you’re seeing at IBM?

    Kaczmarski: Certainly what I’m seeing. If you consider things like the importance of customer data, data sovereignty, customers’ concerns over security, proper connectivity—all those need to be addressed, and customers’ businesses are running on their IT, and they’re comfortable at different stages with different aspects of those things being on the cloud, whether public or dedicated, and you often find something, like private cloud is a wonderful way to get started on understanding what operational architecture programming changes and even organizational changes they need to make to best start to utilize the cloud. Whether they take all those capabilities to public or dedicated cloud or not, the private cloud helps them.

    Shimel: No doubt about it. And so, Mike, when we talk about—you know, they may be IBM customers. But when we talk about organizations transforming their traditional—and by traditional, I mean non-cloud, they’re not cloud native apps—and trying to migrate them to the cloud. You know, I think you highlighted some of the things that we run into, but anything else that I think listeners may be interested in or at least gotchas that they should be looking for in transforming these apps and trying to move them to the cloud?

    Kaczmarski: Yeah. Well, I think there’s three patterns that we see pervasively. The ones you hear a lot about are those customers who are building out new cloud services, new cloud native programming models, and extending their business into the cloud using some of these new microservice-oriented programming models—polyglot technologies—and perhaps connecting them to their enterprise from the cloud; hence, the hybrid sense through APIs and API management so they can take advantage of their back office systems and the data and expose other application pieces on the cloud.

    There’s a few other patterns. We see customers who have applications that would fairly easily be optimized by cloud technology, such as container technologies for rapid deployment, rapid scale out, resiliency. There are applications that can be, we call it, lifted and shifted fairly easily. And then there’s a whole area of applications that are built out in monolithic fashion that have very tight interdependencies that have been around for years and years, and customers are making decisions on what they do with those applications, and it kinda depends on how much those applications are changing, how critical they are to the business—I don’t wanna touch it, it’s not changed in years, it’s doing its job. That might be some of their criteria. In other hands, parts of those applications might be changing fairly rapidly. And if that’s the case, then they start looking at refactoring or factoring out the portion of application code that is changing fairly rapidly into, say, microservices and placing those in the cloud.

    So, I think there’s a number of approaches that they’re taking, and obviously, it’s a business issue. What makes sense for me to refactor? What am I gonna gain by the refactoring of these applications and putting them in the cloud? How am I gonna lower operational costs? How is DevOps gonna help me, and what kind of return am I gonna get from that versus continuing to do what I do or even leaving some of my monolithic applications alone?

    So, I think, you know, there’s a broad range of considerations that customers have when they look at moving their applications to the cloud, and hopefully I’ve kind of listed a few, there.

    Shimel: Absolutely. So, Mike, you know, this is all—it’s all happening, and I think we’ve kinda described it well. But now, so IBM has recently come out with this Cloud Private, as they’re calling it, and you know, frankly, I think there might be a little misunderstanding in the market where, hey, you’re talking about hybrid cloud, but now, why are you doing Cloud Private? Right? Is it private cloud, is it hybrid cloud? Cloud Private—where does that fit in? Can you help clear it up for our listeners?

    Kaczmarski: Yeah, sure. IBM Cloud Private is an on premise cloud offering based on Kubernetes technology, optimized by some of our systems group. It does run and allow you to deploy private clouds, what I’ll call on premise clouds, on Intel, on Power, on zLinux, so you can take advantage of the systems you might already have deployed, but it has full connectivity to any services in—cloud services that are running in the cloud public or dedicated cloud. It’s a way for customers to start to either write new microservices or write new capabilities or refactor, as I mentioned, some of their applications into a cloud that is running on premise, allow them to experiment without concerns of data privacy, data governance, data sovereignty, and allow them to figure out what’s the best approach that they want to take for refactoring their applications or moving them to the cloud.

    It is Kubernetes-based. It’s based on the same technology that runs on our public cloud and what we call the container services. So, much of the workloads that can run in the private cloud if the customer chooses can be transparently moved to the public cloud or a dedicated cloud for them. The Kubernetes technology overall, the Docker containerization—everything’s running in Docker. They’re fairly pervasive in the industry, so it does give the customer a choice. I think it gives them a foundation that they can start with. They can move workloads at their most comfortable, keeping them on-prem, and then they can start to extend those workloads to the public or dedicated clouds as well.

    You know, another big difference with IBM Cloud Private is, we’re moving our middleware, our traditional offerings like the WebSphere and message queue and IIB and DB2 and the data science experience—traditional middleware that customers have running on-prem that they’re writing their applications against are now available in IBM Cloud Private in containerized versions, the same service, the same APIs, a lot of the same capabilities. And so, they can actually take advantage of the same middleware that they’ve been running with, now containerized in clouds so that they can take advantage of simpler deployment, AB deployment, a simpler upgrade, resiliency, scale out, and so on.

    So, that’s what I think we bring to the Cloud Private arena is the ability for customers to leverage the investment they have in our middleware and middleware services now in a cloud deliverable. And that also makes it easier for them to move their applications into a cloud architecture, whether it’s on-prem in Cloud Private or in public in IBM cloud or a dedicated cloud, an IBM cloud.

    Shimel: You know what, Mike, that was fantastic, and it kinda made a lightbulb go off for me, here. What really, what Cloud Private is offering customers, or anyone—you know, eventually, I guess, their customers—but it’s portability. It is giving you a cloud ready infrastructure, whether that cloud be on prem, at an IBM data center, maybe in a public private type of situation, hybrid situation or not. And not only is it allowing that infrastructure through containers and Kubernetes to be portable like that, you’re now portable-izing, if that’s a word, [Laughter] that whole layer of middleware that so many have been using for so long—

    Kaczmarski: Yeah.

    Shimel: – and making that also portable to whatever or however and in what combination you want to post your applications going forward.

    Kaczmarski: Yes, that’s sort of a—

    Shimel: And that’s really powerful.

    Kaczmarski: – yeah, that’s a good description, yes.

    Shimel: Yep. And, you know, I think, you know, Mike, it really goes to the heart of what we’re seeing in technology today, which is the—and a lot of it is via Kubernetes; well, microservices and containerization, let’s call it that.

    Kaczmarski: Yes.

    Shimel: It’s fundamentally shifting the IT infrastructure or the preferred IT infrastructure in a way that we haven’t seen maybe since when we moved from client server, or maybe when virtualization and hypervisors first became sort of dominant or started really asserting influence in the market. This is really a shift of that magnitude. Do you agree?

    Kaczmarski: Yes, I do, and actually, those are two perfect storms that kinda come together, the virtualization and the client server. I think containerization is an interesting supporting feature of microservices. It really allows a full stack deployment, and actually changes some of the roles and responsibilities of what developers have traditionally done.

    Shimel: Absolutely on that. So, this is DevOps Chat, though. Let’s talk a little bit about DevOps. I always like to tell people that—hey, DevOps is an umbrella term today. It’s more than just the breaking down of the silos between dev and ops, and there’s obviously a cultural aspect to it. But, you know, the thing about DevOps is, it’s about how things get done today. And so, when we talk about things like microservices and containerization and cloud, right, I don’t know if DevOps is a byproduct of those things or if DevOps is a precursor or an accelerator to those things, but they seem intrinsically linked.

    Kaczmarski: Yes.

    Shimel: What’s your view on that?

    Kaczmarski: Yeah, I think they are tightly linked. I think DevOps enables the kind of automation you really want to be able to understand how your applications are being developed, are integrated, how they’re performing, whether or not you’re ready to go into production with what you currently have, whether or not you’re really ready to support, operationally, the applications you already have—all of those things, as early in the life cycle as possible.

    And, you know, when you talk about containerization and microservices, as compared to monolithic applications, there’s a lot more moving parts. There’s many more moving parts in a microservice container organization of your code. You know, you have business function decomposed into various different microservices. It’s actually an organizational construct as well as an architectural construct. You have teams around those microservices building them. They all have API contracts with each other on their behavior, and now they’re deploying at different times into what should be a running system that’s providing a service. At every point along that line, you wanna understand. You wanna be able to herd all of these microservice teams that are together building out the application in a consistent way and always know where you stand in terms of the application being built.

    By the way, the same applies to monolithic apps, because they undergo change if they’re interacting with these cloud native apps and microservices. So, you need to be able to automate and make sure nobody breaks the builds, you need to be able to do continuous deployment of the microservices in, say, a test cluster or a cloud where they interact with each other. You want to vary the versions that are out there to understand if the API contracts have been violated. You want to have a real good idea of the performance and scale of the microservices that are out there—and there are so many of them in a traditional application now, manual tasks would never be able to keep up. So, automation through DevOps in terms of build, deploy, the manageability, the testing of the microservices is paramount in being able to scale a true microservice architecture to a product that has reliability and can be easily updated and can actually iterate very quickly to meet customers’ needs.

    Shimel: Absolutely. Mike, let me introduce another term into our term goulash today, and that’s service management, alright? So, service management is something that has certainly been on the IT agenda, right, on the IT menu for longer than the word DevOps has been used, right?

    Kaczmarski: Yes.

    Shimel: Service management is an important piece of it, right? And there’s been somewhat, frankly, of a disconnect on the nexus or connection of DevOps and service management. Are they compatible? Do they work together? Is there a continuum with them?

    What’s your view? I mean, you have both under your portfolio, here. What’s your view on that?

    Kaczmarski: Well, I think that integration of DevOps into Ops, if you will, relative to DevOps I just talked about in terms of automating, you know, build, deployment, test—integration into Ops is more about making sure you can monitor the application, making sure that if there are outages, you have procedures, run books that can quickly bring things back, supporting things like site reliability engineers, understanding who’s going to be notified if there’s a problem with a particular service—all of those kinds of things push back operational characteristics on the DevOps and even the development team.

    You know, as our teams were building out IBM Cloud, a lot of the services in IBM Cloud are managed by, developed by individual squads, so a logging service or a particular database service or whatever we make available in that cloud, there’s a squad behind it. Obviously, they develop it, they go through regular DevOps deployment and testing, they determine when it goes into production a lot of times based on analytics from a lot of the automation that they have.

    When it goes into production, they’re immediately also responsible for the ongoing operation of those services. This is the development team. They’re now responsible for the ongoing operation of those services. Now, they have site reliability engineers as well, but if you take some development teams and make them responsible for the operational characteristics of their services, a lot of interesting things start to happen. You start seeing development not around the application itself, but also around, “Oh, hey, I have some Selenium scripts that I’m gonna use to automatically monitor response time of the application. This needs to get deployed with the code.” “Oh, I have some run books for the SREs or automated scripts that, should certain events show up, will automatically restart or scale out services appropriately.”

    You start seeing operational artifacts as part of the development of the particular microservices or applications that are being built. And of course, as that starts to occur, you start seeing standards for handoff of these kind of artifacts between DevOps and Operations teams so that not only are they deploying application, they’re deploying the management around that application and they’re ready to go when that application goes to production.

    So, I think that’s the biggest cultural change I’m seeing with DevOps going into Ops is really integrating the management capabilities and intelligence into the application and the awareness that now the developer and the DevOps team have in providing what is needed to properly manage the application and operations.

    Shimel: Mike, that was one of the best answers to that particular subject that I’ve heard. Thank you very much for that.

    Unfortunately, Mike, as I told you before we started, the time here goes really, really fast. I promised you we’d be done in 15 minutes and we’re on 20 minutes already, so I know we had a lot of other topics we wanted to cover. Maybe we’ll have you back on at another time and we can do a part two on this, but we’re about out of time right now.

    Thank you so much for being our guest on DevOps Chat today, Mike.

    Kaczmarski: Oh, thank you, Alan, I really enjoyed it.

    Shimel: Not a problem at all, and as I said, I’d love to have you back on here soon, and we can continue the discussion. But before we go, for anyone who wants to get more information on IBM Cloud Private, where can they go?

    Kaczmarski: Well, actually, the easiest thing you can do is Google IBM Cloud Private, and there’s a number of references out there, and tools. There’s cloud reference architectures, developers, communities. If you want to engage with some teaming with IBM on what’s the best way to move some of your applications to the cloud, there’s IBM Cloud Garage, and there’s some wonderful blogs out there where developers will take you through how they actually move some of the applications to the cloud. So, I would just Google IBM Cloud Private, and you should see, in the first two things that come up, some really good references.

    Shimel: Fantastic. Mike Kaczmarski, IBM Fellow and CTO for IBM Private Cloud, DevOps Service Management—thanks so much for being our guest on this episode of DevOps Chat. To everyone listening, hope you enjoyed it, and we’ll see you soon on another DevOps Chat. Have a great day.

    — Alan Shimel

  • IBM Brings Cloud-native Environment to Private Clouds

    New IBM Cloud Private software – based on containers, microservices and APIs –bridges Public Cloud and traditional IT environments

    ARMONK, N.Y. – 01 Nov 2017: IBM (NYSE: IBM) today announced a new IBM Cloud Private software platform to help companies unlock billions of dollars in technology investment in core data and applications and extend cloud-native tools across public and private clouds.

    IBM Cloud Private software is designed to enable companies to create on-premises cloud capabilities similar to public clouds to accelerate app development. The new platform is built on the open source Kubernetes-based container architecture and supports both Docker containers and Cloud Foundry. This facilitates integration and portability of workloads as they evolve to any cloud environment, including the public IBM Cloud.IBM also announced new container-optimized versions of core enterprise software, such as IBM WebSphere Liberty, Db2 and MQ – widely used to run and help secure the world’s most business-critical applications and data. This makes it easier to share data and evolve applications as needed across IBM Cloud private and public clouds and other cloud environments with a consistent experience.

    An airline, for example, could use IBM Cloud Private to bring a core application that tracks frequent flyer miles into a private cloud environment and connect it to a new mobile app in the public cloud. A financial services firm could use it to keep customer data in-house as it works to meet its security and regulatory requirements while taking advantage of new analytic tools and machine learning in the public cloud to quickly identify investment trends and opportunities.

    Enterprises to Spend More Than $50 Billion a Year on Private Clouds

    While public cloud adoption continues to grow at a rapid pace, organizations, especially in regulated industries such as finance and health care, are continuing to leverage private clouds as part of their journey to public cloud environments to quickly launch and update applications. IBM estimates companies will spend more than $50 billion globally starting in 2017 to create and evolve private clouds with growth rates of 15 to 20 percent a year through 2020, according to IBM market projections.

    “Innovation and adoption of public cloud services has been constrained by the challenge of transitioning complex enterprise systems and applications into a true cloud-native environment,” said Arvind Krishna, Senior Vice President for IBM Hybrid Cloud and Director of IBM Research. “IBM Cloud Private brings rapid application development and modernization to existing IT infrastructure and positions it to be combined with the services and experience of a public cloud platform.”

    Hertz, Ilmarinen Transforming IT with Private Cloud

    The Hertz Corporation, one of the top car rental companies in the world, believes both public and private cloud is critical to achieving its technology objectives.

    “Private cloud is a must for many enterprises such as ours working to reduce or eliminate their dependence on internal data centers,” said Tyler Best, Hertz Chief Information Officer. “A strategy consisting of public, private and hybrid cloud are essential for large enterprises to effectively make the transition from legacy systems to cloud. Hertz is an early adopter of both public and private IBM cloud and we could not accomplish our technology goals without private cloud as part of our overall cloud portfolio.”

    Ilmarinen, a Finland firm responsible for the pensions covering approximately 900,000 Finns, has started a pilot project with IBM Cloud Private and plans to be in production in early 2018.  “Ilmarinen is excited about the capabilities in IBM Cloud Private as a flexible, compliant cloud-native platform that it can deploy and manage behind our firewall for creating new applications and modernizing traditional workloads,” said Jani Itkonen, Production Manager, Ilmarinen.

    IBM Cloud Private Provides Flexible Platform with Support for Enterprise Developers

    Innovations used in IBM Cloud Private are designed to simplify cloud management, accelerate app develop and maintain security across cloud environments. Key features include:

    • Cloud Management Automation – Streamlined management across cloud environments to help launch, monitor and manage services and help ensure consistent security protocols.
    • Security & Data Encryption – Security Vulnerability Advisor to scan containers across the cloud to surface potentially serious issues and weaknesses; Ability to encrypt all data in flight and provide for strict access control by users within a cluster.
    • Core Cloud Platform – Includes a container engine, Kubernetes orchestration, Cloud Foundry and essential management tools surrounding developer runtimes, which are fully integrated and automated.
    • Infrastructure Choice – Compatible with systems from leading manufacturers including Cisco, Dell EMC, Intel, Lenovo and NetApp, as well as IBM Systems, including IBM Power Systems, IBM Z and IBM Hyperconverged Systems powered by Nutanix software.
    • Data and Analytics – Integrations with database services, such as IBM Db2, PostgreSQL and MongoDB, to leverage data and gain business insights.
    • Application Support & DevOps Tools – Containerized versions of software and development frameworks, including IBM WebSphere Liberty, Open Liberty, MQ and Microservice Builder, as part of software bundles; Optimized management and DevOps tools, including APM, Netcool and UrbanCode, which can be added for a separate fee.

    IBM also offers cloud deployment, management, brokerage and storage services to help clients manage multiple clouds and can help clients with migration of applications to IBM Cloud Private. More details on Cloud Private can be found in the product overview.

    IBM Cloud Private Reinforces IBM Commitment to Open Source

    IBM Cloud Private is another significant step in IBM’s support for organizations to create, deploy and manage apps in the cloud environment of their choice. IBM and Google recently announced an effort to create and open source the Grafeas project to help developers with security of containers. Last month, IBM released Open Liberty, a new lightweight, open-source version of its WebSphere Liberty Java application server, to make it easier for developers to get apps up and running in any cloud environment.

    IBM also is a founding member of the Cloud Native Computing Foundation, which hosts Kubernetes and Cloud Private is in compliance with its interoperability conformance tests. To get started with IBM Developer Journeys as they relate to Kubernetes, please visit: https://developer.ibm.com/code/journey/

    For more about IBM Cloud Private, visit here.

    For more about IBM Cloud, visit here.

    Contact(s) information

    Joe Guy Collier
    IBM Media Relations
    1 (248) 990-4707
    jgcollie@us.ibm.com

  • IBM Adds Cloud Foundry PaaS to Cloud Private

    IBM Adds Cloud Foundry PaaS to Cloud Private

    As IT organizations are being asked to provision and support an ever-growing number of platforms, they increasingly require an approach that abstracts away as much of that complexity as possible. With that goal in mind, IBM created IBM Cloud Private, an on-premises platform that automates the deployment of a private cloud based on Kubernetes container orchestration software. This week, IBM announced it is extending the reach of IBM Cloud Private to include support for the open-source Cloud Foundry platform-as-a-service (PaaS) environment.

    IBM Cloud Private is designed to be deployed on top of virtual or physical servers, including instances of hyperconverged infrastructure based on software from Nutanix. Michael Elder, an IBM distinguished engineer for IBM Cloud Private, says IBM has developed tools for automating the provisioning of not only underlying infrastructure, but also containerized and legacy versions of IBM middleware such as IBM DB2 databases, the Open Liberty Edition of WebSphere application server and IBM Microservice Builder. In addition, Elder says IBM Cloud Private can be employed to deploy a variety of open-source databases, including MongoDB and PostgreSQL.

    Also available for an additional fee with IBM Cloud Private are a plethora of DevOps tools including APM, Netcool, UrbanCode, Cloud Brokerage, Jenkins, Prometheus, Grafana and ElasticSearch. Regardless of the platform employed, IT organizations should be able to apply a consistent set of DevOps processes to manage either Kubernetes or Cloud Foundry, Elder says.

    IBM is also addressing security issues by including Security Vulnerability Advisor to scan containers and an ability to encrypt all data in flight.

    Elder says many IT organizations will deploy 12-factor applications on a PaaS environment alongside containerized applications running on Kubernetes. IBM Cloud Private is designed to provide a common management framework for managing both environments. However, IBM is not extending that management framework to the IBM public cloud. Elder says the company determined that attempting to create a common management framework for both would result in too much complexity, especially for administrators of public cloud services that require a much more streamlined user interface experience.

    Most IT organizations could, of course, craft their own private cloud. IBM Cloud Private simplifies that process by providing all the pieces required under a common management framework. Rather than spending months putting those elements together, IBM is making a case for an integrated platform that enables IT organizations to concentrate more of their efforts on deploying applications instead of managing infrastructure.

    The debate occurring across the IT industry now is to what degree will container-as-a-service (CaaS) environments based on Kubernetes supplant traditional PaaS environments. IBM, as a major supporter of both Kubernetes and Cloud Foundry, is clearly betting there will be room for both. The Cloud Foundry Foundation recently furthered that goal by adding support for a Kubernetes runtime.

    Thus far, however, the complexity of standing up a PaaS environment has limited the adoption of Cloud Foundry to Fortune 1000-class IT organizations or cloud service providers. Meanwhile, CaaS environments based on Kubernetes increasingly are being stood up by developers and then handed over to IT operations to manage. Given that disparity in deployment models, it may not be too long before the number of CaaS environments simply overwhelm the number of instances of traditional PaaS environments.

    — Mike Vizard

  • DevOps Chat: Shift Ops Left, Shift Dev Right with Kristian Stewart, IBM

    DevOps Chat: Shift Ops Left, Shift Dev Right with Kristian Stewart, IBM

    In this DevOps Chat we speak with Dr. Kristian Stewart of IBM’s Cloud Event Management team. Kristian has some keen insights into the role of dev and ops and how they interact. Kristian calls it Shift Ops left, shift dev right. An interesting way of looking at things.

    As usual the streaming audio is immediately below and the transcript of our conversation is below that.

    Audio

    Transcript

    Alan Shimel:               Hello, everyone, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Got a really hot chat today and my guest joining me is Kristian Stewart of IBM’s cloud event management team. Kristian, welcome to DevOps Chat.

    Kristian Stewart:         Thanks very much for having me, Alan.

    Alan Shimel:               And I just wanna make sure I got it right – it is Kristian Stewart, right?

    Kristian Stewart:         Last I checked.

    Alan Shimel:               Okay. Well, sometimes my funny French accent throws people off, but, anyway – and, Kristian, I mentioned you’re working with IBM in cloud event management, but give our audience a little bit behind that. What exactly does that mean?

    Kristian Stewart:         Well, let me give you a bit of a background ’cause there’s some history here, in particular with respect to the topic of the podcast, which talks about operation tools. So I’ve been with IBM for ten years. I’m one of the lead architects for a suite of IT service management tools, and my own specialization is in event management, as part of IBM’s Netcool brand, okay? So I’ve been in this industry for 18 years.

    I worked for a small start-up back in the late ’90s – the company was called “Micromoves,” and we were focused on introducing tools for disciplined fault management into telcos, into communication service providers, during the dot-com boom of the late ’90s. And then, in the early ’00s, we pivoted and successfully sold into enterprise, finance, retail, as their IT infrastructures became larger and more complex and as they matured, from an IT operations perspective. So we were acquired in 2006 and we started to work towards applying interesting mathematical and analytical techniques, for increasing the value provided by our tools, and applying machine learning and problems to this space. So that was my background up until about three years ago.

    So what do I mean by “cloud event management”? Well, more recently, as part of the movement of the industry that we serve, as they move into cloud and their investment in cloud has increased, I’ve been working with teams to build software-as-a-service offerings  capabilities we had, till that point, only available on-premise, so it includes alert notification tools, runbook automation tools, and cloud event management. And so our particular interest in DevOps is twofold, right? So our transition itself, from going to shrink-wrapped client service software, that was originally deployed on-prem, has gone through to the development of cloud-native, cloud-scale, public cloud resident offerings, and with our guys embracing paradigms like micro-service architectures, 12-factor apps, and, of course, DevOps.

    And one of the biggest challenges or one of the biggest changes our teams have had to endure is that they now have to operate these deployments themselves, right? So they’ve gone from shrink-wrapped, “Give it to the client. Now it’s their problem,” – well, kind of – through to “Now we’re hosting this for you.” So we’ve had folks from development and QA transitioning to operations roles, and they’re required to apply software engineering skills and work with app developers to ensure that we’ve got robust capabilities in private cloud. And we’re providing 24/7 ops to support these offerings.

    But we find ourselves in a fairly unique position because we’re running operations but as a service product that themselves are designed to help people responsible for running operations for their own apps and services. So it’s just sort of a renewed empathy for our end users, especially as we start to angle our offerings towards teams that are embracing DevOps. Does that answer your question?

    Alan Shimel:               Yeah, and then some. [Laughs] But good stuff, Kristian. Thank you very much. So wanted to talk a little bit today bringing this back home to DevOps, right? And one of the trends that we’ve been seeing over at devopsy.kinsta.cloud recently is, really, around kind of putting the “ops” in DevOps, right? ‘Cause we’ve spoken now to a few folks in the DevOps space from both the vendor and practitioner side, who are really emphasizing the role that ops plays in DevOps. And one of my things about it, though, Kristian, is I get the opportunity to speak to a lot of people like yourself, a lot of people who are heavily invested in DevOps, but I also get a lot – the chance to talk to a lot of people who aren’t and are new DevOps or just dipping a toe in the water and planning their DevOps migration and transformation.

    And one of the things that I try to remind people is that “Don’t leave your common sense at the door,” at the DevOps door, right? Bring it with you, number one. And, while you’re bringing something with you, it doesn’t mean everything you’ve done in ops to this point and all the lessons learned and best practices accumulated get thrown out – you know, the baby with the bathwater. With DevOps, we evolve. We’re not necessarily revolutionizing; we’re evolving. And so building on best practices and time-tested ops practices and methodologies and processes is probably a better solution than, you know, scrapping the whole thing and starting from scratch. And who has the opportunity to do that anyway? What do you say to that, Kristian?

    Kristian Stewart:         Oh, I agree completely. And, you know, amongst our clients, we’ve got a whole array of clients, from telcos to finance to retail, right? You name it. Across those clients, we have people on varying points on the curve of maturity, with respect to adopting DevOps. But what I say to those clients, as they look at those paradigms, is that the business objectives of operations teams haven’t changed substantially, certainly since I’ve been in the business. There’s a lot that has changed, but the business objectives continue to be measured by KPIs like mean time to repair, mean time between failures, and pressure on costs, right?

    So disciplines – so, within a, let’s say, a mature enterprise that have invested heavily in ITIL, they adopt disciplines like event and incident management, and that leans on a key set of capabilities, which are equally applicable when you transition to DevOps. You know, the proximity of your developers to your operations and the smoothing of the processes and the interactions between those organizations, if anything, are enhanced by some of the traditional methodologies and tools. So, you know, to list some of them, you need tools which can consume events from highly heterogenous environments; you need to minimize the amount of management noise that’s presented to the people who have to respond to events; you need to be able to integrate with other systems; you need to be able to help pinpoint probable causes, drive efficiency in operations, do things like apply machine learning and advanced analytics to gain insight from your event and incident data.

    So, if you look at the evolution of these practices, historically, right, ITIL emerged in parallel with the practice of event incident management. It didn’t dictate it. You know, these standards emerged as – sorry, event and incident management emerged as de facto practices, driven by the availability of practical tools to solve real problems, and they still solve those problems. You know, if you look at the way that operations has evolved, look at telecom from the late ’80s and early ’90s, right?

    So, in a telco network operations center back then, you might have had dozens of very highly-skilled people, _____ network engineers, with training on dozens of different management tools, and these guys and girls were expensive, right? I mean, their time cost a lot of money, and then the introduction of event and incident management tools helped transition from that to having perhaps the same number or even more operations staff of a substantially lower skill. And so the first thing event management and incident management did was to try and lower the cost of entry for running an efficient operations team.

    But now, if you look at the changes in IT management now – so I was chatting to a large enterprise just the other day, and, ten years ago, they – so these guys have always been driven by those same metrics – MTTR, MTBF, cost, right? A few years ago, their job was to provision physical hardware, static middleware, and the management of that stuff from an operations perspective. Now these guys are having to provide platform-as-a-service tools, distributed runtime container and orchestration systems, and they still have responsibility for the existing infrastructure – the network, the physical servers,  the legacy monolithic applications. And all that still requires management. So, mainly, they’ve got the challenge of managing hybrid cloud, coupled with extremely tight expectations on time-to-market that working practices like DevOps and Agile software development allow for.

    So I’d say that event and incident management tools are as relative now, if not more so, than they ever were because, when you shift to practices like DevOps and site reliability engineering, you know, back to the olden days where you have ops employing of hundreds of you know, low-skill operators, best practice is transitioning to one where you have a substantially lower number of substantially higher-skilled operations staff. Right? So these guys and girls are highly skilled, but they’re time-poor. You know, your typical operations professional, in an organization that’s embraced DevOps, wanna be concentrating on automation, on liaising with dev early on in the release life cycle, on prepping for new rollouts. They don’t wanna be grappling through log files and sifting through performance metrics to find out what happened just so they can restore a broken service.

    And I think the eventual goal of the kind of tools that we provide – event and incident management – isn’t just to help the operator find the needle in the haystack; I think it’s to hand them the needle. And that’s useful, whether you’re a low-skilled junior operator in old-school operations or a time-poor, hyper-technical site reliability engineer with 20 years’ experience. Alan, you still there?

    Alan Shimel:               Yes. Kristian, I’m sorry. I had a little internet issue. So all really good, but, you know, one of the things I wanted to touch on, Kristian, is the subject of empathy, as part of kind of your DevOps mantra, right? Sometimes, people give cultural things short shrift, but empathy is important in DevOps. And what I wanted to ask about was the idea of “How do we get developers?” Right?

    For a long time, the ops people have sort of had to empathize with developers are doing and what they’re doing in terms of development to help in deployment and stuff, as part of DevOps, but now, putting that on the other foot, right, getting developers to empathize with what the ops folks are dealing with, as part of this DevOps equation. I mean, I’ve heard of some organizations where they’ll actually embed developers on the ops teams for short periods of time so that they get empathy the hard way, if you will, right?

    Kristian Stewart:         Yeah.

    Alan Shimel:               They gotta live it. What do you think about something like that?

    Kristian Stewart:         I think, in terms of getting the development professionals involved, I think – so you mention role rotation, right? And I think that’s one tactic. You know, I like to think of this as much as “shift-right dev,” as it is “shift-left ops,” right?

    Alan Shimel:               Yeah.

    Alan Shimel:               Good. Good.

    Kristian Stewart:         And, actually, you know, it reminds me of the situation in shrink-wrapped software development, maybe 20 or 25 years ago, between development, who were the coders, and QA. Right? So there was sort of a brick wall, prior to Agile software development, where it was throwing a pile of code over the wall. And I think Agile, with that shift-left testing, really helped to remedy that, to the extent that I see, today, developers and quality assurance engineers working really, really closely together and not depending on, you know, reams and reams of documentation to communicate with each other.

    So, I think, with DevOps, I think a similar thing is happening, and I think you need shift-right dev, as well as shift-left ops. So operating an application or a service, I think, has to be a shared responsibility, and I do think that dev need to get skin in the game. So that’s gonna include dev as an escalation point, when an incident occurs. It can also include role rotation. But, for mutual benefit, I think they both need to use the same operations tools, right, so that they see what each other are doing, when an incident or a critical event occurs in the environment. And then they’re motivated to improve the use of those tools for themselves, as well as for the sake of operations.

    I think, you know, a 3:00 AM incident notification, you know, like a page at 3:00 AM, is a great motivator. So, for ops people, it’s an incentive to get runbooks and automatic incident responses written so that service restoration is as quick as possible and, preferably, automatic. With dev, it’s an incentive to make their services or applications operable, right, so they need to get the right amount of instrumentation into the app so that ops can manage an incident or, better still, that some script can, so that neither of them get the 3:00 AM escalation. So I think there’s a – with all due respect to my dev and ops colleagues, there’s a carrot-and-stick approach there.

    Alan Shimel:               Mm-hmm. Yeah, that makes perfect sense. Kristian, I want you to repeat what you said before. We need to shift ops left and shift devs right or did I have that backwards?

    Kristian Stewart:         Yeah, no, yeah, that’s what I said. Shift-right dev and shift-left ops, right?

    Alan Shimel:               Got it.

    Kristian Stewart:         So get them to have a degree of overlap with respect to their responsibilities. And, of course, what they do in response to those responsibilities can be quite different. You know, let me see if I can think of an example. So, for devs, under those circumstances, when they’re being involved in responding to an incident, it can be stuff as simple as being really clear in their application logs.

    So, if you think about events that are generated by, say, a container-based app deployed on Kubernetes, okay, so the event and incident management system is gonna be presented with logs from the app code; they’re gonna be presented with logs from middleware; logs from Kubernetes itself; logs from, potentially, external technologies and monoliths – NFS mounts, databases, legacy apps, network; and they may also be getting alerts from monitoring systems that are watching performance metrics for the running container, so transaction request rate between micro-services, CPU utilization, response time.

    So, if devs can make sure that something as simple as the concept of criticality or severity is included in the logs, that really helps with filtering _____ ops figure out whether or not something’s really a problem. You know, for example, is this event classed as a trace message? A debug message? A warning? An error? Is it known that this is service-affecting? Right?

    Alan Shimel:               Yeah.

    Kristian Stewart:         And, you know, how better to motivate devs to implement those sorts of practices than to make them consume log messages that are completely uninterpretable, right?

    Alan Shimel:               Agreed. Agreed. Hey, Kristian, we’re over time already, but, as I told you before we started, the time here goes quickly. But, you know, boiling all of this down, the last – whatever – 18 minutes down, really, I wanna make the point of – and I loved what you said about ops shift left, dev shift right – that our ops and devs can work together. And, as you said, they each will have different reactions with different roles and responses to given incidents or given stimuli, but they can work together and we can build on what ops has built over the last 50 years of the IT industry. And –

    Kristian Stewart:         Mm-hmm.

    Alan Shimel:               Right? We don’t leave that at the door of DevOps; it’s part of it. And one thing I want – you know, if we can ask people to take that with them. And you agree that’s key takeaways here for them?

    Kristian Stewart:         Absolutely. Couldn’t agree more.

    Alan Shimel:               Fantastic. Hey, Kristian Stewart, IBM, thank you for joining us on this episode of DevOps Chat. Love to hear more in the future about what you and the IBM team are doing around cloud and hybrid and some of the other stuff kicking around. And we’ll have you back again soon, but, for now, thanks for being our guest this episode.

    Kristian Stewart:         Alan, it was an absolute pleasure.

    Alan Shimel:               Great. Hey, this is Alan Shimel, everyone, for devopsy.kinsta.cloud, DevOps Chat. Thanks for joining us and we’ll see you soon on the next chat.

    — Alan Shimel