 All right, okay, so thank you so much guys. Well done. Um, so hi. Hello everybody. My name is Bjorn. Oh You really means I'm a techie guy. I've been running cool back in the days For how many years and these days a lot of time the customers and clients Really talk to them about how they build software. How they do it right now How to kind of bring that to the next level modernize the way to do it It's not a secret Give them the kind of conference right here, of course a lot of time talking about Cloud Foundry How do you guys solve for to properly take advantage of that type of cloud-based platform? I'm gonna go beyond a little bit just Getting started on technology and really talking about kind of what happens. I call it like day two development You gotta start on the project things are going great with doing microservices. Everything is fantastic and you realize that there are new challenges coming into play that you may not necessarily have dealt with before and There are things that you need to think about that Maybe a little different compared to how you've been approaching approaching certain types of problems in the past So just as a quick hands up Who here is building microservices today? Quite a lot of people that's awesome How many are using spring? Of course, that was a given. Thank you. And finally, how many are you seeing the spring cloud frameworks? That's great quite a few people. That's awesome. So that means I mean for you guys are doing that It is not just that you're doing kind of Microservices by accident to see that quite a bit around Where they have to be building restful services and they kind of make it work Kind of scared of calling it microservices, but that's really what they're doing kind of by accident and They kind of make it work. Now in this case here It's really about us the story about a team who has his monolithic application It's been around for a long time and it's kind of been growing over time to become this big beast and They realize hey, it's hard to maintain this thing. It's hard to add more features to it We're not really confident in ourselves when we're trying to do anything to it either what it's going to work afterwards fixing bug and bugs and Releasing those bug fixes is always being really nervous doing it at three o'clock in the morning all that good fun stuff That comes along with That kind of applications over time and of course nobody wanted to end up there But that's kind of where you end up over time. So it was a good story about how the unearth that happened. But anyway There's only realized that hey, we need to do something about this We're following all the best practice everything that but people are preaching in terms of splitting up into two pizza teams Because that's what we're supposed to be doing. We're going to do microservices and everything is going to be great, right? Sans fantastic and of course if you're gonna do the microservices Yeah, you better be doing it on Cloud Founder, of course, that's a given so far so good Well, there are some questions coming up as well when you start going down this path and One is a very basic question, which is a matter of communication How do these teams work together to start building something that becomes a solution as a whole and Because you're gonna have find that some teams are more concerned about building services that others are supposed to be consuming And you would have to think like well the answer to that question is a very straightforward I mean you do restful services you use some Jason and you get to go. I mean, it's not that complicated, right? And technically speaking, it's not The bigger question is how do you make sure that the service are built are actually the right services are to be consumed by whoever is going to build more of the front end and What you tend to do then it's okay Maybe you'll do some actual teamwork you'll sit down you look at the requirements see what the business wants and you come up with an agreement Specification in terms of in order to deliver this functionality These are the APIs that I need so you get the point where you get an agreement on that You write it down put into a nice shiny word document I regret everybody's agrees upon you save it somewhere and then you kind of forget about it and That sounds like a good quite good strategy right and ideally speaking when you do that You set up in a way so that the team was building the services they get started They get start building all those great API So you're looking for when those that team is done building those APIs then the front-end guys and gals can get started and Build their front-end they can consume those APIs and we're all happy everything is fantastic Well reality is that it doesn't always work this way Really what tends to happen is more is that that API that you're relying on that that is under construction It's gonna remain under construction for quite some time you realize so not you're on different teams with different priorities Where you as a front-end team you realize that you cannot afford to wait For the other team to actually finish their work before you can get started because if you do that You're gonna miss your deadline and you're gonna look bad and that other team they say well We're busy with something else at the moment, but we promise we are gonna deliver at some point and it's gonna be Just in time for when you deliver need to deliver your stuff So if you know that kind of situation you have no way of Influencing that what are they supposed to do? Well What tends to happen or very common strategy to kind of address that is To start marking up those APIs that you need so in that way you as a consumer you don't have to wait For the producer to build those APIs that you rely on you take a look at that word document I was created you look at the API is there and you say it. Okay. This is the stuff I need. I'll just Walk that up myself not a problem And in that way I can keep on going at the pace that I want I'm not being held back by anybody else and I'll be good I'll get to where the point where I need and all my unit tests in my CS system They're running green and everything is good and everybody's happy, right? And That's not a bad idea. I mean If you think about it with the spring framework We've been preaching Mocking as a part of a unit testing strategy for 10 plus years now It was one of the big things that the spring guys Started preaching back in the days and it really has some real benefits Especially when it comes to doing proper unit testing and being then doing focused unit testing It also helps because we're not relying on the real implementation to even exist yet Which means that once again the consumer gets implemented faster Consumer build runs green. We're happy. We're not really held back by everybody else and the only caveat To what we're doing here is that we can't really do proper end-to-end integration testing because In order to do that kind of integration testing what you're going to be integrating with actually has to exist so we'll have to wait with that and One day when the other team is done with the service that we depend on then we'll flip some switches will turn out integration tests and Hopefully this will work because this is the last thing we need to do before we actually go into production, of course Doesn't go that well And these are the actually the fantastic kind of Bugs and errors to deal with it because they always happen late in the development cycle when you're the most stressed out You're almost done. Just make this thing work together. Everybody. We already like to line it all up And we just can't get it working and it's a pain to fix. It's expensive And not at least it's extremely stressful to deal with this stuff so what went wrong well You got really two different worlds you're dealing with here that are compete that are going against each other you got that unicorn world on the one side where You as a client-side developer you're looking at the world through your Your view the way you think it should be working and you mock it up and you make it work and it turns out that that world does not match the real world and the real API that gets built and It will and there are of course a lot of good stories around like why that happened I mean, there is always a good reason for it. Sometimes things get lost in translation sometimes You realize that we had to make a few changes here they either in order to implement the client or the server in the right way and Tried to put into back into that word document that nobody reads anyway, and it just gets lost on the way There are also some more fundamental problems here that just adds on to the damage and kind of sets you up not for success but failure Somebody boils down to who's actually managing those stuffs in the first place Yes, it's the clients and needs them But if they're holding on to them if they're building them that represents their view of the world and their their Interpretation of what's needs to be delivered the best they can Which may not necessarily be the same as What's actually going to be delivered by the by the server team It also means that those stops are not being used to validate that their server team actually builds the same thing Saying that we have different two different implementations essentially that may or may not match So the question is then how do you even guarantee that those steps are valid? You built them You hope they work But you have no way of guaranteeing that they work and you may actually make them work at day one When you do your version one point over release of your software But as time progresses as you keep on changing the system do maintenance on it it becomes hard and hard to actually maintain these things And to make matters even more interesting if you're running an even larger project. We have multiple consumers Relying on the same service that is not there yet. You are gonna end up in a situation where you have multiple teams building multiple stubs multiple mocks of the same service and Not even them may actually look the same way So that way you have duplication of effort and if you're unlucky you have not only a Duplication of effort, but we may have multiple views on how the same service should work And they may all actually be wrong, which just makes matters in worse for you. So What are you supposed to do? I mean does this mean that this was a really bad idea? Not necessarily I mean mocking itself is not bad and especially I mean if the producer doesn't even exist What on earth are you supposed to do? there are however some Philosophical things in terms of how we approach this problem that is Worth emphasizing in the rethinking compared to the way we're usually used to thinking about Service providers and their APIs they provide first of all if you think about where your requirements Usually tend to come from they come from a business user somewhere and they view on the world Very often it is more in terms of from an end user point of view I need to this user needs to be able to do these and these things so I mean it's already there the Requirements and who's actually driving the API itself. It's actually coming from the consumer not from the server side It's not then so that that's one aspect of it that also means that not only should the consumers take part in defining the APIs But it also means that they actually should be the ones driving the design of the API and really telling these These sort of things we actually need and this is really what is a concept called consumer-driven contracts That is a concept that really reinforces that in terms of who is actually supposed to be Defining these contracts and defining the APIs is not necessarily The service side people who are building them It really is more matter of that letting the consumer the customer in many ways define what they actually need and I Think for us as people that's a very different way of thinking compared to the way where you used to Dealing with things like that. I mean if you think about it also is techie people We're used to seeing you less all over the place And user license agreements rise a lot of text and you have two buttons underneath it Accept or decline and you have no choice There's no way for you to negotiate this thing same thing you go and buy a new cell phone And you get this enormous contract by whatever cell phone provider you're dealing with and once again The only option you have if you want that service is to sign the dotted line And it's really the provider of the service you're buying that holds all the power in terms of what you actually get to do This is a different way of thinking we turn in the tables completely on this We're saying is really the consumer who knows best what they need and they are the ones who really should be Driving what actually gets delivered In addition to that that API specification that end up very beautifully in the word document earlier That should not just be this thing you write down somewhere and you leave it It really should be a specification that is written away So you can actually use it to generate stubs That you can use for mocking on the client side automatically So in that way you don't have to duplicate that effort and in the same way you should use the same Specification to validate that the producer implementation actually follows that specification And that's very important because that means not only do you define a contract in terms of what's supposed to be delivered Do you actually use it to both validate what happens on their service side and on the client side? Which means that if the contract is well written They'll the behavior between the will actually start lining and that's really where spring crowd the spring cloud contract comes into play And it's really a framework for consumers to drive the producer APIs through contracts What do I mean by that? It means that it's a way to define these contracts in a machine readable way through DSL's It's contracts that you store as part of your source code Manage the same way and that we can actually use automatically to get some value out of it That means that we can take these contracts and use them to validate that producer is actually working the way we expect it to And it means that we can take the very same contracts and use it on the client side to generate stubs Saying that way if you need to do mocking on that end we do that based on the very same contract What's the value of that it means that we can actually reduce the amount of end-to-end integration testing We need to do and we still need to do them of course, but The amount of bugs you're gonna find there is Are then going to be reduced dramatically Needless to say I'm in spring cloud contract is Java centric spring centric You're gonna find that if you're using spring cloud We can actually stub out completely frameworks like Eureka console and so forth And it's got a few different projects involved there both in terms of helping you use those contracts to validate the service side on the back end We also use wire mock to Generate more of a more stubs and that kind of things as well And we also have some neat frameworks into play So you use it from a client point of view can go out there and actually download those contracts on demand and Plug them into your project for your testing So what is a contract? Well? Here we're gonna example of it and it's essentially a groovy script And if you look there this little example of a guide here It's a login example Calling a login service in the upper half there You can see that we call this user login service to provide a username the password And then on the bottom here we were describing. Okay giving that input This is the kind of output. I'm expecting And I do I do understand I mean this is a very much a simple example The reword is a lot more complicated than that We're dealing with ideas that change all the time timestamps and a lot of information like that And what we do actually let you do when we describe when we define this contract It actually include variable fields like that so you can see it. Okay here I expecting a GUI D back that kind of thing so now we can deal with variable fields. Not a problem This is actually a fairly flexible framework. So let's do a demo See how this thing actually works and I have a Fairly not too complicated demo to show you guys is based on the same kind of login scenario Where I have a login service on the client side that I'm implemented and I've been providing Credentials there my username password when I get that I'm gonna forward that to a back-end service That says yes or no to those credentials and the business logic on that is very simple It's basically that if I get a password in that has mixed casing Then I'm gonna say thumbs up. This is a good password if I had get a lowercase password Then it's gonna be no So by all means this is not a proper login service, but it works great for a demo like this So let's take a look at this how this actually works so First Let's take a look at our contracts here So I have so this so where I'm going right now is I'm putting on my hat as a client side developer But when it comes to the contracts in terms of how the service side function works That is being stored together with the source code of The service side function you can actually decouple it completely so you can have a separate project with just your contracts It's up to you how you want to manage that and in this case here have two different contracts in here I have one describes the use login service with my username password and I get it okay result back And then I have another Example here for username bad password or lowercase in this case is not okay So this is kind of my contract here to find that I can get positive result back and a negative result back So what I do then is I can actually plug that into my client code And I've written some unit tests here That is testing that login function I implement on the client side So I have the same use cases here my username good password Okay, and the same way bad password not okay and To wire this all things together What I've done as well as I have a Annotation up here That's telling me to set those tells spring cloud contract to set up a stub runner So when I'm running these units test whenever I'm calling out to the backend service here It's actually going to stub out the services that I need in order to make this make this happen And the way it actually gets to those stubs is actually through a maven repository So really what I'm doing here is I'm referring to This is a package is this is this is a this is a component where my stubs are stored in a stub section in there I'm telling it to work offline in this case which basically means it's that on I'm not on the public internet right now We don't have a maven repository in the server somewhere So in this case, I'm actually leveraging my cash repository my laptop for it So that's what I'm saying telling to work offline in this case And I can run my unit test We'll now see that yep everything runs green everybody's happy everything is looking good now After implementing this so that show this to the business users they were like yeah, this is good But we've been reading up a little bit on security and stuff and we feel like Just saying that okay mix casing for user and password. That's not good enough You've got to have mix casing and some numbers in there in their trade in order to make it a valid password You know, okay, we can do that. We'll implement that so let's change our Unit test a little bit. So my password is not good enough anymore We need my password one two three in order to make that run and we also want to emphasize that doing bad password with Mix casing is also no longer good enough So implement those changes For my unit test and of course when I do that These tests are gonna run red. They're gonna fail because they're not according to The behavior of the service I'm calling the back end. So what do I need in order to fix that? Well for me as a client-side developer There is no way for me to fix that implementation because that's a different teams responsibility to do What I can do in this case is at least Start the conversation with that service side team and say hey We need to make some changes to the contract we have in place here to accommodate these new requirements that we got So what you do that is you check out the code from the service side team And we're not gonna Implement the changes for those for that team. I mean that's their job to do I mean maybe a simple change may be a big change What we can change on the other hand is the contract that we have between Us and that service so we're saying that okay. It's no longer my password is my password one two three Then it's gonna give me a positive result And we're gonna emphasize once again Bad password makes case not a good idea So now change a contract in order to make those changes available for me when I run my unit tests I need to Then maybe install But I'm not gonna rerun all the unit tests in there because I really don't care about that. That's not my job I'm probably breaking something on the service side implementation And that's okay. So all I'm doing now is just building that survey component With that new contract and putting that in my local Maven repository in my laptop right now So now I've done that And I can rerun my unit tests Where he's now using a Different implementation of those mocked-up services and we can see that okay We're good We've made our unit test run green again That means at least from our point of view in terms of what we're expecting This is the right behavior. It's what our business users are asking for So once I've done that then I can go back to the server team I can submit the pull request back to that team and say hey We made some changes to it Hopefully we couldn't talked a little bit about it before in between there. So this doesn't come as a big surprise to them But you made those changes to the contract and it's up to them to pick up on that Cheat those changes whenever they actually have time to do it. So Once they're ready for it And I kind of changed house here from being a client-side developer to server-side developer I could take a look at these changes And I can say well, yeah, that looks okay. I mean if that's what they want, we'll fix that and The first thing I can do then is actually run some unit tests to see if my current implementation aligns with those that new contract and The way you can do that is we have a plug-in as a part of spring cloud contract where they actually on the fly Generous unit tests based on those contracts. So I can do a Maven test of my server code and we're going to see here Build failure something went wrong We're on some unit tests One error here And if we look a little more in the stock trace what happened I'm saying that somewhere here We got an okay when you really expected A not okay result So here I can see suddenly that my implementation of my server code Does not fulfill the contract that I have my client Lucky for me. I mean I know exactly what the problem is and Fixing the bug is not too complicated So let's just fix it Down here has got some code. This is my authentication method When getting the password And up to this point. I've been making sure the password in there somewhere has a lowercase At least one lowercase letter and at least one uppercase letter And the only thing I need to do is Add another check to see that we have at least one number in here between zero and nine So I implement that change rerun my unit test And we're good to go Build success. Everybody's happy. We're all good So in that way, we've taken that change on the contract We've fixed our code. We can check it in Everybody's happy And the only thing that it needs to be done after that is to communicate back to the clients and developers that hey We picked up a change we made to the contract. This is looking good. We've implemented. We checked it in so in that way The only change that the clients that developers can do that at some point is to update their test I'm saying up here work offline Change it from true to false which basically means that when you run the unit test, we're going to download This component here and we're going to take it from our own hosted maven repository instead of trying to rebuild that component Ourself All right, so let's get back to our presentation. So Really, what have we achieved by doing all these things? Well Two things First of all, we improved communication. We've taken The type of information that ends up often in a word document That becomes immediately stale after it's been written and we turn it into an artifact that we can actually Put to good use So that means we're actually taking that information that contract we defined Not only can we use it, but it also means that we'll actually keep on updating it afterwards because there's an actually incentive for us To keep on updating that documentation It also means that we're reducing the risk of failed integration tests They can still go wrong But if you look at the kind of integration test failures you'll have Changed a lot of them you can actually write back to okay if we had a better defined contract between our teams We cannot avoid those failures in the first place That also means we get a better api in terms of That is something that also aligns better to what the consumer needs And it means that That api that contract you use Is managed as source code You can use it for verifying The actually implementation of the server implementation to make sure that one is good It also means that you can use a very same contract the very same specification To mark up your own implementations as well that you can use on the client side So thank you. That's all I had for today. Any questions? Yes So the question is do we have to use this dsl language? The answer is no We there are ways to use other types of specifications as well. I'm not sure if we have support for exactly The notation you guys are using there, but I mean at the end of the day We're open source. We're friendly. So I mean we'd be happy to work with you if that's something you're looking for Another question I'm sorry. I can't hear you Just saying that there are ways to do it. So I mean if you get if your gentlemen want to talk together afterwards I mean that's up to you guys any other questions All right. Well, thank you for so much everybody started for running a little bit over and I do appreciate hardly anybody fell asleep So that's fantastic. Thank you very much