Aaren Quiambao

Welcome to Coding over cocktails, a podcast by Toro cloud. Here we talk about digital transformation, application integration, low code, application development, data management, and business process automation. Catch some expert insights as we sit down with industry leaders who share tips on how enterprises can take on the challenge of digital transformation. Take a seat. Join us for a round here are your hosts, Kevin Montalbo and Toro Cloud CEO and founder David Brown.

Kevin Montalbo

All right. Joining me as always is none other than Toro Cloud CEO and founder David Brown. Hi, David. Good to have you on. 

David Brown

Hi Kevin, Thank you. 

Kevin Montalbo

Alright. And our guest for today is a software architect and director at Thoughtworks based in the UK. As a member of the Thoughtworks Technical Advisory board, the group that creates the technology radar, he contributes to industry adoption of open source and other tools, techniques, platforms and languages. He's an internationally recognized expert on software architecture and design and on its intersection with organizational design and lean product development. Most importantly, he also defined the microservices architectural style back in 2014, which we'll be talking about today. Ladies and gentlemen, joining us for a round of cocktails is James Lewis. James. It's an honor to have you on the podcast. How are things?

James Lewis 

Really good. it's an honor to be invited. So thank you very much for the for the invite. Yeah, you find me, you find me in a very rainy London or near London sitting in my shed at the bottom of the garden, which was my my lock my first lockdown projects during the pandemic. So I converted my office into a shed, so I'm now in mission control there.And yeah, it's been, I mean, it, it's like, like everyone, it's been very, very strange. You know, a lot of my job has been,, I wouldn't say,, has gone but a lot of my job was involved, travel to conferences and public speaking and, you know, I've been really an evangelist for thoughts over the, over the last few years and all that sort of disappeared. Really. So, it's really great to actually be invited on to things like podcasts where we can talk about these things because I think everyone misses it, don't they? But yeah, thanks. Thanks for asking.

David Brown 

And I like your party lights too and your shed.

Kevin Montalbo

All right. So let's jump right in. So, together with Martin Fowler, you were responsible for coming up with the concept of microservices. So, in the past seven years, since its exception, have you seen the use of the term and the concept evolve from what it initially was?

James Lewis

Yeah, I mean, the short answer is yes.Martin Fowler. And, but I think, I think, I think actually that's not so bad, right? So naturally things evolve and I'll, I'll come to, I'll come to that in a second. But there, there's, I guess there's two types of evolution in, in a sense there's, there's building on what we have in the past, you know, there's this idea of you have scientific revolutions and then you gradually build on those ideas until you have another revolution.And that's, that's kind of fine. But then there's another type of evolution which is, should we say like a kind of bad type of evolution. Martin Fowler talks about this as semantic diffusion where the term or the thing starts stops meaning what it originally meant and starts to mean something else. So you could talk about for a long time, agile, you could talk about the, the, the phrase agile being semantically diffused where it started to me to be synonymous with Scrum and sprints and commitments and this kind of stuff, which actually that's not what agile is about at all.

So, I mean, with, with microservices. Yeah, absolutely. I think things have changed but I think it's been a good change. I think it's, I think things have evolved in a, in a, in a good way. And the reason I say that is because, you know, we're all really looking back at micro services and that, that definition, I think it was, it was almost like a, like a meta paper for like a scientific, you know, for research in the sense that it was gathering a whole lot of good things that people were doing at the time. You know, it's almost a bit like XP. It's like you take all the practices and you turn it all up to 11 in extreme programming. That's the, you know, the old joke about that.And I think microservice is, is the same. If you look at the individual components, they were all there around, you know, and had been and been built on for a number of years. So, I guess you could, you could pick up things like the products over projects and organized around business capabilities. Those are the principles or characteristics and you can see their origin in things like domain driven design. You know, you can see the, the the the origin in, in, in, in concerning ourselves with the business aspects of, of the problem we're trying to solve as opposed to like the layered tech, technical aspects or whatever.

Or if you look at things like, you know, end points in, you know, smarts in the end point and not in the pipes, then you know, that that's an evolution of how we'd sort of come to view rest or, or web integration as almost the holy grail of, of decoupling in the sense and, and you know, the, the, the the best type of, of integration over over say, you know, enterprise service buses or smarts in, in, in your infrastructure where, you know, things tend to end up being well, you end up with stuff smeared everywhere. So it's not very cohesive and you end up with, you know, with tight coupling all across the place. So, so I think it's, you know, it was an evolution of these ideas, you could say it's an evolution of Jim Weber's gorilla ss O A which, you know, if you haven't seen this, there's a great talk he did with Martin Fowlersome, some time, well, years ago now at Q I think it was a keynote called Does my bus look big in this about his idea of gorilla. So, a which is, you know, it was the antithesis of the Big Bang. We'll, you know, we'll, we'll go away and design your service oriented architecture and then come back three years later and you know, it will all be done, you know, which never, never worked, never happened.And yeah, and so the gorilla, so a idea was to do was to build out things in slices based on value. So I think it's, it's all been an evolution really. And it's all based on these, these giants that came before going back four years to UNIX, you know, in, in essence. So, I don't know if you've got any, any, any thoughts about that as well, but that's kind of how I see the evolution.

