Microservice communication and integration: what are my options?

[Music] we have one more session in here this morning and it's going to be about mark services communication integration please welcome Kate's family hello so kids can hear the microphones working that's a good start so as I just said I'm going to talk about mic receivers communication and integration my name is Kate and you can tweet me if you want to on Twitter but my slides aren't showing it there we go so you can shoot me at at Kate Steinle 91 if you want to during but I won't respond but after the presentation so first some introductions I'm a software engineer I work IBM at the moment particularly on websphere liberty which is a java application server if you haven't heard of it you should check it out pretty cool but for the last couple of years I've actually been focused on mic receivers and particularly building something called game on which is a text-based adventure game I'll talk a little bit more about that later so if that's something that interests you and hold on to later in the presentation this is actually my second time talking at Jay focus my second kind of Stockholm as well I'm so excited to be able to come back and talk to you all today here's a picture of me presenting last year I talked about microcircuit again but it was testing last year so if you're interested in that then do you feel free to check out Jay focus website from the videos last year it will be up there and there's my Twitter again so what am I going to talk about today first I'm going to give a little introduction to you what Microsoft is are just so that hopefully we're all on the same page then I'm going to talk about why communication I think is important both in life but specifically in mic receivers and then what are your options when it comes to micro services how to be a good producer and consumer of api's a little conclusion at the end I'm aware on the talk just before lunch so I'll try not to go on too much and keep you from your lunch so first what our microcircuit is can I just get a quick show of hands who here thinks they know what Mike reservist is already and they're kind of happy with the concept cool I think that's a fair few people so I'm not going to go into too much debt there's plenty of stuff you can go and read about to kind of learn more about much service but I'll just do a little introductions so Mike reservist is used to compose complex applications using small in quotes because that's a controversial subject independent replaceable processes and they usually communicate via language agnostic api's they give you a lot of advantages by putting everything in separate pieces you can scale them more efficiently you can perhaps iterate more quickly but they do come with some sub difficulties as well I talked a lot last year about how testing is something you have to maybe think a little bit more carefully about when you move to Mike reservas you might have to rethink your DevOps strategy and of course communication so before I kind of go on into communication of Micra services I just wanted to throw it out there but micro services is not the answer to all the problems in your life you should really consider before you go down this track because there are advances but there are disadvantages ative so with that in place let's assume that you've read arpa-e think marshal services are the way to go and now you want to know about communications so why is communication important before I talk about microcircuits specifically I'm going to talk about my team and how we communicate so we will formed I think about a year and a half two years ago now and it was formed to look at how can we make Liberty awesome for Mike receivers it is awesome for micro services by the way but how can we make sure it's really good and also how can we help people learn about micro services because a lot of people don't really know Western or they've done something very simple but what do they do next and we formed this team and we thought this is great you know we're going to did awesome team and create all this cool stuff but we ran into some issues around communication and these were down to three main things the first one is that we're in different locations so I'm based in the UK if you hadn't already guessed by the way I speak and my colleagues are actually on the other side of the world to me and that means that we also are in different time zones so to just give you an idea we have a meeting every day at 3 o'clock in the afternoon my time but that's 10 o'clock in the morning for some of my colleagues so we do overlap on our days but we don't completely overlap and the final one is different languages and I'm going to tell you where all of the people in my team are forum and that might mean the languages is a bit interesting so as I said I'm from the UK there's some other people from the UK we have some people in America and people in Canada but the people in Canada they don't speak French did you to be English but the reason I say that we are all speaking different languages is because of this quote the United State and Great Britain are two countries separated by a common language this has been attributed to various people but it basically means that when I say something in English to my colleagues then the people across the pond in the US might interpret that in a quite different way to what I intended and then there's a different interpretation again in Canada so although when you look at it on paper we all think you know we're all speaking English this should work fine there's maybe some issues there and we've had to do some things to overcome those and the reason I'm telling you this story is because I think this works well in really think about microcircuits it's tempting to say oh well I'll stand up all my microservices and we'll you know we'll all just communicate via language agnostic api's and because their language agnostic it'll all be fine but there are some things that might trip you up that you weren't expecting along the way so that's what this presentation is about kind of trying to show you where you need to take a bit of care with communication so how do we solve our problems well first we chose what data types we're going to use to communicate so that could be text or speech or body language it's kind of the main ones that humans use to communicate we also had to choose infrastructure options do we use email do we use slack or maybe Skype and then what characteristics do we have for our communication so that could be things like blade communication if I send an email I don't expect an immediate response I might get response in the next hour it might be the next day the next week maybe but for Skype it's immediate if I phone somebody up on skype and ask them a question I expect them to answer me straight away and actually we've used a combination of all these things to get really good communication within our team and then hopefully build really good for micro services as a result so how do these things convert to micro services well first you have to decide what data type you're going to pass around you could muck around with having some people pass around Jason or something different but as if you all agree on a data type it's just going to make your life easier down the line I would generally recommend Jason if you're starting out it's the one that's kind of become the most popular at the moment you could use XML that's kind of going out of fashion a bit I put binary up here as well there are binary protocols like thrift available but if you're starting off I would generally recommend going with Jason and then down the line once you understand the kind of communication between your micro services then you can consider whether or not binary protocol is the way to go then you need to think about infrastructure do you need a service registry do you need a service proxy and these are all things I'm going to go into in a little bit more detail and then there's the characteristics and I'm going to talk about asynchronous and synchronous protocol specifically so let's get into it what are your communication infrastructure options so the first thing you need to consider with Microsoft is is you should absolutely never have known endpoints because one of the reasons you've hopefully moved to micro services is so that you can be more resilient and if one service goes down you can handle that gracefully but if you're using hard-coded endpoints then if something knocks out that hard-coded endpoint anymore you're in trouble so you need a way for services to find the other services in the room and that's where a service registry comes in it's a store of available Micra services depending on which one you use it could be but it's a persistent store and put into a database somewhere or something or it might just be a cached list of Micra services available whichever one you choose you should aim for its haves the following kind of four functions and those are that it provides registration so you need to be able to as a Mike reservist go and say I'm alive and here's my endpoint a health checking mechanism so we either for a micro service to say I'm still alive you know I'm still here you can still send traffic to me or a way for the perhaps the platform you're using to tell the service registry when it syncs an application is available service discovery so here there's a difference between service registry and service discovery a registry is your list of where everything is but you need service discovery so you need a micro service to be able to discover what's in the registry and then do registration and the registration could be done by say the platform like if you're on a cloud platform that might do the D registration but generally the they'll be sort of something like a heartbeat going from a micro service to the service registry and if it misses a heartbeat then it will automatically get D registered and that's them I think the most common approach there are many choices and when you're choosing which service registry you would like to use one of the main considerations is do you want consistency or availability there's something called the cap theorem which is the theorem for distributed systems which is you can only have two out of the three of consistency availability and partition tolerance and you kind of always want partition tolerance so you have to choose between consistency and availability and the choice really depends on what your micro service is doing quite famously Netflix kind of say that they choose availability so for example if you if I've gone and watched something on on online on Netflix and then I go back and it comes up with the things that I was previously watching rather than saying oh well we can't find up-to-date version of what you recently watched will just show you nothing Netflix choose to show the last good copy of that data so it might be that the thing I watched yesterday isn't up there but the thing I watched two days ago is and that's enough for them so it really depends on what your micro service needs and you'll see kind of a themes throughout this presentation that communication it's very important if you understand what are the requirements of your micro service and then that should help you make your communication choices I've put some examples of some service registries up there things like to recur console amalgamated maybe one that people haven't heard of that's kind of container based and I'll talk a little bit more about that one later so now that you've got the service registry everyone's registered and you've got this nice list of where everyone lives you need to decide how as a microcircuits you're going to call another micro service and the first option is using a service proxy so in this case is basically either Mike receivers will call out to a service proxy which will then forward my request to which have a micro service I need to send the request tree and this picture here I haven't included load-balancing and that's something that normally will be done by the service proxy and the other thing I haven't included in this picture is caching so I could have the micro Service make a request to the service proxy then at that point service proxy makes request at the service registry gets a list of services comes back does some sort of figure out which one it should send me to and then forwards the request but that's quite a lot of the kind of steps just to make one request so if you're going to choose this model I would generally recommend to have your service proxy have a cache of the service registry if for some reason it doesn't have an upstate casual the cache has gone away then you can still make the request but for efficiency you should have the cache there and also think about how you're going to do load balancing and the advantage of doing this if you have quite simple requests within your microcircuits when you write the code you're just making a request to some endpoint that you happen to know about and then it's quite simple to test it and you know mock out service proxy and you're all good the disadvantage of this is of quite a few network cops going on so you're making a request out to the service proxy which is then forwarding the request on to someone else who then responds and then the response comes back again so there's a lot of network cops going on and if you have issues along the lorry and then you might cause latency to your users so the other approach issues client side reading and for client slow reading basically one micro service will have some mechanism to find out where all of the other micro services are hosted what endpoint they have and then you make the requester to direct to you the Micra service and again you need to think about where am I going to do my load balancing and where am I going to go do my caching so you would expect the you as a micro service to have some way to check with the service registry and keep a local cache of all of the services in that registry so you don't have to go ask the service registry come back and then make the request to the Marcus and for client side reaching there at kind of two ways to do it you can use a client library or you can use a sidecar so for those of you that might have looked at Eureka before they provide client libraries for you to make requests they also and provide youth libraries like Netflix ribbon which do you things like load balancing and basically in this scenario you have nice code that you can write you can look at it you can understand if something goes wrong and debug it but it is language specific because you've written it into the logic of your application and you're gonna have to think carefully about how do I make sure that my where I'm using my current library and making requests how do I keep that separate from my business logic inside my app the second option is the sidecar model this is language agnostic and this is what amalgamate does that i mentioned earlier so the idea is you have a sidecar that's running say inside the same container as your application or if you're using something like cuba Nessie's then you can actually have one container that has your application in your pod and then have a second container in the pod which has the sidecar in it and this is nice because it's language agnostic if all of the Micra services in my system are written in different languages then i can just use one sidecar and I can reuse that everywhere and it works the difficulty is if something goes wrong with your sidecar it might be more difficult to debug the failures because you haven't written the code that's making a request so it might be a bit more difficult step through so there's the kind of your options around how you make two requests out the other thing you should consider is an API gateway API gateways are used to kind of keep a layer of separation between your micro server system over here and anyone who wants to make external requests so although you might have lots of different teams building the Micra services you still work quite closely together and you still should have a cider of people external to your little group of micro services that are making requests in and it basically just provides a mechanism for showing coarse-grained api's up to the user so because of the nature of micro services I mentioned they were kind of small wish it means you'll probably have quite fine-grained api's and you don't necessarily want to expose them to an external person and and the main reason for that is because it means you're showing them exactly how you're doing everything and in the future if you want to change something you can't because people are relying on your very fine-grained API so instead you should consider having an API gateway that provides more coarse-grained api's up to the external users and then that means you are completely free to do whatever you want behind the scenes and the external users will just never know they're also useful for API metering and GWT injections so if you need to kind of validate some of the requests coming in and understand whether or not that person is authenticated and what they might have access to then an API gateway it's quite a nice way to do this because you know this is one entry point for the requests coming in so now I'm going to move on to talk about micro service communication characteristics so I said earlier I was going to talk about synchronous versus asynchronous and this is the topic that when I showed these slides and to my colleague Frey left the UK there was some question around or what does synchronous versus asynchronous mean and we kind of realized that people do talk about this on several of levels so hopefully I'm going to describe to you how I see it and hopefully it will make sense but I'm basically talking here about synchronous versus asynchronous protocols so I think Rinna's protocol is something like rest HTTP of CPUs rest you have to use HTTP but this requires a response if you make requests you expect something back whether or not that's just a message says yep I received your request that's fine or they're not that some sort of payload back again whereas asynchronous protocols here I'm talking about something like messaging it's more of a fire-and-forget scenario so you just have some data that you've throw like into such a channel somewhere and you don't worry about it and if someone picks it up the other ends and that's fine and I think that actually both of these are useful for micro services I've seen various kind of blogs and things a line that discussed like which ones you should use but I think they can both be very useful in the right circumstances but before I talk about the circumstances where they should be and I'm also going to point out I've got here you should utilize asynchronous programming models so although I think synchronous requests are useful it's worth noting that when you make a synchronous request you are blocking the thread where you wait for the response but you can use like asynchronous programming models to hand off that thread and then you're not actually blocking a thread but you obviously are still waiting for that response back again so where do I see each disease to kind of show you an example and show you where I think these are useful I'm going to talk about game on which I mentioned earlier so game on as I said is our text-based adventure game it's written in my Chris and it's you can kind of see on the left boat sprite to you right hand side that you kind of enter commands and you can play around in this text-based world so it's made of a bunch of different rooms and you can go into a room you can have a look around pick up objects and then you can remove from room two rooms by doing like go sort go south or whatever and the reason we decided to create game on is because we wanted to find a nice fun different way to teach people about Mike reservas and we thought this would be a good way to do it because you can come in as a developer and you can write one room for the game that should be a fairly simple application hopefully you can have a go at standing up in the cloud somewhere you can hook into our architecture and start thinking about how you would communicate with other micro services but it means that from the starting point it should be quite a simple process and then what's your kind of comfortable you can take steps forward in whichever directions that you want so for example say you decide well I'm going to do some scaling and I want to have two instances of my room available well once you stood up two instances you might have someone in the game who's gone into one instance and someone else who's gone into a different instance but how do you make sure that the two people in the two separate instances of your room see each other how do you make sure that they actually feel like they're in one room not two and then you have to start thinking about water too I'll use eventual consistency am I going to have some cache data or something and we've we found that actually by creating a room and doing something is a little bit different from what you would do day-to-day it kind of gives you the chance to explore concepts that are new and exciting in micro services in a kind of new setting and then what you kind of learned and you understand what you need to do then you can go back to your day job whatever and say well I can see now how we can apply this to what I'm working on so that was kind of the main reason why we created it and it's live I'll put some links up at the end and you can go and play it if you want to or write rooms or whatever but we created it and we now take out to conferences and also to our clients we run workshops and in the workshop people create rooms and then they can play around with a room they can see each other's rooms and go and visit them and because of that we needed to create something called the interactive map so this is the interactive map it's basically a picture of all the rooms that are in-game on I had to zoom in so that you can kind of see what's going on but actually we have a ridiculous number of rooms at the moment and this is a picture of rooms that are live like currently being hosted on cloud platform somewhere and hooked into the game on systems and the basic reason we created it was just so that when you come along to a workshop you can create your room register it with game on and then you couldn't go look on the interactive map and see it appear so you know it worked and it just displays the name of the room and the location on the map so the example I'm going to use to show where we can use a synchronous versus synchronous protocol is a user who has created their rooms they registered it with game on and then they want to update the name of their room so we have here the UI so that's how I would go in and update my my room and what's a 'birthday today I want some sort of response that says yep that's done and then at some point in the future I need to be able to look on the interactive map and see my new name appear and restructured this kind of flow to look something like this so the authenticated user comes at the top and they're making a rest request to the map service the map service is our service that understands everything about the map so it's in charge of the desorb has a list of where all the rooms are a composite in comparison to each other and if you want to make some sort of it update then you go to the map service and the reason this should be a synchronous request rather than a synchronous is because me is the user if I come in and say I want to change my name I expect that response I want someone to come back and say yes that was successful or no that wasn't successful you'll have to try again so that should be synchronous then there's the question of how do we get the interactive map to see this update and we could have the interactive map make synchronous requests to the map service to say Oh have you got new data on a haven't or have you got any now and then keep going back and forth but that's extra traffic that we don't actually need because the interactive map isn't one of our core systems it doesn't need to be up-to-date it's nice if it's you know pretty up-to-date but it doesn't need to be to the second we have a perfect view of the world so we can use messaging instead we can have the map service send out a message to some sort of message broker which would then be subscribed to by the interactive map and then it receives the request and by choosing this model we've made good use of both synchronous and asynchronous requests and it means that the user gets what they expect and the interactive map gets the data that needs in game on specifically in case you're interested we're using Apache Tasker here's an example of the code all of the creators of game on is actually open sourced so if you want to go look at it kind of in more detail and see how we're building up things like our events or anything else to do game on the new can and I'll put the links up at the end and the reason we chose Casco was because it's nice way to send messages but also there's a service called message hub in the IBM cloud so we have all of our services deployed in containers onto the IBM cloud and message hubs is based off of Casca so when we're creating micro services we strive a lot to get high parity between our local development environments on our laptops and what's up in production so by using casco we can have our application then using kind of the classical clients and things and then it gets easily put up into production we don't have any problems so that's kind of example of where you can use both synchronous and asynchronous so next I'm going to talk about microcircuits design and how it should be implemented by communication so when you're coming up with the idea of your microcircuit it might be kind of easy to think we'll you know we'll just decide which services we need and everything and then we'll kind of worry about communication what Priesthood them all up somewhere but I think that actually you should really consider what communication your Microsoft is going to have as part of your design kind of approach and one of the reasons for this is because of latency because actually if you have two micro services for example that when a request comes into one it always has to make a synchronous request the other one and then get the response and everything you might find that over time your users experience latency and actually if you have several micro services in a row so if you have a request that comes in it calls another one which calls another one calls another one which then gets a response back and back up the chain you're definitely going to see latency and you might have not had to worry about it kind of in a monolithic world but now the only distributed system latency is definitely a problem so you should really consider you know how are my Microsystems going to communicate and how will that influence how I should split them up and to kind of give you an example of that I'm going to talk about game on again so this is our architecture for game on when we first started out and we structure that after at Hotel style model so we have proxy is kind of the front end piece and we have player so player understand everything to do with the game player and then we have a room because we knew we wanted people to come along and join us and write friends so we needed one room to get started and then we have the idea of a concierge in a hotel a concierge shows guests to their rooms so the concierge was just there to show players to their rooms when you come into game on and you access UI you can send messages like I said you can say like go north go south look around or whatever and you can also chat so you can type hello and other people in the room can see it and to facilitate this we set up a long-running WebSocket and so initially that was going from proxy which kind of links to the front end into the player service and then it's pushed across two rooms and we kind of set them somewhere like cool sorted but then as we went on we kind of started thinking about you know how we're going to do communication and what other services do we need and we realized actually this was a problem because of scaling because we wanted to be able to scale really efficiently but a long-running WebSocket actually scaled quite differently to the rest requests that would come in to update the name of your player for example or what their favorite color is so we moved through this model instead so we added something called the mediator the mediator mediates between the front end and the room and that's what's been hosting the WebSocket the long-running connection and then we have the player which has the rest requests coming in and this is just one example of how we've actually had to rethink our design because we didn't think about kind of how will the communication impact the way we do things we didn't think oh well actually we're going to be using this form of communication here which might need to scale in a different way and if we'd have thought ahead we could have put mediator in immediately so hopefully I kind of give you an idea of the different infrastructure options you have and now I'm going to talk about producing and consuming api's so the first golden rule of api's is api change it's quite nice to kind of assume that you'll get everything right the first time and you know you'll write your API and it will be good forever but actually in my opinion has been quite pessimistic because you want people to use your API and you want people to want more from your API so you want to be able to extend it make it even better and get it to provide even more so you should be optimistic and assume that your API is will change and there are some kind of different kind of changes you might want to make there are one sort of sort of typically breaking changes like altering methods or changing the data that's coming out or there's number 18 methods and so you could add some data or you can add some methods and theoretically that shouldn't break anyone but unless everyone is being a good consumer and producer of API then actually that can cause problems too so first I'm going to talk about being a good consumer the first thing you should consider if you're consuming api's is you should always accept the unknown so for example if you're taking JSON in it might be that you want to process actuate in some way in turn it into Java objects so that you can then do something with the Java objects and you should always accept unknown values and things in your JSON object coming in and actually some of the processing sort of frameworks and things they do build the syn so this example up here this is from GameOn again and that's using jackson to press this adjacent into a Java object and you can see you just can use an annotation updates and ignore properties ignoring a nickel tree and this actually goes just in front of the class declaration for your models so room info is a model of some Java object that was being passed in so if you so if you use the the right systems like Jackson then actually you get this kind of thing for free but you should always make sure you accept the unknown in the second one is only validate against the required so if I go back to kind of game on examples if I make a request to map to say I want to know the name of the rooms but it returns me the name and the description and then I have something in my code that validates oh yes we've got the name and we've got the description but then I just do something with the name and not with the description then it's in the future someone changes the API and they stop giving me the description bag said I'm broken except I shouldn't be broken because I don't need the description so why on earth am i validating against it so only validate against the things that you actually require back the other one that I put up and here is fault tolerance for talents is really important when you're doing microservices communication and you should use it pretty much everywhere so not just when you're calling other Microsoft Alling things like Cloudant because cloudy for example might be hosted somewhere on the cloud you don't know if that's going to go down or be available or if you're reading files from github so what happens with github goes down so you should always use for Florence whenever you're making outbound requests I'm not going to go into details here about all the different options for forums because there are plenty and but it seems like timeout circuit breakers bulkheads if you want to learn more there was actually quite a good talk about follow tolerance in micro services last year at Jade focus you should go check that out on the website cut remember hunter you gave it but fault tolerance is definitely something that you need to consider when you're writing your communication so whenever you're writing requests out to an external service just put some fault tolerance in there next one is being a good producer of micro services so the golden rule is don't break your consumers and if you need to break something use versioning so this comes back to what I mentioned earlier around if you want to alter methods or you want to alter the data that's coming back instead of ultra in your existing API just create a new one and in fact when you first create your API you should just start off with versioning don't assume that you know you've sorted out the beginning and you're never going to have to change it assume you're going to want to change it and that's all you're going to need version 2 or version 3 so if you version from the beginning then you should be alright the next thing to consider is accepting unknown attributes in a request in so if for example I'm the map service and someone makes for a question say I want some information about this particular site and then it passes in some random number that you have no idea about rather than throwing back and saying well that's not request that you works that I was expecting just return the data that you think they want and throw out the extra thing that they passed in because why do you care that they pass something extra cheese why should you care at all so just accept that unknown attribute and then the final thing is to only return attributes that are relevant to the requests coming in so for example if I'm at service and then someone makes a call in and says please can I have the name of this particular room or site then I should only return the name and not the name and the description and the location and whatever else like all the objects in the room or something and there's kind of two reasons for this one is because if you just retire if you've returned everything and then in the future say oh we don't think anyone's using the description when they call the API so we're just going to stop returning it then you're going to break your consumers because they may well be using it even though you weren't expecting you to the other reason comes back to not exposing the internals of your microcircuits so this comes a both the level of kind of API gateway where you don't want it and expose the internals of how you filt your Mike reservist to the whole world but also in your little team that's building a micro service you probably shouldn't expose how you're doing things to your team that sits over there because then it stops you from changing things in the world of kind of JPA you're used to dumping all the data out and like sending everyone everything but then that means in the future you really stop being able to iterate and innovate and change things and completely throw out the bit in the middle and start again and actually I talked a little bit about it last year but you should maybe think of having some sort of data anti-corruption layer in your application so the way you build up your application internally is quite important you should have your business logic and then some sort of layer in between your business logic and the logic that's receiving the requests from making requests out again and that means that you always have that little barrier so you can always change your business logic and completely redo it if you want to without causing any issues oh so most of this consuming and producing business comes down to something called the robustness principles you can find it on Wikipedia quite a note well-known thing which is be conservative in what you send and be liberal and what to expect and the last two slides were pretty much a long version of this so whenever you send things out and that's the minimum possible and whenever you accept things in just accept everything and just use what you need so the last thing I'm a little quirk about around api's is documenting api's now when you're set up with your different teams are working on different micro services it's important to get some sort of understanding of you know how you're going to interact and this kind of links back to what I was talking about the beginning of to talk about how my team interacts we had to set up some understanding and some guidelines of you know where are we going to talk how are we going to talk you know what channels of communication are we going to use and it's pretty easy to kind of all sit around a table and draw on a whiteboard and say yeah this is what our API is going to look like it's going to be cool and awesome and and then you everyone goes away build their parts and you put them together push them up into production and everything's broken so instead just document them in code in for example contract tests and again if you want to learn more about this I talked about it last year but basically it's useful to have the consumer of an API write some contractor so say this is what we think we are going to be consuming and then they can throw that over to the people producing the API and they can valid again state as well and because it's written down everyone should be on the same page hopefully I would still recommend that you kind of everything into staging and then run some end-to-end tests and integration tests before you go ahead and push it all up into production but if you've got consumer-driven contract test then you should have less things breaking in your staging environment than you would have done before and for game on we've chosen to use swagger to kind of document or api's and facilitate this passing back and forth of information there's a couple of reasons for this one is because it's quite popular and people kind of know what it is know how to use it we also have a feature in WebSphere Liberty that will allow you to generate this documentation so we actually just write the annotations and then we use the Liberty feature to auto generate the JSON file which is what's being showed up here and actually the Liberty feature is providing the URI that you see but it's built on top of the kind of open source version and the other nice thing about this is swagger provides you the cool little try it out button so if you haven't had that seen that absolutely should go on to game on you can click on the flag link and you can actually try out our API and that's really nice because it not only helps out the teams who are writing the internal microservices but actually if we want to encourage people to consume our API externally like in the way we did with the interactive map then they can come in and try things out and actually for some of our kind of API some things we actually wrote them in Jason first and kind of stood them up and we had other people writing services consuming them to make sure we were happy with them before they were then actually implemented in code so that's another option so hopefully that's given you a little flyby stalkers microservice communication there is a lot to consider and generally I would recommend that you consider communication alongside designing your micro service and defining what the kind of main aims of your micro service are but the main points I've covered today are you should choose your service discovery and invocation method and I've given you some different examples and if you want to go and have a at how we're doing something game on feel free you should use both aid success and synchronous protocols and I think both are useful maybe you synchronous in moderation because it can cause latency issues but they are both very valid as I said design should be definitely influenced by your communication and then also consider the robustness principle at all times so that's the end of my talk if you want to go and play a game on now I talked about a lot but you can and all the code is up there on the github page and we've actually got a bunch of different samples so you can go and start writing a sample room with like a framework to get you started we've got ones in Java JavaScript go as well I think if you want to learn more about Liberty but also if you want to read more about micro services you can go look on web dev net and then the final thing I want to plug today is my red book that I wrote with some of my colleagues so IBM a book about microsomes best practices for Java it's got kind of and some of the things I talked about today but also about testing and DevOps and design and all sorts of things so it's free to download if you want to go check that out as well so thank you so much for having me I'll kind of leave it there now so you guys can all go ahead and go to lunch if you want to all if you'd like to ask any questions and I would welcome now or I'll be around for the rest of the day thank you [Applause]

Channel: Jfokus

Views: 19,089

Keywords:

Id: 4KQoYVX9lNM

Length: 41min 19sec (2479 seconds)

Published: Fri Feb 24 2017