Episode 31: The Hybrid Cloud Forecast - Outlook: Anniversaries

Anncr.: You're listening to the Hybrid Cloud How- To Series with host Andre Tost, brought to you by IBM.

Andre Tost: All right, welcome everyone. Thanks for tuning in to this episode of the Hybrid How- To Series. Today we want to talk a bit about application development in the context of hybrid cloud, and I have the distinct pleasure to have Kyle Brown with me. Kyle is an IBM Fellow, one of IBM's best and brightest; has been working in this space for many years, if not decades. Thanks for joining, Kyle. Welcome.

Kyle Brown: Thanks, Andre. Glad to be here.

Andre Tost: Maybe we should start out by just quick introductions. Tell us a bit about yourself, how you get to where you are today, a bit of your upbringing.

Kyle Brown: The place to start is that I have been a Java developer since there was Java. But I actually came to Java from Smalltalk. I was one of the few developers in the late'80s and early'90s that had joined the Smalltalk wave as that started up. And the great thing is I was able to make a lot of lasting friendships through that time, with folks like Martin Fowler and Kent Beck and many others that have gone down to have much more luminary careers than I have. But the good news is it taught me a lot of really good habits that I was able to bring forth into my career as a Java developer. And later on, as I came to work for IBM as a consultant for a brand- new product that we named three weeks after I came on, that we decided to name WebSphere. So what's happened from there is that I was one of the first WebSphere consultants for the brand- new WebSphere Lab Services Team. And I helped build a lot of the initial best practices and patterns that are still being used in Java programming today. I literally wrote the book on WebSphere. Literally; it's sitting here on my bookshelf above me, Enterprise Java Programming with IBM WebSphere. I've since moved on from just Java programming into a whole bunch of other things that have emerged from that: starting with services- oriented architectures, where you and I spent an awful long time together, Andre. And then moving on to various things in the cloud. And what I've been doing for the last few years is I've really been majoring in helping to understand what it means to have programming models and application development approaches for the cloud. And especially, how do you modernize existing applications to run effectively on the cloud?

Andre Tost: Cool. I haven't heard anybody say Smalltalk in a long time. Could you still write a program in that? Is there even tools still around?

Kyle Brown: Yeah, there is, actually. You can go download Squeak Smalltalk, which is an entirely open- source version of Smalltalk 80. And believe it or not, just the other day I was in Squeak writing a program; first of all, just to remember that I really can do it. But also because honestly, it's very hard to find something that's better at certain tasks like parsing and making sense out of data. The same way that a lot of people use Python, I still use Smalltalk when I'm actually just wanting to parse through all a bunch of data and then generate a bunch of CSV files.

Andre Tost: All right, very cool. You already mentioned a whole bunch of topics that I think we want to dive into a little deeper as we go. But before we do, one thing I ask at the beginning of every episode is, let's settle on and agree on a definition of hybrid cloud. What does it mean to be in the hybrid cloud, to build a hybrid cloud, to create an application for a hybrid cloud? What's your personal definition of the term?

Kyle Brown: It's funny, because the way that I often start with defining the term, is I start by setting it apart from another term. And these are two things that are often used sometimes interchangeably, even though they really mean slightly different things. So it's best to talk about them together: and that's hybrid and multi- cloud. All right? What multi- cloud means I want to be able to write a system that at least can run in whole or in part on multiple different clouds: meaning I could write a system that has components on AWS, components on Azure, components on the IBM cloud, and components on Google. Or, take an entire program and run them on any of those four things. Then what hybrid means, when I'm considering it, is hybrid is an extension to that, to where we're building systems that have components that are in the public cloud. But they're also in on- prem systems in various different combinations. Now, that could be an on- prem private cloud, something like OpenShift, running in a data center that one of our clients owns. Or it could be running on a mainframe, a Z series system. Or you could have components that are running in, let's say, traditional IT technologies like WebSphere ND. Any combination of any those, brought together with one part being cloud; private, public, doesn't matter, some combination. That is what I mean by hybrid. And you have to be able to make sure that you're delivering value with all of those parts. And you're integrating all of those parts to really make sense out of what it means to build a hybrid cloud system and a hybrid cloud architecture.

Andre Tost: I guess another set of terms that applies then is to say; since we're talking about applications here; are these applications portable across different places? Are they connected? Are they fully integrated across different places? And I guess hybrid cloud is all of the above.