David Brown 

It's interesting, isn't it? I mean, we talked about that interpretation of agile just on a couple of podcasts ago in terms of the meaning of agile has changed the interpretation of what agile means now is so broad, it's probably diffused from its original concept. So you said micro services is being interpreted in a similar sort of way. How are people using the terminology? Which wasn't really envisaged by you?

James Lewis 

Yeah, it's I mean, just a, a sidebar on, on agile. I mean, agile for me, I can tell you, I mean, I've been working for Thor Wicks now for 15 years and I was doing XP before Thors, before I joined Thor Wicks, I've been working in an agile manner for a long, long time. And all agile means for me is is, is three things. It's small batch sizes, fast feedback, and discipline. And if you do those, if you've got those three things, that's essentially agile for me.But in terms of, in terms of, in terms of microservices. Yeah, I mean, well, iii I think the original, the spirit if you like of microservices was around,it wasn't so much a microservices have to look like it was more that the spirit of a microservices architecture is to take good architectural practice and then essentially take it to the extreme with a set of constraints, these principles guiding you.So originally, there were things like, you know,it's very much like the 12 factor A apps from Hiroko Those, those constraints and principles, they came out practically the same time as we were doing the 1st set of sort of micro services architectures in th works and, and Netflix was doing it and, and, and so on in the guardian. And that,and, and, and that those that the spirit of microservices was to, was to, was to well, was to build well architected evolve, well architected systems based on these small components where, you know, where you took the idea of single responsibility principle, almost like to, to to extremists, right? So, you know, we, we talk about turtles all the way up and down, you know, so a method in object oriented languages, a method has a single purpose, single responsibility, a class is a single responsibility.

A name space is a single responsibility, you know, so a package and then, you know, a a library or, or an application has a single responsibility and then you, you, you sort of scale those up to be commuted until you are at the level of a business capability which might be represented by a number of microservices interacting. But the key thing is it was that, you know, you had these, these small things that were well that were well designed using, using standard patterns, using standard integration patterns. I think what it's come to me now, in some senses, it's crystallized more, it's, it's more it's more of a firm definition. People tend to think of microservices in a number of ways. They tend to think of them as noun services. You know, I'm gonna have a I don't know an order service or a product service or a user service, these kinds of things and they're connected together in a, in a dag, you know, directly graph.And that's, that's actually the sort of, if you look at the sort of squint bit and look at what Netflix used to do, it was a little bit like that. Not quite, wasn't quite names, but they had this, this graph of stuff where 11 thing we call another, which we call another, which we call another. And that's fine. And you know, you can do that as long as you have, as long as you, you put in place the appropriate you know, patterns to s to, to solve for availability, right? And reliability cos the problem with, with deep call chains is the service at the top. The availability is limited by the, the the product of all its other calls.So if you, you know you this, I think this is called the multiplicity multiplicative effect of downtime if you've got one service at the bottom,or if you've got one service called five other services that its availability is limited by the sum the product of the availability of the other services. So that's, that's why you end up with all these circuit breakers and all this kind of liability stuff built in. It's fine. The NNNN patterns are fine to a point. The problem with N services is they tend to be they, they tend to mean that you have, that, that change trickles through more than one of them. So when you want to make a change to something to a business process, you tend to have to make a change to the user service and the product service and the catalog service. Whereas if you have something like, you know, product management as a service, like a capability sort of thing and capabilities as an API you can limit the blast radius of change to the capability. And that's, that's, that's why there's a great blog by Michael Nygaard, you know, the author of a fantastic releaser. If you can look it up, I think it's about verb services. 

So you should, you should be, you know, trying to think of the services in terms of doing stuff as opposed to just returning, you know, crud operations, they should, they should have behavior. And so that's why we favor services with things like management and the title order management and that kind of stuff rather than order should be everything to do with orders, not just calling and getting an order from a database. So I think things have changed, things have crystallized in a sense as I say. and people when, when, you know, when, when, when they talk about micro services, they tend to mean that kind of that Dag type Netflix of course changed, they've, I believe they've still, they, they, they sort of inverted the graph if you like. So they, they went to reactive, a reactive pattern where they're, they're sort of streaming results rather than doing, you know, request response from their services, which is, which is slightly where Rx Java came from, you know, the port of Rx from, from C# was their implementation of that.But there are other patterns, I mean, this is almost on to Stefan Tilk Thoughts around the different sort of styles of microservice itself. So you've got, you know, this is the sort of, he talked about the type two the two A if you like, which is Netflix or Amazon, the sort of dag of, of, of hundreds of connected services or type two B which is when you invert it, as I say, you do the arrows the other way up on the diagram and you get the Rx version of it.But there's also, you know, there's also a type of service a type of microservices, architectural or, or sort of category of architectures which are almost purely functional and based on messaging or, or you know, sort of events, event driven architectures.

