GOTO 2019 • Discovering RESTful Web Microservices: A Traveler's Guide • Mike Amundsen

Published by Darron Toy on

hello it's good it's good to see you thank you for coming it's been a really great experience this is the first time I've done the Chicago go-to event in quite a while and we had a workshop yesterday and lots of good sessions today so I'm very I'm very happy to be here and share with you so the topic of the talk is discovering restful web services so before I do that I have one one thing I must do I travel a lot last year was about 40 weeks on the road so I actually need evidence of where I've been just to remind me so if you don't mind I'd actually just like to take a snapshot if you just had wave and say hello this will remind me very good thank you very much so in in the future I can say oh that's where it was okay so again this is me this is how you find me on LinkedIn and github and Twitter and I would love to connect with you I would love to learn about what you're working on in the API and micro service space what what are challenges to you what they're interesting if you would remind me when you connect or just mentioned go to Chicago that would really help me a lot to make sure I sort of place you in in the in the panoply there of people that I keep running into so I do a lot of training and a lot of traveling and advising if you're interested in more of the things I talked about you can visit this site these slides will be available to you and there are a few short videos from some other talks I've done both internally and externally and that'll give you some ideas about what's going on so I used to work in a group called API Academy they were disbanded at the beginning of this year but it was an amazing group of people we had a but year about seven-year run all really talented individuals I was so honored to be working with them we traveled around the world and collected information so this was our book on micro services you can download a free copy of this book at this URL because it was sponsored by CA technologies so you can get a free that's about 175 page book and get a free book out of that and again this link will be in the slides when you get them so I'd be happy to share a lot of the things that I'll talk about today came out of our research for that book this book covers a sort of a general notion of the value proposition and and management idea behind services it's not a it's not a hands-on book like the designing micro-services book but this will give you a good start the last book the team released in December was on API management so I'm just mentioned this one I have two copies of that book here I don't have a free ebook copy but will when we're doing questions we'll have a chance to give away a couple of copies of that book and you can visit the site to learn more about it and then finally this is the book that I'm just finishing up this year this will be released in the fall with pragmatic publishers it's much more of a hands-on API book I won't spend any more time on that but you can follow that link if you want to learn more about it please remember to rate the session this is a chance for me to improve the talk that I do and a chance for go to to learn better how to program for the for the future so please just take a moment and and do that rating it helps me a lot I appreciate it okay all of that stuff out of the way let's talk about what we're what we're here for so the title is a bit weird discovering restful web micro services it's a nice little little buzzword package right I get a lot of things in there but I it really means a lot to me this notion of discoverability I think we're getting to this stage in micro services and web api's and so and so forth that we need to move beyond writing bespoke everything I have I want to use Twilio or write a client for Tullio but I want to use AT&T SMS service or write a client for a TN t–'s SMS service we have all these things that we're doing bespoke right now and that means it doesn't scale now lucky for us those of us who are paid developers and architects we get paid every time somebody wants to connect but in the grand scheme of things that getting paid every time slows the growth and the creativity of the environment the web beat that problem and scalability by changing the rules about how you connect it and I think that's the thing we need to think about and one of the first parts of that is this idea of discoverability I did a talk a few years ago on mapping the API landscape API landscapes are a big part of what we talk about in our management book it turns out your API is much more valuable when it's connected to another API and the more api's we have in the system the more API is in the landscape the more valuable your API can become because it can attach attach to more and more people that's called the network effect they're trying to do this all the time when they're in Silicon Valley what's a cool product that has a network effect it's when we add more people the value of each individual one gets greater the problem is that doesn't always happen with API is because api's are living in their own private world we need to figure out how to create a map and a landscape where you're adding an API suddenly makes it available immediately to everyone rather than through some extra work in maps and you know I used maps in mapping the landscape is a big part of my discussion because maps are very much what we use today to figure out how to use an API this is a map right it happens to be a map generated through swagger hub right a lot of us use swagger swagger was designed as this ability to generate documentation and some stub code we now use it as a way to actually define an API so this API is defined by some swagger file which has specific endpoints URLs and beginnings and endpoints and responses and stuff like that the challenge is this is a map for just one API and it's not even a map for just one kind of API it's not a map for a user management API or a pet store management API it's a map for this one instance of it which totally isolates it we don't have a general map do we we have just specific Maps so we've used maps for a long time right so when we first started building web sites we created sitemaps we thought maps were really important we've given up on that idea for the most part but I kind of liked that period when we were actually mapping out our web sites think about the way a car you know your maps in your your phone work when you're driving right we want a map of everything to get from A to B that's how that AI that intelligence inside that app works it knows the inscape it knows the math most of us for our websites we don't know the map anymore and that's certainly true for a api's we don't have good maps what makes a good map a good map has legends on it it says if you want to find the city or the castle or the forest or the lake this is what it looks like on this map and it's a universal way of talking about things in fact we can draw lots and lots of maps and use the same legends or same symbols and we don't tend to do this in api's but we have done this in the web for a long time not just this is the about page or this is the who are we page or the FAQ page but this is the forum and this is the link and this is the drop-down and this is the selector we have all sorts of legends that we've built into our webs that we don't have inside api's so what I'd like to do is actually stretch this idea of mapping a little bit further this is a map that an artist by the name of Alex Rivera helped me create and this is a map of the landscape of creating micro restful micro services that people could discover along the way one of the beauties of maps is maps don't tell you how to get there they just tell you where things are if you'd like to go visit the castle here's a map to help you get there and there are lots of possible ways to get there so what we're gonna do is we're gonna visit this Omni Tara this world where there are lots and lots of places and we're gonna use those places as sort of a guide as a way to kind of remember and remind us what's really going on in the world and hopefully this will make sense as we get a little bit further so finally I have that restful web thing what does that really mean what am I trying to pull off here so the idea of the web or the idea of hyperlinks is actually more than a half a century old whose first verse talked about in recent memory by this gentleman Ted Nelson in the 1960s when he coined the phrase hypertext in hyperlink and hypermedia as the way to talk about links and linking between things it actually exists along before that all the way to dawn of the 20th century won't get a chance to talk about that gentleman by the name of Utley who's a Belgian had actually envisioned what the World Wide Web would look like if you're interested in what sort of a steampunk version sort of an early tech version of the World Wide Web would look like look up the word the the individual outlay I think it's OTT le T and you'll find an amazing vision of what he called the the I think he called the world Network but anyway we've been around for a while this idea of webs is important a person who really made it happen for us was Tim berners-lee it took another 25 years basically between when Nelson was talking about it to when we actually got a working version of HTTP and he wanted this idea of a universally linked information system where portability was really important generality was really important Portability generality that sounds pretty familiar now you might recognize this character right fielding we're a fielding is famous possibly infamous for the idea of creating a thing called rest what he did is documented an architectural pattern that emphasizes scalability and component level interactions in generality boy that sounds an awful lot like the web doesn't it and that's because he used the web as his guide when he started to build his notion of what network software architecture could look like he was trying to imagine what it was right to write software for the network not software for one machine a challenge that we'll have and we'll talk about this some more as often we're not led to write software for the network we're led to write software for the machine or the container or the instance and we don't really think about the network as our composing space and finally there's there's lots of talk about micro-services at this event and several others and you've probably seen martin fowler's sort of distillation version of it a suite of services running in its own process and like make mechanisms so on and so on so forth so we have this notion that has gone for the last half century about how it should be simple and light and easy and straightforward to create services it turns out there are lots of definitions for micro-services but there's some pretty sting shared features of microservices you might have heard this one make each program do one thing well a micro service is focused on doing just one thing it's not a monolith of a bunch of things it's just one thing now whether that one thing is search or user management is up to the individual designer but it's one thing and when it's time to do something else we're gonna do that somewhere else so another big part of micro services is this notion that the output of every service is actually going to be the input of some other service so we're trying to figure out this idea of composability we've used things like ESB s and gateways and proxies to do that for quite a while there are a lot of people that are trying to build services that actually operate just on their own and they make their own connections Amazon is actually very good at doing this internally they create services that talk to each other very easily another aspect of this is designing something to be tried early we say early and often so there's that Minimum Viable Product idea that idea that I want to build something just to see if it works before I build anything really huge no big upfront snow big waterfall experience that's another big characteristic of these small services and then finally we have this idea of actually using tools writing tools programming tools to make programming easier a kind of a weird sort of inception pattern right an abstraction of an abstraction Netflix gave us a fantastic set of examples of how to do this they write all sorts of things in there chaos army in order to test the code that they've written before they put it in production right so they actually spend thousands of hours and hundreds of thousands of dollars to build all these tools to make writing their code easier Amazon does a similar thing with the way they start individual projects Etsy does a similar thing with the way they do releases that's he releases 30 or 40 times a day they have a huge infrastructure they built for that so this notion of actually programming tools to make it better is a is a real key part of creating service small services that work together now I think there are a few people in the room that I recognize that might actually have seen this list before has anybody seen something like this list before you might know it as the principles of you all right these are actually the the principles of Unix from one of the earliest writings about AT&T UNIX philosophy and it this is actually taken straight out of that material the beauty of that is it's 40 years old we already learned a great deal from this right so we have lots and lots of learning that we can do about how to build services that interact with each other whose output is input who are designed to be tried early all these things and we do that really well at the Machine level the challenge is doing it at the network level so I tend to talk about it in a much simpler terms loosely coupled components running in an engineered system what's a loosely coupled component it's pretty easy if you can release your component into the ecosystem like at your company without having to get permission from anyone first without having to make sure somebody else has also changed their service to then your loosely coupled if I have to wait until the data team she makes their changes before I can release my middleware or have to wait until the front-end team releases their thing before I can release my middleware that means we're not loosely coupled means we're a distributed monolith right I think we all experienced this on the web of course this is exactly what happens I can put up a web server anytime put any content on it I can link to anybody else and it works just fine I don't have to get permission from anyone to do that Ted Nelson used to say there his idea behind the web should be that anyone can post anything anywhere without getting permission from anyone and finally running an engineered system we need an engineered system that's resilient and robust and we use our what's typically called DevOps to do that right we have all this process of testing and release and even release testing and production to try to make sure this thing is resilient and they keeps running even if something fails and that's what the web does the web keeps running even if my server fails right there are no fatal dependencies on the web it's actually a web not a stack right so it's not like I'm traveling down and if one of these is broken nobody else works what's really interesting is the failures on the web are pretty much not on the inside they're on the outside they're on the discovery end if DNS fails a lot of us are into right now we've done a pretty good job with Amazon and a few other things of actually creating fatal dependencies if Amazon's down a lot of us are down right so that's not a web anymore that's a stack and we need to fight that in the long term if we're really gonna create systems that are robust and live for a long time so I told you I do a lot of traveling this is my this is my commuting vehicle this is how I got here it only took me an hour sometimes people have to drive an hour to work every day that's what I did I just flew but this is also another way to travel traveling the network we don't think about it but we travel the network when we use our browser we go to lots of places and that means we need to be programming the network there are lots of people who are programming different bits and pieces that I all have a pull into my web page or pull into my app at some point along the way and they're all disparate elements that don't really understand a lot about each other we used to call them iframes and stuff like that but they're all individual pieces often we're tricked into doing this we're coding one machine we think the machine is our only target this happens to be my machine this tells me I'm not going to be watching a movie on this flight since the system won't reboot but actually this is what we program right and the problem is when we use our API is when I use api's from Salesforce or s AP or Oracle or Microsoft or Google or whatever I'm using ap is that I don't control written by people I've never met running on machines I can't reach that's the feature that's not a bug most of us build in our heads systems where they own everything I own all the servers I know everybody who's contributing to it and we all agreed ahead of time how to do it but that's not how the web works right so if we want to scale to the point where we can do our own services anytime anywhere without permission we need to get to the point of thinking about the open space rather than the closed space of what programming looks like okay so with that in mind let's do a little traveling we're gonna go through a couple of places we won't have a chance in this talk to visit all of the locations on this map but I want to visit a handful of these and talk a little bit about this and just give us sort of a chance to learn a little bit and the first place I want to visit is actually in the center this is what I call the ruins of monolith eeeh this is the place where all of us remember right this used to be a thriving Society this used to be a fantastic place it turns out it was originally designed by a king by a royalty there's this line of royalty and this first king designed this community and did figured out where all the roads would work and where all the communities are and every weren't great and it took a long time but we got it built up and matter of fact it took that Kings whole life and by the time the King died his sister took over and she took on the task of architecting the rest of the community and what she decided is that that last architecture that her brother had worked on was really not all that good so what we're going to do is we're gonna build a brand new architecture we're gonna get rid of all that old stuff we're gonna build a new system instead so that meant that there were lots of parts that weren't quite working well anymore or didn't connect really well but people kind of got used to it and then she died and then her brother took over and then her and then hit he started tearing up the old system and building the new system again until pretty soon century it's decades after decades generations after generations the entire community was always in flux was always being built nothing was working anymore it was always either old and abandoned or yet to be built and we had this community where nothing worked anymore and it took too long by the time we built it it was old and unusable so somebody had to build something else instead and it suddenly fell to ruin nobody knows quite sure how it all ended but apparently what happened is people just abandoned all this architecture and went off somewhere else to do something else now this probably rings true in a handful of ways that we can think about right a lot of us work in organizations where we're constantly rebuilding what was already there somebody new comes along there's a new technology there's a new way of doing it we're just going to rebuild what's there in fact in real life what we do is we repurpose what already exists what used to be a church is now a community center what used to be a factory is now an apartment building we actually reuse what's there rather than destroy it although in America we're pretty good at tearing down buildings Europe's a little better at keeping them in America we're pretty good I'd like them just moving that stuff over somewhere else so it turns out this idea of building a huge community is complex because it's distributed in lots and lots of ways so you've probably seen this list before some version of this list the fallacy was distributed computing Peter Deutsch is the person who sort of credited with the first version of this list I think he had maybe five or six things on the list it's grown since then a lot of these fallacies probably look familiar that we always assume that the network is totally reliable right we always assume that latency is zero or that the bandwidth is is infinite or that the system is already secured or that nobody moves the server from one place to another there's only one administrator if I could just find her I could get to my problem solved right that transport cost from one place to another is zero it turns out none of these things are true right none of these things are true there's always latency there's always a bandwidth problem the network is always going down somewhere on the planet somehow we need to account for that one we build when we design and build what we're doing I love this line from Pat Helen Pat Helen started working at Microsoft and then he moved to Amazon and then he helped Amazon build their distributed system and then he moved back to Microsoft to help them build Azure and now he's working at Salesforce he's got this line in a paper called data on the inside and on the outside there's no simultaneity at a distance what does that mean I look up in the sky and I look at a star and I saw that's a beautiful star but I don't realize is that star is tens of millions of light years away and that star is already dead I go to a web site I hit this API and I say how many of those cool Mike Amundsen books do you have in stock and it says one and by the time the message gets to me book is gone all right we imagine that everything is instantaneous but it's really not right and that's a really important part of programming the network program for the fact that it takes time to go from place to place and that every information every message that sent is really a message in a bottle and it's frozen in time and in the amount of time it travels affects the accuracy of that message yet we commonly don't think about that when we write our own apps we just imagine that latency is zero and this is another one I like from Michael Nygaard I'll be quoting some other Michael Nygaard stuff in this talk he has a great book called release it michael says bugs will happen they cannot be eliminated they cannot be eliminated so they have to be survived John gall I won't get a chance to talk about John gall he's got a great book called system antics from 1980s and his line is a quality system is one that keeps running even when it's in failure mode even when parts of it are failing it keeps going that's how our bodies work when I got a cold when I'm not feeling well I keep going often that's how our cars work that's how so many things in our life work but often we don't create programs we don't create applications that actually behave like that they're brittle one thing fails and the whole thing falls down so Michael has a lot of stuff to teach us out of this book called release it anybody seen this book before I highly recommend if you haven't seen this book to pick up a copy this is actually the second edition he wrote the first one I think around 2007 or eight or nine this one is just released last year highly recommend this book it is primarily about writing code like tcp/ip related code so if you're a service provider or your writing client abscess may not seem appropriate but especially if you're involved in network apps he's got some great advice he has these things called stability patterns and capability patterns so I want to talk about his stability patterns in this idea of how we program the web so you've probably heard some of these before the timeout pattern right is that that's when I make a request to you and I'll wait 500 milliseconds and that's it then I'm leaving that's it I'm not gonna listen anymore you've got a certain amount of time then there's the circuit breaker right which is when you don't get back to me now what do I do what I do as I mark your server is unreliable and I flip a switch which basically takes me to the all either the alternate place or a cached version of what I got last time or a message that says I'm sorry I can't help you right I flip a circuit breaker that circuit breaker has a timer on it like another 2,000 milliseconds or 3,000 milliseconds and then it flips and I'll try you again right so this is a way of kind of mimicking the electric circuit pattern for services to make sure we don't get stuck along the way so the another one called bulkhead bulkhead maybe could save me from a circuit breaker so a bulkhead is when I have a service like one that generates a date/time stamp to the microsecond and everybody uses that service so I really want to make sure that if it goes down I don't get in a lot of trouble what do I do I get six or seven and them running in a cluster right so if I can get up to four five or six of them I'm well into into into five nines of reliability for the most part especially for stateless servers if one of those goes down somebody else can answer the question all right so I can use a bulkhead to help me add reliability steady-state this is that this is actually a really nice one steady state is this ability to keep running even when things go wrong those of us who know about writing logs to disks know that eventually run out of disk space right a steady state implementation make sure I never run out of disk space it says it notices boy you're gonna run out soon let me go ahead and start getting rid of some of these old logs or maybe stop writing logs or ready to write them to somewhere else there's all sorts of ways to keep the system up and running systems running too slow kubernetes runs up spins up another version of it or Amazon will spin up another version of it or Heroku will spin up another version of it right that's a steady state implementation fail fast is the opposite of timeout if you send me a message and you say you've got two thousand two hundred thousand milliseconds to answer and I know from my past history it takes me three hundred thousand milliseconds to compute this you what'll I do I won't even waste my time I'll just say no I'll say 500 I can't do it in 2002 200 milliseconds go find somebody else right so that way we don't back up a lot of people waiting a needless 200 milliseconds because I wasn't gonna get it done anyway right so fail fast is a really nice pattern I think Netflix uses that a lot and finally there's this handshaking idea handshaking and tcp/ip is all this extra talk I'm about to send you a package are you ready and somebody says yes I'm ready and says ok so I'm gonna send you the hash and the length if you got the hash in the length yes I got the hash in the length ok here's the message did you get the message yes I did did it match the hash in the length no okay I'll send it to you again like we have this constant conversation of handshaking right we don't really have that on the web but what we do have our health checks are you up are you running what's your memory situation what's your latency situation how many errors of you are you producing so that's a way of doing handshaking if I look at your latency situation and I realize you your latency is running at 300 milliseconds I might not even send you the request for the for the service into it because I need it in 200 milliseconds so I can avoid trouble if I use handshaking so we're taking this journey we're taking this step these things along the way to help us figure out what's going on so now I want to talk a little bit about code I don't know or normally talk about code because code happens on a machine I usually like to talk about the network but I think it's worthwhile talking about it a little bit it leads us to a few other places on our map and the first place I want to talk about on the map is the fields of purity this is sort of an amazing place in in Omni Tara everybody does one thing and one thing well and they're amazingly fast at it so there's all these gurus all these Swami's all these sorcerers all these amazing people that do this one thing and they're they're amazing and what you can do is you can sort of just ask them a question and they answer immediately what's really weird about it though is once they answer your question they don't remember anything anymore so you have to ask them again and you have to ask them again they have all memory of time they have no memory over space they just keep repeating the same thing over and over again and that's pretty much what a stateless micro-service is a stateless micro-services are simple processors like converters or translators they they actually just do one job and do it over and over again what's amazing about them is they have no dependency on any other service they don't have to ask anybody any other questions return me a list of valid zip codes validate the zip code that I have tell me what the interest rate is in for this currency in this location and so on and so forth they're really good at answering just one question and doing it well they don't even depend on writing or maybe even reading local data storage all the data it may be up in memory so they can just do it in memory really really quickly this turns out to be the most common micro service component example that you hear about we all want stateless services it turns out it's the least useful it's pretty hard for me to get a lot done when all I have is a stateless service or a bunch of stateless services that don't remember anything I can't write any data I can't read any stored data I can't actually execute any series of steps that anybody would actually commit in any kind of way that remember in any kind of way but they are handy little tiny services now what's great about them is they have no shared state they don't need any other server to explain anything to them they don't look under the server for data they don't write any data they don't wait for somebody's cookie or session or anything to tell them what's going on they just do their own problem what's great is they can be easily replaced I can write my my currency translator in PHP today and I can write it and go tomorrow and nobody cares I can write a bunch of them I can have them do lots and lots of things I can actually scale a lot of them so I can have 10 of them or 12 of them in a cluster or whatever or I can spread them around I can put them at various locations around the planet to make it easier for you to find and connect to them so often they just look like this like there's a little confusable conversion servers is I get a request an appointed two responses I convert the value in the request then I send it back to you it's simple it's easy but there's that thing right what about the network what happens what happens if it takes too long to work what happens if I can't connect to the service at all so when I call this service what I have to actually do is maybe use this fail-fast idea say look I have a time budget I need it in a certain amount of time why don't you why don't you try it and if it's not going to work then I'll just return the value I'll just say I'm failing right so I've got to make up for the notion that I might it might take too long I also have to make up for the notion that it might not work I might not be able to connect to it at all and we'll talk about that in just a second so that leads us to another place in the map and this is the caves of persistence this is an amazing place these are these storage caverns there are people who work in these caverns and then they store all the valuable things from the city people come out to the city and these are sort of this like priestly class these these sort of ascetics these religious folks and they take your they take your object maybe it's that's all of your ceremonial object from from from the harvest season and they give you little slips of paper that have IDs on them and then they go hide them somewhere in the caverns the caverns go on forever and ever there are some people in the caves whose only job is to make new caverns is to like dig out new new parts of the caverns they never didn't see the light of day and they keep storing everything and every once in a while they rearrange all the storage inside the caverns they move things from one place to another nobody on the outside actually knows where anything is they just come and they present their little slips of paper and somebody says ok we'll go get it for you sometimes they can get it quickly sometimes it takes a while to get it maybe you'll take even days to get it what's really interesting is what happens is over time is they've stored all these objects and some people never show up with their slip of paper anymore they don't ask for them anymore right so you might think that what they do inside the caves is they throw away all these things that nobody asks for but that's not what they do they keep them forever they maybe move them to some other place but they never know when somebody might come back and ask for this right so they keep them forever turns out that's exactly what our data storage systems are like right there are people whose only job is to figure out how to optimize storage they don't know anything about the services behind in front of it they don't know anything about interfaces or api's or anything all they know is about their storage and they keep stuff around forever and ever and to them it's all just storage it's all just value in some kind of way and that's ineptly just to another kind of micro service and that is this thing we call a persistence service or a storage service simple storage the reads and writes often local data like it's on the same server that has the API it's very disk IO dependence so it means I've got this space I've got latency I've got all this reads and writes that I need to deal with that may also mean that it's really a virtual disk that's spread over against a lot of space that I have to deal with it may be on the same virtual machine or it may be dependent on another VM or another another 1u in the same rack but usually it's pretty close together so these persistent services are often very much needed micro service component but they're not the easiest to implement because they're stateful right so that means they have to memorize things this is especially important when you have a dozens of people that want to access the same storage maybe you read the same records maybe update the same records suddenly a distributed system becomes more challenging they're often treated as the system of record or a source of truth this is the one database there's only one database there's only one instance of this one thing somewhere when in truth in real life that's not really true at all right we have information all over the place we have copies of information all the time we have information on the TV we have information on the web we have information in newspapers we got little slips of papers we were handed when we came in here for registration there are all sorts of copies of everything right we don't necessarily always go back to the record system of record or the source of truth we use the copy we have so it's relatively easy to scale reads for persistent services mostly through a pattern called a CQRS command query responsibility separation will separate the reads from the writes so it's actually pretty easy to scale reads we can actually make lots of copies of the data and people can read them but it's a real challenge to write because I don't have things like to face commit or cross cross service or cross table commits in any way instead most typical pattern is to use a thing called a saga pattern has anybody heard of a saga pattern Chris Richardson who's speaking here in doing a two-day class at the end of the end of the week has a great write-up on how to use two flavors of the saga pattern to get things done Amazon uses the saga pattern every day you go order something from Amazon you you say I want one copy of this book and I'm gonna pay with this credit card and I want you to ship it like this and Amazon says you're all set to go of course they're lying you haven't trade they they haven't looked at any of that yet they just say yes go ahead and move on move on and then they go back later and they check and my credit card is bad so they're like hey you know that you know you might you might want to check that and then I'll say halt alright never mind cancel the order right so then they have to they have to undo the shipping part undo the charge part let's never worked anyway and put the thing back in stock right those are the sagas those are the compensating transactions and that's how banks work as well by the way banks don't change money in real time they change money once a day there's a there's a commit at midnight in the ACH system in the US everything else is all just just transactions that will resolve later sometime so it turns out persistence often is I want I want to write something to logical storage and there are a lot of possibilities that could go wrong so what if it takes too long what if the dependent service on the other end doesn't respond in time what if that service is down at the other end or what if the network is down at the other end what if data overflows in other words that actually fails when I attempt it these are all things we have to deal with so now I have a bunch of things that from Nygaard that I need to employ I have to make sure there's a fail fast that I can tell people to go away if I need to that sometimes referred to as a back pressure problem probably gonna use a timeout when I call the other service when I try to write the data to that and remote data service I may need a circuit breaker if I can't write it here I'm gonna have to write it maybe to a queue to be handled later I need steady-state I need to make sure that the disk doesn't run out that I don't run into trouble we're along the way so there's a lot of stuff to do so I want to talk about one more thing and that's the aggregator service this is the this is the marketplace of Agra got oh these are all the scholars these are brilliant people they're kind of like our our ended are sort of stateful people in the in the fields of purity but they actually can put things together you ask them a question and they know all of the people that they can talk to to find the answer to the problem and they arrange all of those people together it may take a little bit of time but they figure out how to solve your problem even though they don't know a thing themselves all they know are other people who are smart and they arrange it all together and they're an amazing amazing group of people and you can go to this marketplace and you can ask people questions and if they know the answer they'll arrange to get all the people together to solve your problem quickly and easily and that's what aggregator services are like aggregator services depend on other distant micro services they might be next door they might be around the world they might have moved from yesterday to today so you're very network dependent if the network is down I can't get my work done there's a lot of challenges there they can sometimes also be disc IO dependent either there's a local dependency to keep certain track of state or there's a dependency somewhere else along the line this is actually the most often needed service the aggregator service this is where we think we're actually going to get our work done we're gonna use lots of micro services to solve our problem it's actually the hardest to do it's incredibly hard to do for lots and lots of reasons the biggest reason is the relativity of time time and distance when we're crossing distance when it takes time lots of things can go wrong so one way to work on time is this this difference between sequence and parallel calls how much can i parallel eyes when i'm trying to aim orchestrate a lot of services how much do I have to do in sequence and this actually can affect the way you design a service as well if I need to create a new customer and then I need to create a new set of accounts for that customer I got to wait until that customer record comes back so I have a customer ID to create the accounts however if I can create a customer and the accounts at the same time and then associate them and another I can paralyze that action right so there are lots of ways that you can design systems to to improve your ability to deal with time sequence is important but it's not always important they should be easy to scale but because of what I just described it could be really challenging most of us think of getting work done in a sequence step one step two step three we sort of live in this Newtonian world where we think that everything happens is in action and equal reaction we forget that actually we were told more than a hundred years ago that we live in a relativistic world where time and space are relative where they don't happen in a sequence in an order there's actually a lot of randomness in the world and we could design systems to take advantage of that so I've got a lot of databases I need to gather all those resources and return them based on some query requests do I have to do them in order or can I do them in parallel there's lots of things that can happen here it could take too long the dependent service doesn't answer it might be down there might be an overflow maybe it's unhealthy it's working but I can't write data properly what happens if the traffic spikes suddenly right in the middle of something there's lots of things that go on so I need to employ lots of these things we talked about earlier I need to manage handshaking to check people's health and I need to probably start to come up with some bulkheads to save me from a lot of trouble so it turns out there's a lot going on there it turns out most of your micro service code especially your aggregator code is dealing with the network and not dealing with the service at all there's a great line inside my guards book is all this extra code this clutter necessary it turns out the answer is yes there's a the short version of this is nobody calls you up if you're working in a company NIT and says by the way I just ran a transaction and worked great thank you very much now they don't do that right they only call you up when it doesn't work great right hey this thing isn't working I can't find a blah blah blah so all this clutter all this dealing with all of the randomness of networks is to prevent those calls from happening now we're not gonna have time to go to this next section because I want at least some time we have some questions not yet okay so maybe I'll talk a little bit more please be sure to add some questions in there otherwise they won't be able to give away books so I'll talk a little bit about some things after this we're not gonna get a chance to talk about all these details but you'll get the slides afterwards I want to go back out and talk about another interesting place in all this and this is this is the this is the gardens of samanya this is the the place where everything kind of gets put together there's an amazing group of people in this community that actually know how to sort of create messages through flowers flower arrangements they actually speak to each other by arranging these different colors and shapes and flowers what they're really doing is they're actually integrating a lot of things together they're actually using a unique language that's usable by all these different communities who speak other languages it's a generalized universal language that's what Interop is in the web our Interop happens through a language of HTML right it's the language of the of the Internet it's the language of the web so you I can build an accounting system with that language I can build a content management system with that language I can build all sorts of things with that same language over and over again I don't need to know about your objects I don't need to know about your data model I don't need to know about anything interoperation is peer-to-peer and it works because we have a shared semantic understanding what happens is the clients and servers on the web understand HTML and HTTP they understand the message protocol and they understand the content of the message which is HTML CSS and JavaScript is actually just an add-on by the way it turns out we're now so dependent on JavaScript it's no longer an add-on our apps don't work anymore and that is not a language that should the JavaScript language is shared but what it's talking about is not shared I'm gonna talk briefly about this idea of sign signal and symbol from yen's Rasmussen this idea that we can break up the way we think about things we get some signal like it's it's hot in here and that's a sign of something which means maybe it's getting past some comfortable point in the temperature and that's usually a symbolizes that somebody needs to go adjust the thermostat somewhere when we start to create autonomic systems we have to deal with signal sign and our brains deal with it in instantly we don't really think about it in broken spaces signal is the protocol and that protocol is usually things like HTTP or co-op or mqtt signs are the formats like HTML or hell or collection JSON or siren or uber or Mason by the way not XML or JSON those are not formats those are just C realizations like plain text write symbols symbol actually represents what something means there are vocabulary managers like dublin core application profile or application level profile semantics these are languages these are these are formats and that helped us share a language together all right do we have some questions yet oh we have some questions

1 Comment

Siddharth Kulkarni · July 29, 2019 at 1:39 pm

Main talk starts at 3:28

Leave a Reply

Your email address will not be published. Required fields are marked *