Kyle Brown: It really is all of the above, because you've got to think about it in terms of components. Now, let's say that you've got a front- end component. And your front- end component, let's say it's just JavaScript and Node. But it's using HTML and CSS and JavaScript on the client, just like everyone does these days. Well, that component, since it's all written on open- source technologies, may be fairly easily portable or very easily portable to any public cloud. Or you could run it on an on- prem cloud; that's totally fine. And decisions like use of open source and use of common open APIs are going to help you with that. But then again, that's not the entire application. We'd like to think it is, but it's usually not. You still have to deal with things like databases and existing systems and existing transaction systems. And so that's where that connectivity effect really comes in and becomes super important.

Andre Tost: Let's talk about application architectures a little bit, which is what you just said leads into. I guess, what it comes down to is the architectures that we're seeing enterprises run are all over the map. They're old and new and everything in between. Is that what you're seeing, too?

Kyle Brown: Absolutely. There is no one cloud architecture. That's the one thing that I have to correct people on when they start thinking about what it means to run on the cloud, or be part of a hybrid cloud architecture. There's a myriad of these things. For instance, I talked about one particular aspect that you commonly see: which is going to be that you're going to have a front- end architecture probably written in JavaScript and Node. Or it may be a mobile native application that you've written in Swift for your iPhone. Or it even may be something like a chatbot. And if you're really talking about a chatbot, you're probably talking about something that has been built to use cloud provider- specific technologies: things like the Watson technologies that we have available on the IBM cloud. That's just the front end. Well, then as you move behind that, then you have to get into, well, where are you going to be running your business logic? What language are you going to implement that in? And then how is that going to connect to things like back- end databases, back- end transactional systems? And are you going to be bringing in things that are going to be really part of a more modern architecture, like events? And try to connect things more loosely and with less coupling?

Andre Tost: So if I start at the very beginning, or the beginning of my career, we started saying, " Applications are built following a three- tier architecture." There's a front end, there's a business logic piece in the middle, and then there's the back end that has the data. That was the structure of most applications.

Kyle Brown: Sure.

Andre Tost: And there's so many of them around today still, obviously. Now, the question being, can I run an application like that in the hybrid cloud? Or what does that even mean?

Kyle Brown: That is a really interesting question. Because it turns out that yes, you can run that in the hybrid cloud. I can give you two different ways in which that would work. One being, let's say a more traditional way, and one being a more modern way... or at least a more flexible way. The first answer is, yeah. If you've got a traditional three- tier application that's running in, let's say, WebSphere, maybe uses MQ, things like that, there's nothing to stop you from containerizing all of those existing pieces of what you might want to call a monolith, and just run that in the cloud. I mean, it'll run an OpenShift today on any of the public clouds right now. In fact, that's a really low barrier of entryway of getting some parts of your systems running on the cloud. Sure, that's terrific. But is that really going to be the thing you want? Or do you want something that's maybe a little more decoupled? Well, that's where you start thinking about... Well, what are each of those tiers that you talked about? Your client tier, your business logic tier, your data tier? What do those look like when you start thinking more in cloud native terms? Well, we've already talked about how the client tier could be something like JavaScript and Node, more modern application architectures upfront like that. In fact, the whole idea of breaking up a big monolithic front end into something like single- page applications or SPAs, and even micro front ends is probably the way that I think most applications are really designed today on the front end. Well, if you just take that idea of breaking things up into smaller and smaller pieces and you extend that to your business logic, well, hey, that's all microservices are. They're just smaller pieces of business logic that are going to be easier to test and easier to maintain. And you can extend that back into the back end, away from monolithic databases into smaller, maybe cloud native databases, things like MongoDB and Cassandra and things like that. Those can either run in containers on your own, or you could use the facilities that are given to you by your cloud provider. All of these work, and it essentially has the same overall structure at a 50, 000- foot view. But it's not until you really get down to the details that you start to notice the difference.

Andre Tost: I guess what you're saying is that modernization is a big part of getting to the hybrid cloud world; is that it does not mean you need to leave your old applications alone or rewrite them all, based on modern architecture. There are more cloud native, but there is things that we can do with that existing application landscape that's in place.