And this is, this was sort of characterized early on by a guy called Fred George who's also Exor works. It's no surprise that a lot of these people came from thought works actually.But he talked about this like, you know, he, he was building applications of very, very, very simple functional microservices that would functional in the sense that they would take an input and produce you an output, you know, and it was repeatable like a mathematical function in functional, functional programming functional.And they would just be sitting listening to a bus and when they, when they received a message, they would do some stuff and then they would produce another messaging response. There was this, this sort of set of services that were, that were connected.But I mean, there, there are other styles, I mean, the other two I would sort of mentioned are Stefan Tilkh himself, he talks about self contained systems. So there's a great, he's got a great, great site own self con self contained systems. It's a really nice idea where you have a single runtime which contains everything you need to do to do a particular slice through your, through your application, not separated out into individual services. I'm properly doing that a disservice but have gonna have a look at Stan's work and then there's what I call just use your head. I normally swear a bit more to use your head because the original intent of microservices, as I said at the start of this was to build stuff in a well architected way, deploying, you know, sensible patterns. But then constraining yourself around things like running, you know, don't, don't scale via threads, scale via processes which is one of the Hiroki 12 Factor app that, you know, constraints. So, has it changed, it's crystallized but at the same time, you know, that's ok. That's fine. You can still just use your head.

David Brown

So, when you say expanding from a noun based service to a verb service, does that imply that the domain limited scope of a service is now expanded? You're expanding the scope of the service, like you said, it's no longer an order service. It's an order management service. It's doing more. Is that what you're saying?

James Lewis

It's super hard, right? Because is the order management is, is potentially a capability, right? So you have a capability that you need to offer to, to the enterprise order management. Sounds like one of those capabilities now, is that a single service? Well, maybe and actually from the outside, you probably shouldn't care what you should see is an API which is your representation that you see of the order management capability. Now, internally, the team that's building that, that capability, you know, whether they choose to decompose that into a set of other into a set of services, you know, many services or whether they choose to represent that as a single service with maybe multiple end points, I guess that's the choice for the team themselves and applying what I said about using the appropriate design patterns, architectural patterns to, to make that decision. I'll give you a good example of that. I did a talk a long time ago now, 2012, 11 or something like that at Q on San Francisco. It was called Java the UNIX Way and it was the first time I started talking about, about these concepts publicly.

We've been talking internally but I haven't spoken publicly. And in that we have this, we have this sort of user management capability that I talked about and we were building and that from the outside, it looked like it said a series of end points where you could poke it with user detail or you could request it to create a user for you.And it, it would or wouldn't depending on whether you've given it a well well formed, you know, user request or whatever it was, it would, it would allow you to query it for users and do various things like that for users, create them, delete them, you know, change account details, all that sort of stuff. But internally, even though it had these very well defined APIs And then, you know, it was actually atom was the, was the domain application protocol we used. But internally it was represented by well internally, it was composed of a fronting service which accepted a request and then stored it off to the side for safekeeping.So it validated it, stored it off to the side and then said, right, your request is in process.

And then, and then sort of announced that on, on an internal queue, we then had competing consumers in separate processes that were reading messages off the queue as fast as they could and creating users in the back end store essentially.So it was internally, it was sort of 123 or however many three types, 33 different services externally, it was one, it looked like one thing, it was one API And we, and we, we, we, we used the three services internally to, to provide, to well, to solve for the cross functional requirements which we had, which was very spiky traffic. So we'd have really high load overnight and then crud operations during the day. So batch overnight, crud during the day and that, I guess that's an example where you from the outside is a capability you don't really care. But the team, the people inside that, you know, had to solve for the requirements they had and to do that, they apply standard standard design pattern which would be competing consumer in the, in the sort of enterprise integration pattern sense.So I don't know if that, that helps to sort of clarify maybe a bit what I mean about around, around the different types. It's not different types, it's different things change depending on where you're standing. It's like relativity in a sense

David Brown 

And it all sounds so simple and obvious and logical. When you're breaking down from a monolithic architecture to microservice architecture, you end up maintaining potentially dozens or hundreds of applications as opposed to one. And as you said, that might be comprised of a few front facing APIs or dozens of front facing APIs with lots of back end services, microservices behind those doing very specific functions with different architectural styles, potentially behind them, some event driven or whatever it starts to become complex. So how, how do you, how do you recommend organizations manage this complexity of re architecting monolithic applications to a micro service based application architecture?

James Lewis

