IBM i DevOps TechTalk
Strategy to move to a more modular code and Microservices #15

Ray Bernardi – Welcome to IBM i DevOps Tech Talk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi and I’ll be your host today. Today we’ll be speaking with Andrew Clark. He’s the DevOps product manager here at ARCAD. We’ll also be hearing from Nicolas Delessio. He’s a senior DevOps consultant here at ARCAD. Performing the interview today is Alan Ashley.
He’s a senior solutions architect. Today’s topic is how to take monolithic code and turn it into microservices. Alan will be conducting the interview today.

Alan Ashley – So Andrew, we’ve heard a lot about microservices and dealing with modernization. On the IBM i of really recent days, can you explain what microservices are?

Andrew Clark – Sure. So microservices is just a fancy way of saying that you expose certain pieces of your code to the other parts of your application. So in other words, in RPG speak, what we do is we take some key specifications. Could be a subroutine, could be a procedure, or it could actually just be in your mainline code.
It has some kind of a business function in it. It might be calculated texts or it might be starting or something like that. Whatever your business functions are. What we need to do is we need to take that code in the form that it is today, and change it so that it can be used by other things.
And other things might be a rest API, it might be SQL. So really what this does is it takes your existing code, which is often a monolithic code base and makes it so that other parts of your application and organization even can use them. So for instance, you might have IBM i developers and you might have web or front end developers and the web and front end developers know nothing about the IBM i.
So if you use microservices, you can create APIs, you can create SQL services, you can create Restful APIs. Any kind of interface to your existing code is what we call microservices.

A.A. – Now with these microservices, it sounds like there’s some advantages here of maybe multiple groups being able to tap into users codes. Is that what we’re really striving for here is to take advantage of that. And what are some of the other advantages of using microservices and pulling out these little bits of code?

A.C. – So when you move to microservices, all those things are correct. When you move to microservices, what you’re doing is basically taking a lot of times, you’re taking monolithic code which is hard to maintain, hard to organize, hard to describe, and move it into software describing functions. You might have a block of code that does your order entry, but then you could actually move it to a microservice where it’s actually called order entry.
You have distinct, easily recognizable parameters that come into your function, and you have distinct values, equally easily recognizable values that come out of that function. And so it’s almost self describing in some way. So there’s an immediate advantage to the IBM i developer in your existing code base. But the real advantage to microservices is exposing it to other groups and other applications so that they can consume those services. Today lot of times what will happen is they’ll be duplicate code. They’ll be code on the IBM i that does a certain function and because it’s impossible to access from other places from the web or mobile or whatever, they’ll just rewrite the function. And that makes no sense. You want to have one code base that does the same thing inside your organization.
And, the IBM i is such a great transaction machine, and it works with decimal arithmetic so much better than other machines. There’s actually a performance advantage to that as well.

A.A. – Now, is this where using a RESTful API is this kind of the end result of that?

A.C. – So when we talk about microservices, there’s some kind of interface to those microservices that’s exposed to other parts of your application or other parts of your organization. So the RESTful API is probably the most common API. So that’s just, Http interface. That’s what RESTful is. So it’s a basically a web interface that you pass certain well-defined verbs to the RESTful API.
So a lot of code bases will actually automatically create RESTful API structures around your microservices. So if you define one, the entire you can define it one time, and then the rest API just kind of creates itself. There’s create, read, update, delete kind of things from your RESTful API. So if you define it in a well organized way like rest, then you can automatically create kind of this whole structure around it.
But RESTful APIs aren’t the only thing. Like I said, you could use something like SQL functions or SQL procedures. The IBM i does a great job of exposing program code to SQL that many other operating systems don’t. In fact, it’s the best that I know of to be able to do that. And, you could use other things, you could use XML, you could use JSON.
Really the possibilities are limitless. It just depends upon your organization to what kind of data you need.

A.A. – Ok. And so before we kind of move on as the best way to get there, I’m sure there’s like an incredible ROI on this in that moving from this monolithic code. And you even mentioned maintaining two separate code platforms because it’s doing the same thing. You just tied the two together. Can you talk a little bit about the ROI on moving to a microservices?