Kyle Brown: There's two modernization myths that I think it's probably worth dispelling right up front before we get to what that really means. The first is, like you said, the first thing you can do is you don't have to change anything. You just lift and shift everything you got into a public cloud, and you're on the cloud. Well, technically that's true. But you're really not gaining any of the business benefits of the cloud if you're doing that. Not only that, but your applications were probably built for a particular set of assumptions around high availability and around reliability, and things like that that may not apply in the public cloud. Let's face it, VM's uptimes in the public cloud are not necessarily the same as a VM uptime on a carefully maintained piece of hardware that has been around for decades. Okay? Well, the other myth is what you also pointed out that, " Oh, you just got to rewrite everything. It's all got to be completely different." Well no, you don't have to do that either. There's this whole space in the middle between these two that is going to help you with your goal of what you really want out of modernization. I mean, what do you want out of the cloud to begin with? Well, basically it comes down to three things. You want your systems to be maintainable. You want your systems to be manageable. And then you want to be able to make sure that you can extend them and add new features at the rate and pace that your business demands. Well, modernization is about achieving any of those, or all of those, and making whatever changes it needs to make your system to be able to meet your goals for your SLAs, in terms of how you can maintain your systems and what you want out of your other performance and reliability SLAs. And then what it takes for your teams to be able to be productive enough to be able to meet business's needs in terms of creating new features.

Andre Tost: I suppose a big element of that also is just being able to decompose applications into elements that I then can attack individually. And why I'm saying that is because I've heard customers say, " The biggest problem that we have with moving our existing applications to the cloud is that everything depends on everything. We cannot start small and then grow."

Kyle Brown: Absolutely. I've seen a lot of that, or a lot of that complaint occur before. Now, personally, I have never seen that to be 100% true. I've seen it to be more or less difficult to be able to make these distinctions and to be able to cut things up. But I've never seen a system that absolutely can't be moved. There's an old pattern that Martin Fowler originally thought up way back in the early 2000s, before we were even talking about clouds or were even talking about microservices. This is the idea of what he calls the strangler application. And the strangler application is just the basic idea that you can separate out functional areas of a system, and over time move them to a new system: which in our particular case would be running in the cloud. But you keep both systems running side- by- side during that entire time. And that coexistence phase; which, by the way, can and usually does take years for a lot of these kinds of large- scale enterprise systems; is what I think people have problems dealing with. Now, the good news is that we've found lots of tricks that can help you both in identifying those functional areas, and figuring out how to take those functional areas apart into more maintainable pieces. And then especially in how to take all of the various pieces and implement them in ways that are going to be more flexible and are going to be less coupled together, so that you can move them to the cloud more easily than if you left everything tied together in the same monolithic hairball.

Andre Tost: Let's move on to a different topic that I think is relevant in this context. One of the characteristics of cloud computing is a higher degree of automation overall. And what that automation brings with it is the ability to bridge that divide, if you will, between the developer community and the operational community within an enterprise. So the people that are writing and developing the applications, and the people that then need to keep them up and need to operate and monitor them and maintain them over time. Obviously, what I'm talking about is DevOps. And more and more now, I think we're starting to talk about DevSecOps because security plays such a big role in that. Could you comment a bit on how do you see DevSecOps influencing some of the things we're talking about here, in terms of modernization plays and hybrid architectures and so forth?

Kyle Brown: Absolutely. One of the things that I wanted to make sure that I start off with is that any of these modernization steps that you're taking; be that taking an existing monolithic application and containerizing it. Or if you're really trying to apply Fowler's strangler pattern, and you're really trying to break something apart, maybe even all the way down into microservices. Or even if you're just adding new infrastructural features, things like Kafka and an event- based architecture, these are all going to require you to have a much tighter collaboration between your Development and your Operations Team than you would in a more traditional IT infrastructure. So for instance, one of the things that we suggest even for the first option, which is just containerizing existing applications, is that what you really need to do is you need to start building in DevSecOps pipelines: not only for the application delivery, but also for the infrastructural delivery. Not only would it be doing things like making sure that your DevSecOps pipeline for your application is, in the end, going to deliver an immutable container that's going to be the target of what you're going to deploy into something like an OpenShift. But you want to make sure that the process of doing things like setting up your OpenShift and being able to release new components into that, or being able to do updates and things like that, are also controlled through a DevSecOps inaudible And in this case, we're getting to something like a getops kind of approach. So the automation is absolutely critical. But it's not just the automation. You can't just take your existing teams and move them into this new kind of working with automation through DevSecOps pipelines like that, and expect everyone to keep their same roles. You really need to foster a much tighter collaboration. And that's where especially we've had a lot of success in the IBM Garage, where I've spent a lot of years in terms of introducing SRE practices: ideas from Site Reliability Engineering into the development teams that we have that are building not just the applications, but building these platforms like the Kafka and OpenShift platforms that I'm talking about, either on the public cloud or in private cloud. You have to make sure that it's someone's job to really own this automation, and that that automation becomes part of the user stories that you're building out not just for each of the individual applications, but for the platform itself.