I guess the glib answer is carefully. I think the mistake, I think the mistake people make is is by is trying to look at it too much in the in the round, in essence, right? Because depending on where you're standing, yes, things can look really, really complex. If you just look at the individual, it's a bit like looking at the night sky, right?You look at the night sky, you see all these stars and it looks like there's lots and lots and lots and lots of stars up there and there are, but actually if you start to think of those stars in constellations, there's fewer constellations out there, right? And I think that like the service landscaping a large enterprise is sort of similar to that if you just look in the round. If you look at all the stars, you look at all the services and you like God, I've got 2000 of these things. Hm. Yes, that's, that's really complex. And these things are event driven and these things are this and these things are that. However, if you, if you, if you, if you consider them as, as groups of things instead, and this is the whole how we group them together into, into business capabilities, you know, and then organize your teams around that the people inside those capabilities, they don't need to see the whole night sky. They just need to be concerned with their, you know, their, their, their solar system if you like, you know, I'm just, I'm pushing this me too far now. I've never used it before but hey, it sounds like 

David Brown

You're on a roll there.

James Lewis

But it's, I mean, but that's, that's really the, you know, that's really, I think the trick and I think if you're used to as an architect in a large organization or an enterprise architect, you're used to having this overview and I think that's, you know, that, that, that, that's still necessary. But I think the complexity can be managed by pushing these things into these smaller constructs and having the teams worry about them themselves,and worry about precinct, you know, the right APIs and then that and that kind of thing. I think there was the other question in there about how do you, you know, how do you sort of migrate or, you know, should you migrate in or, or how do you, how do you, how do you migrate from a monolith now? I mean, the question I was asked is why, why do you want to migrate your my life? You know.And there are, there are multiple reasons, valid reasons why you might want to do that.I I could think of a few off the top my head. Maybe it's, it's old right that your license is running out, the license is too expensive. You need to replace it with something else and therefore you're gonna do the, you're gonna migrate to microservices at the same time.You, you, you're a start up or a scale up. Another might be another reason. And you know, Twitter is a great example of this. Fail whale starts happening more and more because you've become really successful.And you need to do something you need to scale for, for because reasons, you know, it might be availability you're not available enough and you, you've become a mission critical resource, you need to do something, you know, you need, you need to and you, you were built in a particular way that doesn't encourage this scaling.

So there are, there are valid reasons and valid business reasons to do these things. But I, but I don't think it should be as you, you know, the implication David is that you shouldn't undertake this lightly, you know, which is really where I think we will, but hopefully where you're appointing, you're prodding me to go because, you know, it shouldn't be undertaken lightly. There is a great book obviously out there by Sam Newman who's a great friend and former colleague called Monolith to Microservices, I believe.which is, and it's an excellent, it's, it's really excellent. Actually, he's spent a lot of time working together and I fully endorse everything that comes out of Sam's mouth, more or less. There's some stuff about around board games. I'm not so sure about, but, you know,and he, and he's got a, he's got a weird taste in LEGO. He tends to go for the architecture sets and I'm not sure about that. But apart from that, you know, go and look at Sam's stuff, there is also some stuff we're working on.Actually, I'm working on with Martin at the moment around how you find Seams in, in legacy software. 

So, and the patterns that you can then apply to gradually move away from legacy. But it's, you know, it's like everything else you apply standard patterns. You look for things generally around business seas and depending on the, on the, on the, on the, on the underlying monolith of what the infrastructure and what that looks like. You've then got various technical patterns that you can apply. Great example. And my friends at BB VA who are awesome engineers and they've, they've managed to migrate part of their well global payment processing away from them from their mainframe, which is, you know that this is their core banking platform. Now, this is, I mean, this is the holy grail of many of the big banks at the moment is to do away with their mainframes and they're on, they're on their journey and they've, they've managed it. And one of the things they've been really great at is identifying the chunks and how to move those chunks off.And one of the, one of the nice patterns I've heard we've used as well is treating things like mainframes as an event source or event driven architecture. Cos if you squint, it's all about reading and writing batch files and if you squint to the batch file, it's just a list of transactions, right? So if you can sort of just pop batch files into the right place, pro you know, produce them and consume them, you can actually isolate whole parts of the mainframe safely often.So, you know, there are different techniques you can apply. But I think the main question is why do you have a valid business case? And because it's cool, it's not a valid business case.

David Brown

Yeah. And I mean, don't get me wrong. As a company, we facilitate Microsoft Services architectures. That's part of what we do. But we also enable integration of monoliths as well. So also space applications or whatever and automating workloads. But it's interesting because often starting with a monolith if it's architected, well that it can be broken down into microservices in the future is perhaps easier and more maintainable for a small, small team, you mentioned some valid reasons for migrating away from some companies may migrate away from the monolith. But I think also you have the issue where it gets so big that code base gets so big and so unmanageable and the team has changed several times since the original codebase was written, it gets to the point where you don't want to touch it because you're too afraid to touch it. You don't understand, you don't want to touch it in case the implications of touching it. And so, but if a monolith is actually well architected in the first place that it can be broken down into individual services. If and when it needs to be, then that's perhaps not a bad starting point for some businesses. It depends on the use case. And if you, like you say, if you, if you're just looking at the, the, the the migrating and one with there is a whole multitude of reasons why, why you may want to do that. But you, you want to have a reason, like you say.

