Sam Newman on Information Hiding, Ubiquitous Language, UI Decomposition and

[ad_1]

Subscribe on:






 

Charles Humble: Hello and welcome to The InfoQ Podcast. I’m Charles Humble one of the co-hosts of the show and editor in chief at cloud-native consultancy firm Container Solutions. Today I’m joined by Sam Newman, Sam is an independent consultant and is the author of a number of books including two on microservices, Monolith to Microservices which has been the subject of a previous InfoQ Podcast and Building Microservices. The second edition of the latter is just out and having just finished reading it I was keen to talk to Sam to find out more about what has changed between the new edition and the first version which was published in 2015. Microservices will also be one of the tracks at QCon Plus the software developer conference which will be back this November the 1st to the 12th online.

QCon Plus features 16 tracks curated by domain experts to focus on the topics that matter right now in software as well as the microservice patterns and anti-patterns track of the tracks covered this November include the cloud operating model, from remote to hybrid teams, and architectures you’ve always wondered about. At QCon Plus you can find out what should be on your radar from the world’s most innovative software leaders driving change and innovation. Each will share with you their solutions, best practices and actionable insights to reduce uncertainty on which technologies should be part of your roadmap. We hope to see you online this November. You can visit qcon.plus for more information. And with that, Sam, welcome back to the InfoQ Podcast.

Sam Newman: Thank you very much for having me.

Can you talk about information hiding, and why you feel it’s so important? [01:50]

Charles Humble: And congratulations on getting the second edition of the microservices book out there, I think it’s a fantastic book. I’ve just finished reading the early access version and I believe as we’re recording this, the second edition is going to print and will be out in the next month or so. I was interested by some of the things that have changed and in particular you talk a lot more about information hiding in the second edition drawing on David Parnas’s work. Can you talk about that, why you feel it’s so important.

Sam Newman: When I wrote the first edition I think we were just dealing with what people were doing, we were looking at this architecture, looking at that architecture, and just seeing the different style of SOA that microservices was becoming and it was a process of just almost recording what people were doing rather than trying at that stage, you don’t really have the time or the energy to be able to distill down the essence of what unified these approaches, bit of a hand-wavey way of saying it right there. But basically there was too much stuff going on and there was no time to step back and think about what were the core ideas at play here, we could see there was something different but not what, a lot of the early focus was other things. And after time and energy looking at it and throughout writing the first edition, I kind of zeroed in on this idea of this independent deployability as being the big hook for microservices.

But then in the intervening time after writing that first edition, I spent time working with people who were struggling to deliver on that. And I realized talking about independent deployability was great but how do you achieve it. And so I’d been put on the trail of information hiding, during the first edition Martin Fowler who helped review the first book had mentioned it, and I do cover it in passing I think in the first edition. But I came back to that concept as well, is this the hook for the hook in a way? If you get information hiding right does it therefore make independent deployability much easier? And I realized that actually it does. And if you go back to the original work by Parnas when he’s talking about information hiding as a way of building good modular architectures, the concepts of what we want from independent deployability are right there in the stuff he wrote back in the early ’70s.

And so at the beginning of last year I’d kind of come full circle almost just thinking of microservices really fundamentally as being a modular architecture, albeit a modular architecture with the complexity of a distributed system. And so therefore taking Parnas’s advice about information hiding made even more sense in that context, so that’s kind of where it came from. So the first edition, the world is chaotic and I have no time to work out what the hell’s going on, I’m just capturing the good advice and then in the second edition, I’ve had a bit of time to think there’s some core hooks, I think, that are important to emphasize more in the second edition to hopefully help people deliver better on the promises of microservices.

Can you give a definition of exactly what you mean by information hiding? [04:41]

Charles Humble: Can you give a definition of exactly what you mean by information hiding?

Sam Newman: Yeah. I mean, there’s some specific definitions that Parnasmkj uses in his work but the kind of one I go to is the default, if you think about a microservice boundary your default position is almost you don’t expose anything. So any information you expose, so if you expose a method, a data structure, a piece of functionality to something outside of your microservice boundary, well, then an external consumer can make use of that. And so once they make use of that they then effectively have a contract between you and them, it’s an interface they’re using. Once they have an expectation about how that function works about the presence of that piece of data, that then makes it harder for you to change your microservice without breaking them. If you want independent deployability, you need backwards compatibility. By hiding things inside your service boundary the things inside your service boundary can change without fear of breaking your external consumers.

So it’s almost like partly saying, things that are hidden can change easily and things that are shared are part of your contract and you have to be very careful about how they change if you want proper independent deployability. The more you hide, the more freedom you have as a developer working on a microservice to change things safely. I talk about information hiding really is just about clarity, being really clear to a developer as to what things can be changed fairly safely and are not going to have a nasty ripple effects in production. Developers don’t go to their day job wanting to break computer systems, they want to do a job. And with information hiding, right? You’re saying, this stuff is hidden no one else can see it, that’s yours, anything you change in there is going to be okay.

Now, anything in this part of your code base, this is where you’re shared with other parties, the outside consumers, you need to be really careful in that world. So this is where you’re exposing your REST endpoint or gRPC endpoints and whatever kind of external contracts that you might have. And so when you change anything in that world you need to have safeguards in place to make sure that you don’t break people accidentally, this is why I’m a big fan of explicit contracts for service interfaces, things that are contributive in contracts. But information hiding allows you to really focus that energy and work on the small parts of your microservices code base which actually are used by other parties.

Charles Humble: And then for those bits that you are exposing to other parties, how do you then control that? Do you have some sort of schema? Do you have some sort of contract which…

[ad_2]

Source link