Andre Tost: You just actually mentioned containers for the first time. We haven't really gotten into that too much. But my question, I guess, is just how much do containers matter in this world of application development and applications running in hybrid cloud? What makes containers so interesting?

Kyle Brown: The way that I look at it is containers are table stakes. They are the minimum you need to be able to move to really be able to take advantage a lot of the things that hybrid cloud is going to give you. I've seen many companies try to succeed just in terms of using VMs. And I'll tell you, the problem with that is that it takes an awful lot of discipline just to be able to re- create the same things that containers, and especially container orchestration environment like Kubernetes, honestly give you out of the box. I mean, if you're basically going to be working in VMs, then that means that you're going to have to create the capability, or probably an entire team, to create off- the- shelf VMs that are going to be your starter kits. Then you've got to build an awful lot of automation in terms of scripting things and technologies like Ansible or Chef or Puppet or something like that to be able to set up all of the things inside those off- the- shelf standard VMs. And then comes the hardest part of all: how do you keep people out of these VMs once you've created them? Because the problem is drift is always going to happen. You're always going to get someone who's going to want to SSH into a VM, and they're going to change something subtly and forgot they do it. And what's going to happen is that means that over time, the VMs that you've actually got running are going to slowly drift over time away from what you think is in them. Well, the thing's containers avoid all of that. They really give you much more enforced discipline than you can get in a VM environment. And it really helps you to be able to move to that quicker DevOps pace.

Andre Tost: So are you saying that containers are more immutable than VMs? Or at least that there's a culture of you'd never log into a container and mess with it, so to speak; whereas with VMs, it's almost implied and expected?

Kyle Brown: Oh, absolutely. It is almost implied or expected that you're going to be going into a VM, and you're going to be making patches and you're going to be modifying them. Containers: it's possible to log into a container. But by golly, Kubernetes and containers make it hard to do it. You have to actually think about how you're trying to do it. And it's a lot easier to enforce the kinds of immutability that we're talking about in containers than it is in a VM environment. That's why I call them table stakes. It's like if you can begin by moving to containers, it's giving you some operational stability that you just can't usually get in a VM environment. And that's going to move you much farther along the line of the three things we talked about: of being able to maintain your systems by making them more stable, by being able to manage them better, by making sure that you have consistency across them. And again, getting to the point to where, " Well, that's out of the way. Then we can focus on the hard part," which is actually adding new feature.

Andre Tost: I've seen lately that there's more focus on even a separation between building and maintaining the container, and building and maintaining the application code that runs in that container. To have that separation of concern even on the development side, so to speak. And I think what that's going to get us to, ultimately, is to run things as we call it serverless. Right?

Kyle Brown: Yeah.

Andre Tost: And serverless obviously doesn't mean that there's no server, right? It just means that I, as the person maintaining the code, do not have to worry about the servers anymore, because they're just there when I need them. And I think containers help with that as well to say, " I can dump my code into containers, but I don't need to treat the container as a first- class element anymore." Would you agree with that? I mean, do a prediction of the future and what it holds in five years from now. Is serverless going to be the predominant style in terms of writing applications?

Kyle Brown: It's interesting, because you're getting into an argument I've been having on the internet on Twitter for the last several weeks: about do microservices as an architectural style have anything to do with containers? And as you can tell from the argument I've already made, I believe they do. That containers are the table stakes to be able to be successful with a microservices architecture. Now, what about serverless? Well, what serverless is really doing, as you've pointed out, is it's extracting things yet one more time to where all you're doing is really providing your code, and then letting the infrastructure figure out how to run your code. Now, in many of the modern systems we have like Knative, what it's actually doing is it's actually using a container underneath the covers to do that; whatever. All you care about is just providing your code and making it run. But what happens is that that also changes your programming model. And it changes the way you think about things, especially as you think about many of the more popular serverless examples like Lambda or Knative and some of the other things that we see there. One of the things that you see is you see, whereas with microservices, we were really trying to take an entire business concept and get it down to one single deployable unit. With serverless and Knative and Lambda and things like that, it's taking it down one more level to what's just one particular aspect of a business transaction, or one particular aspect of a business concept. So you're moving from this microservices idea to more of a nanoservices idea, to where each of those are going to be independently replaceable and independently modifiable and deployable. So yeah, I do eventually see a lot of development going that way. But I want to pause right there and say I don't see all development going that way. There's certain use cases for which serverless is absolutely fantastic. In particular, the kinds of things we used to do Batch in the old days with; actually, if you're doing simple crud, serverless is absolutely terrific for that. Where it really starts to fall down is when you're really trying to do complex interrelated business logic, and you're really doing domain modeling. That makes it a little more complicated, and that's where instead, I think something more like a microservices approach is probably going to be better. And that's why you're still going to end up with this kind of spectrum for monoliths, all the way down to serverless. And I don't think we're ever going to see one of them be 100% of anything. Who's going to get that entire spectrum?