James Lewis

Absolutely. I couldn't agree more. I it's about to have a story funny. So I think it's funny. It's quite tragic really. But one of those examples you gave me, which is that it's become, you know, a cobase that isn't well acted, a monolith and it's become just unmanageable and it was a large financial institution. Our remain name was. And they asked us, you know, what was the best course forward looking at the Cobas, they trying to to change it becoming what was impossible. So we ran some staffing analysis and I said, well, I've got some good news for you.Your codebase is cohesive except the problem is it's all 1.5 million lines of code that's cohesive. So you can't touch anything without something in aspiration.I was telling this Dan Dan Laws about this and because they also, we found a class with who, who, you know, using static analysis tool and we were looking at things like psychometric complexity and this kind of thing. And we found one class that has a method with 60 levels of nested if L which is quite, quite entertaining.

And we LLD North to tell me the old joke, which is, there's no correct level of, of nested if state, right? Because if you've got one, you can always add another. That's fine if you've got 60 what else are you gonna do? You've got no choice. You have to add it up but you can't go factor it. So,no, I agree. I mean, you know, and there are, there are those, those sort of pathological cases where Cobas get so, so old, so unmanageable that the only thing you can do is start again. You know, and sometimes that is the best economic approach to and, and, and this is, this is really,I think this is actually the, the, the hard bit is for that business case. How do you understand what the existing thing looks like to the point? You know, it's a bit like archaeology, my colleague, Ian Cartwright talks about software archaeology, you know, you have to go digging through these things to, to really understand what the economic benefits of strangling versus starting again, you know what they are.And that those, you know, those are, those are quite hard things to understand, right?

David Brown

Yeah, we've talked about a Pisa few times now we've made mention on them. Rest is not the only option for integrating microservices. There's a bit of a GR PC is in favor at the moment for implementation of microservices for performance and other reasons in that debate of GR PC versus rest on what basis should a developer choose one over the other?

James Lewis

Which is we're almost in Devin versus emacs here, right. So, yeah, because I I, I'm in like old man shacks at cloud territory because I, I, I've, I've, I mean, it's quite hard for me to talk about this without describing, it's quite hard for me to talk about it in general because, you know, it makes me, makes me upset, but it's quite hard to talk about it.

David Brown

I hit a sensitive point without, I mean, I still think XML is a thing, right?

James Lewis

Without, you know, without talking a bit about my history and actually the sort of history of integration over the years really. So, you know, because cos really what what when when rest became really popular, it was in it was as a reaction in the sense of it was a reaction to things, you know, to where to and certainly an enterprise integration.and you know, internally inside big organizations, you probably even remember this if you're old enough, you know, we went from the sort of the orms, the sort of corbus and the sort of, you know, the the sort of distributed object model type inter process, inter application communication, we then moved to sort of this, you know, the web services style of integration using the WS Death staryou know, specifications and stack. And incidentally there is there is a, there is a, there is an ontology to describe all the specifications for, for the WS for the web service specification. I mean, any time you actually need a specification of the specification, like of the specification. It's just that, you know, you've gone too far with that, right? It's too complex.

But, you know, you, you had the web, you had the web services stack and originally it was the web, web services were, you know, so R PC, so you'd have remote, so remote procedure calling where you'd essentially, you basically,you know, invoke a method on another service on another server by well, basically by, by passing it some, some, some XML. And it was really awful. I mean, and like the, the, the coupling that, that, that led to it was almost impossible to make any change to your service without requiring all the other things that we're talking that were talking to it to actually change as well.

And that, that became, that was a real issue, certainly, you know, for limiting the rate of change that we, that in, in, in organizations in, in teams between teams in particular, then we moved to document oriented web services, which were kind of better, right? Because you're passing documents around rather than and with documents, you can do things like change the order of, of fields in a document without necessarily breaking the other side. Whereas with R PC, you know, if you change the order of change the order of parameters in a method call, it's gonna break the other thing, right? So you have to be really, really careful about how, how about making changes? You can add stuff without in documents, you can add things without breaking other stuff without breaking stuff downstream and things like that. So you can evolve your services much more freely with document oriented web services. But then the natural evolution came to rest, right? So for integration inside organizations, because with rest, you've not only got the the the attributes of document oriented integration where you can add fields, you can rename by adding a new one with a new name, you can change the order of things. You're not fragile in that sense. So you get less coupling to the, you know, to to to the implementation if you like the representation, but you also get decoupling of the behavior as well because with, you know with hypermedia driving application state, you know, you can include links which allows you as the service provider by providing links to guide what your consumers are doing. So you provide this additional level of decoupling, which is why a lot of people move to rest, especially you know, in four weeks, it was a really big thing. 