A.C. – Yes. So this is the fight in the IBM i world for a long time. You’ve got to move to these modern development techniques and organizations and to be able to take advantage of modern development practices. So, this is what IBM has been calling like next gen applications.
Microservices is part of that. So reorganizing your structure so that you have well-maintained modular objects immediately gives return. You know what we call a shift left in ROI because you can easily identify issues and where exactly they are, when that code is embedded inside of your monolithic code. A lot of times it becomes hard, almost impossible, to narrow down exactly where the problem is.
So that’s just purely from the IBM i perspective. But the ROI, like you mentioned, is even more important when you’re doubling the code base. That makes a maintenance nightmare when a change has to happen. For example, you have a change into two code bases. And just from a purely conceptual standpoint, it makes sense. Obviously, you don’t want to maintain to go code bases, and you want to do it in the place where it makes the most sense.
And the other big advantage in the IBM i world is helps to justify the IMB i. You might have see level organizations that want to move away from the IBM i because they don’t have a way to access that business logic. If you can create these microservices, that’s a huge cost justification to leave being 30 years of established code, well-proofed code, instead of trying to move that, as long as it can be, exposed to other parts of the organization.

A.A. – All right. Nicolas, we’ve heard a little bit from Andrew here on microservices and kind of the importance of the microservices and converting your code from this monolith aspect of things. What can ARCAD do to help the developer migrate to or move to a microservices environment?

Nicholas Delessio – Well, ARCAD has developed a product called, TMS or Transformer Microservices, which helps with the two main areas here that developer is going to tackle when they’re doing this. And that’s analyzing the existing monolithic programs on the box, and then actually creating the microservices when they’ve determined what code has to be ported over.
TMS allows you to go into one of these monolithic programs, select a snippet of code, and then run analysis, which will trace down essentially what all of the fields in that program block are using. So it’ll determine if those are written to or read from anywhere else in the program. It’ll display all of that information in a way that’s easy for the user to see.
And then that will help the developer determine if that’s the right block of code to pull out or if they need to reanalyze what they’re working on there.

A.A. – So it sounds like when you’re talking about the going through this analysis and it’s pulling out different links to fields and different files, and it’s referencing to all those. If you did this by hand or manually, I guess you’d have to scan the entire code, all 10,000 or 800O lines of it or whatever the case may be.

N.D. – Yes, it’s a very tedious process doing it. And a lot of times what happens is that it becomes such a big project that it never happens. So in a lot of cases, having this part of the analysis more automated allows the project to even happen in the first place.

A.A. – And I know when you’re going through this analysis and you’re building out this microservice and I know this is a new thing for ARCAD, a new product coming out and I know from what I have seen of it, it’s really impressive on being able to show you the analysis. And that’s what really got me when I first saw it presented was how it broke down through that little snippet of code that was selected and said, hey, by the way, if you change this, I’m going to help fix it all here too.
And you can see all the lines that were being removed from your code, which in essence makes it more efficient from that. So you get some efficiencies out of it, some performance value out of it. And you also now have this new procedure, this microservice that can be used by other parts of your application. Is that kind of the path that we’re going down here?

N.D. – Yes. It analyzes everything. It lays it all out. And when you’ve decided that part of the code needs to be cut out, then it will lay out the procedure or service program that’s getting created. It’ll show you everything it allows you to change. It put parameters, values and orders. It allows some level of customization there.
And it more or less does that part of the work for you after you’ve done the analysis.

A.C. – From a technical standpoint, one of the really nice things about TMS is that it actually extracts that code into a separate module or service program if you want it. And so that’s a huge advantage over something like RDi, where it does the extraction. They have an extraction function, but it does it within the same source member.
So this creates a copy member that can then be embedded into any other programs. And so it’s immediately available to use in other parts of your application, which gives it a huge advantage over something like RDi.

R.B. – Guys, I know we could probably go on for hours here, but I have to jump in because we’re starting to reach our time limit on a Techtalk. It sounds like there are some definite advantages to converting monolithic code into microservices and ARCAD new product transformer microservices is ready to do that for you.