Andre Tost: I guess there's good news and bad news in this. The good news is there are some new cool, exciting things happening. The bad news is none of the old stuff goes away, it seems. We're inheriting all of it and we're adding to the equation now, which doesn't necessarily make life easier. But it also means that nothing becomes obsolete, right?

Kyle Brown: Absolutely. And let's face it. I know teams that are being incredibly effective, and they're working in agile ways, with really short sprints and being able to have really good project velocity, and using modern DevOps tools. But what they're delivering is COBOL KICKS applications. If the team can do that and they can meet their management and their maintenance and their functional delivery dates, more power to them. They don't need any of the rest of this stuff. It's really down to what does your particular team find to be most productive, and to allow you to keep your team independent and autonomous, and to really be able to meet the delivery constraints that we've talked about?

Andre Tost: Actually, that's a good lead- in to the question I was going to wrap up our conversation with; and going back to what we started with, programming languages. We started out talking about Smalltalk, and we just said, " Nothing ever goes away." My final question being about what are the languages that you see predominantly being used? Has that even changed? Is it still Java for the most part? But then you can bring all kinds of other things to the table? And it doesn't really matter in the big scheme of things, which language you choose to write your logic in?

Kyle Brown: I would say that it doesn't matter in the big scheme of things. But there are certain languages that seem to be better suited to doing some things than others. For one, we've talked extensively already in this talk about JavaScript on the front end. JavaScript is a terrific language, because it can run in the browser, and it can run on the server side. And that kind of flexibility in exchanging JSON and really just keeping the same semantics up, has really been helpful. And a lot of teams have really succeeded with that. But at the same time, I really have yet to find a single application development language that is better, other than Smalltalk, than Java for writing complex business logic. Now, one of the problems I have with Java; by the way, I'm not 100% a fan of it; is it keeps getting more complicated over the years. And sometimes I think what someone needs to do is actually pare down about 80% of what's been added to Java over the last 20 years, and create a smaller, simpler language as a result. But it's still pretty much predominant for writing those kinds of business logic. Just like, to be inaudible COBOL is still prominent for those exactly same kinds of problems. But what we're also seeing is that there's yet one more aspect that is growing leaps and bounds: and that's data science. If you're doing the kinds of things that I was telling about using Smalltalk for, which is actually just taking in lots of data, doing parsing, doing cleansing, doing manipulation, and then taking it to the next level, being able to train ML models and do things on that: honestly, Python is the easiest choice for a lot of that, especially when you start getting into some of the AI workloads. And so most of the kinds of applications that I'm seeing end up with a mix of all three. You end up with lots of Python on the data science end, which is a big part of more and more applications. You end up with some core Java logic or some core Node logic. And then you end up with a lot of JavaScript on the front end. And I think that's probably going to continue to be true for a number of years.

Andre Tost: Yeah, this just made me think. My son is a physics major, and he's doing some programming. Most of it is in CPlusPlus, because it seems like all the libraries that they're using are written in CPlusPlus. That's kind of the language of choice in that domain. So there may always be languages that are specifically geared towards certain domains and functionalities, I suppose.

Kyle Brown: Exactly. Just like we used to have FORTRAN; that's now pretty much translated into two different sets of things. We used to use FORTRAN for the kinds of scientific and engineering applications that now we use CPlusPlus for. And we used to use it for what we would now call data science, and now we're using Python for that.

Andre Tost: And one thing remains is that COBOL will never go away.

Kyle Brown: COBOL will never go away. You will never get rid of it. Learning COBOL is always a good career move for anyone if you want to have job security.

Andre Tost: There you go. Let that be the final statement. I don't want to hold you up much longer. This was fantastic insight. Thank you so much for the comments.

Kyle Brown: Thank you very much, Andre. Appreciate being here.

Andre Tost: And that wraps up today's episode. Thanks for listening, and see you all next time.