Hypermedia driven applications were a really big thing. And then this idea of things like domain application process. So using things like atom to cons or atom pub which became quite popular to constrain how services would interact, you know. So you've got, you don't even have to think about it. It's Atom, it's Atom PUB. I can create, I can edit, I can, you know, I can delete, I can add new collections. I can add entries, I can add content. If you model your domain in that way, then you know, you just know how things are working. Then of course, Google because Google are, you know, tell you GR PC. No A it's not R PC for a start, right? So it's, it's one, it's one of these really badly named things and there are lots of them thw is particularly good at badly naming things as well. So I'm not gonna worry too much about, about Google's naming schemes.But, but also, I mean, if you think about what, what, what problem is Google solving, you know, any, any particular time that you're, that, that one of your fronting web servers is they, I I believe this is still the case. But when you type in say, you know, you type something into your search every time you type a character, it's firing up like thousands of requests off to the back end infrastructure, right? And then it's working out depending on which ones come back fastest.What it's gonna show you in, in, in the results kind of thing.If you're doing that for millions of people all day, every day, maybe there's a use case for using a binary protocol that's a bit faster than, than, than just playing bits, you know, than, than, than XL or Jason over the wire. I think there is a use case there, right? If you're Google and you've got the problems that Google has or if you're Facebook and you've got the problems that Facebook has, it's perfectly reasonable to do things like come up with new storage mechanisms like Cassandra, It's perfectly reasonable to come up or big table. It always perfectly reasonable to come up with new, new protocols, like things like GR PC or even, you know, HDP.

What's the new one? There's an even newer version of HTTP that they're sort of building,which I can't remember the name of it escapes me. But, you know, that, that's, that's completely reasonable. Now, if I'm, you know, if I'm Kate, I'm sitting in my team in my bank and I've got to talk, you know, I've got to integrate with another team across the way. That's that's I don't know, using my services to do  you know move, I don't know if it's investment banking. They're using my service in order to see what prices are, are, are, are, are from particular stocks and shares, but for particular equity products, do I need to use GR PC then? Well, mm, probably not. I mean, the human, human, I can't take more than like an update every couple of seconds, right? Or a second or so you don't want your stock tickers flickering like with, with, you know, every, every hun every 10 milliseconds.Really, you know, probably it's OK to use something that's gonna give you some additional benefits over GR PC, which are things like, you know, visibility and also,so it's transparency but also this, this additional layer of decoupling that allows you to change stuff or, and, and your client to change stuff without breaking necessarily. 

I mean, there are other cases, I mean, you know, you probably wouldn't use if you're doing low latency stuff if you're housing your server in, in, in, in, you know, in the exchange itself, you would probably do something else in that you'd probably be writing in C++ and you'd probably be doing very, very low level stuff over the wire. So,but, you know, in the, in the majority of cases, I don't see that, that, that the benefits of GR PC outweigh some of the cost of GR PC, which is you lose a lot of the sort of transparency and things that you have in HDDP saying that and, and rest on top of HDDP saying that of course, things have changed, you know, we talk these days about things like prima to enterprise and you know, about, about, you know, security being everywhere essentially. So, you know, we don't just want, you know, to terminate TLS at a firewall. When you come into an organization, we should be using TLS across every single one of our services, you know, which, which means that you can't then snoop on, on, on, on, on, on, on HDDP request and just, just see the plain text, you need to build tools that allow you to do that sort of stuff to get the same level of transparency. But I think I still think you get a lot from rest saying that again, I'm on, I'm pretty sure I've lost this one. So in the same way, Jason is, Jason is not an information exchange media thing.

David Brown

We're seeing a lot of guests of GR PC in an East West architecture. So that way you have a bunch of microservices within a contain application. Like you said, it might be services behind an existing front facing API and those services need to communicate very, very quickly because there's dependencies on each other in order to be able to return a the result set to the front facing API. But in that North South kind of dependency, maybe a restful interface is more practical and easier to maintain has advantages itself.

James Lewis

And that's, you know, David, I think that comes back to what I was saying about the different styles of microservice architecture, right? I mean, like if your requirements like inside your inside your capability where where you've got a number of services interacting if the requirements stand are are. But that, that, that interaction needs to be super super low latency, that seems like a reasonable, it seems like a reasonable designed, you know, decision to go with something like GR PC, you know, but you know, do really needs to be calling here is, is, is 30 milliseconds. OK? Cos if it is, then you're probably fine to use to use rest even then And if you've also got incredibly chatty services like that, there might be a question to be asked about why you've got so many things cross and low latency going across between them.

But, you know, as you say, it is a, it is ait is, you know, if you have a reasonable reason to use it, absolutely use the right tool for the job. That is actually what microservices was all about. And one of the reasons,it was so exciting is you get to use the right tool for the job, you get to make different decisions, depending on where you are, you get to make different decisions about security, you know, depending on where you are. This is one of the reasons why the UK government has sort of adopted or several departments have adopted the style because,you know, you, you, you don't have to secure every part of your system to the lowest or the highest common denominator of security. If you like, you can have, you know, you can have inside and outside the perimeter style architectures, which is really, really useful from the perspective of, of, of change. So,so yeah, I totally agree, David, you know, if you have that circumstance, you know, that's a perfectly reasonable design choice, but you get to make those decisions, which I think is the fun thing.

David Brown

And public cloud providers are sometimes making this choice a bit easier. In some cases, completely abstracting the choice, right? So they're providing these managed services, be it container orchestration or service measures that really do a lot of this grunt work for you. And so in some cases, you may even be, you don't really care in terms of what protocol is using for your Microsoft to communicate as long as it works unless latency and those sort of issues are of a major concern as an architectural choice, then maybe you do care, but it may not necessarily place an extra overhead or burden because the public cloud providers are abstracting some of this and managing it for you, right?

James Lewis

Yeah, which is awesome. As long as they're making the right decisions themselves, which the face of it you hope. But again, one of the things I care about I care about. Yeah, I wanna be able to make changes to the thing I've got without having to a notify other people, if possible or b have other people notify me when you know that I need to make a change, cos they've made a change, the thing I've got, I wanna be in control of that change cycle, you know,and if, if the infrastructure provided by, by the cloud providers, you know, allows me to state to remain in control which it for the large pub does, then cos they, because they're operating at the right level of abstraction, they're operating at the level of abstraction of like transport and things like this, right, sqs sns, they don't care what you put in it, you know.I still get to decide what, what, what the, what the stuff is, stuff is I put in, in, you know, in, I push into these services.

And that's, that's, that means that I'm still in control from the perspective of change. And that's, I think the important thing cos that's something that limits that limits through. I mean, well, you know, fundamentally we're, we're building software is about solving problems. You know, I would say business in quotes, but it's not necessarily business, it's not necessarily about making money. It could be about, you know, modeling for the pandemic, which we're, which we're doing with one of the universities in India. You know, we're building a rust based Asianas a BM Asian based modelto, to do a pandemic modeling, you know, but that's business in this sense in the inverted commas. The reason you're doing it is to solve a problem. Whether that's, as I say, this, you know, rus the Asian based model stuff, whether it's trading, whether it's, you know, selling an insurance policy or you know, online deliveries of, of coats and in order to do that, you need to have a particular type, you know, you need to have and as much throughput from your teams in order to solve those problems as you can. So what, what I'm interested in is how do you maximize the throughput back to agile again, right? Which is all about, you know, limiting work in progress and you know, small batch sizes and fast feedback and, and what architectural decisions or designs are there that help maximize throughput or hinder. And, and one of the things that really hinders is, is, is coupling, you know, me making a change means someone else has to make a change. Then making a change means I have to make a change and anything we can do and tools that we can use to minimize the coupling between teams. I think it is important. It's why consumer driven contracts were such an important idea.

You know, because back to the fast feedback, bit of agile, if you can find out that you're gonna make a breaking change in your build to someone else's software, then you can fix it there, there and there, you know, if you find out when they start phoning you further down the line, you've got much less context about the change. Cos it's been, it's longer you, they gonna roll it back from production or roll forward, you end up with, you know essentially, essentially a hit on tropper or a hit on lead time for requirements coming behind that, that change. So, you know, consumer driven contracts would say, you know, if you, you give me the, the, the, you know, you, you tell me how you're gonna use my service and I'll honor that contract by running it, executing it in my build as a test, you know, the behavior that you want. And if I break that behavior, then we can have a conversation, but it's a managed conversation as opposed to me breaking the behavior.and the other person having to deal with it or phone up in an irate sometimes. Of course, that's the only way you can deal with, deal with stuff. I was at a bank once where we were turning off an old version of a series to migrate for a new one. And we didn't, we had no idea who was, who was using it, but we, we knew two teams were using it, but we had no idea who else because there were more requests than just those two teams.So the only way to deal with it was to turn it off and then wait for the phones to ring, which they did quite quickly. To be honest.

David Brown

Look James, several years ago, you had pioneering work on microservices and you've had the benefit of watching this whole ecosystem evolve and thrive, you're now looking into the future and predicting the next big thing or the next evolution or where are we at? What's next?

James Lewis

If I was going to be a bit clip, I'd say database triggers in the cloud seem quite a big deal at the moment, which is Stefan's description of, of, of civil, right? So,the lands and things, I mean, iii, I think that's a really interesting idea. So a couple of years ago now, I was, I was, I sort of looked into it too much in the last year or so, but I was following a lot of the research on not, not on, not just containers, but then uni kernels, which is essentially if you've come across the come across uni kernels.It's almost like, yeah, I used to joke that Docker is 30% of the way to, to a uni kernel, but like a uni kernel is rather than build an application, you actually build an OS, the EX and your application into the OS, but you only build exactly what you need for your application. So if you don't need UDP, you don't build that part of the stacking networking stack. If you only need, do you know what I mean? So you, you really limit and it's in terms of security, it's the holy grail because you're minimizing the attack surface, you know.You know, there's no option to forget to turn off, you know,the fact that, you know, port eight is open, you just don't, you don't, you don't, it's not there in the first place, you know, but also there's interesting stuff around formal formal proofs and then formally checking because if you use, if you use compilers that are themselves formally proven, then you can build uni kernels that are again, you know, formally proven to be correct if you like or secure. And that's really exciting, I think from the perspective of building secure software. 

So I think that that's one thing in terms of, you know, in terms of where I think that infrastructure where things like Landers are going or, or even cus I am concerned about cus in the sense that actually, I mean, Stefan was quite right and he does talk to my concerns around what I see, potentially the problems with servers in the future, which is this unmanaged complexity that you get in databases if you've ever looked at, you know, database from sort of, you know, 2001 or, you know, the big oracle or big SQL server database. When everyone was going ask all the logic and stored procedures. And if you, if you've, if you've tried to untangle any of that sort of stuff, I think this is calling that, which is calling that, which is calling this, which is calling that it's really, really, really hard. I mean, I remember one client where they had, you would call, you would, you would invoke a store procedure. You'd pass it a, an, an index into a table which had the store procedure name that you wanted to call. So you'd like, call it like ID 15 and then the store procedure you were calling, we, we look at, look at the table,, that means that, you know, that store user or something. So then it would by reflection invoke the store user store procedure, passing the parameter. What, what on earth are people thinking? You know, you, you've created your own pointer system within, within, within the database. It's just kind of crazy., but, but I do wonder about that. I do wonder whether we worry slightly that we're gonna get into that position with this. 

And so I think that, I think there's a lot of I think there's a lot of evolution to come there with that. So, with, using functions as a service. I think the other thing, another interesting thing that I've been talking a lot with Keith Morris about, he's someone else you might want to consider for a podcast cos he's very much in the infrastructure space.He, and he's awesome.is, is, is this idea at the moment that of infrastructure is code and what that's gonna look like in the future?Cos we've started to get new things on the scene like palmi and, and CD K, which are much more, I'll write code, code and then something's generated at the back of it.But is that, is that the end, is that, is that where, where the industry's going as a whole or is this just a stopping, you know, stepping stone to something else in the same way that I think Docker and functions as a service is probably a stepping stone to something like uni cables in the future.So yeah, so those are, those are, those are two things that I think I think are quite, are quite interesting. There's also a bunch of stuff around things like ethics in machine learning. I mean, for which we get exposed to a lot of interesting ideas. And yeah, we have, there's a bunch of stuff fizzing if you can if you, if you if you like,

David Brown

I was speaking to a data scientist the other day and he was talking about this ethics in ethical machine learning or AI, he said David, it's an oxymoron. The whole point of machine learning is to define an outcome, to predict an outcome. So why do you want to create boundaries around what the outcome we wants to predict? And he was challenged by the whole concept of ethical machine learning.

James Lewis

Yeah. Well, I mean, that's the thing, isn't it? In the sense? Well, that's true in the sense, in the sense that unless you're very careful about the data set you use, then you know, if you have a perfect data set, entirely representative data set, then, then potentially that yes, that's, that's kind of all fine. The problem is none of them are, you know, we don't have these representative data sets. 

This is, this is 11 side of things.So it's, it's not the case that you're getting the right outcome, you're getting the wrong outcome, you can't get the right. It's like, you know, it's like if you,you only measure,you know, if sooner or whatever,you only decided to, you threw away 95% of the results and then said, we can't find this or this essentially, it's automated confirmation bias to describe it.which is in that, which is not a great, it's not a great thing. If you've got more, if you've got all the data available, then, then that's, then that's fantastic.If you don't, I think there's real issues,

David Brown

James. I feel like we're just getting started. But unfortunately, we have well and truly run out of time. How can the listeners learn and follow you? How, how can they what are your channels that they should have been?

James Lewis

So, I very frequently update my blog at bovo.org. I'm also, there's also quite a few videos on youtube. Now, we've been talking about micro services over the years and on Twitter at Bo Bo IC Y. And if you want to get hold of me, please email J A Lewis at B works.com. I'm always interested in talking about this stuff and learning more about what other people are doing. So, thank you very much and thanks Kevin and Dave for inviting me. It's been really great.

David Brown

Absolutely. Our pleasure and it's very generous of you to offer all those points of contact. We would love to have you back on the program soon and continue these talks. I think there is so much we could dive into. It's been a pleasure. Thank you very much. Enjoy the rest of your day in London.

James Lewis

Thank you. I could hear the rain and wind howling outside the shed. So might delay getting a new cup of coffee. But thanks very much and I'll sign out now.

Kevin Montalbo

All right. That's a wrap for this edition of quoting over cocktails to our listeners. What did you think of this podcast episode? Have you started utilizing micro services within your organization. Let us know in the comments section from the podcast platform you're listening to. Also, please visit our website at www.torocloud.com for a transcript of this episode as well as our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter and Instagram. Talk to us there because we listen, just look for Toro Cloud again. Thank you very much for listening to us today. This has been James Lewis, David Brown and Kevin Montalbo at your service for coding over cocktails. Cheers.