The journey from monolith to microservices – Mike Gehard | The Lead Developer UK 2016

Just another WordPress site

The journey from monolith to microservices – Mike Gehard | The Lead Developer UK 2016

[Applause] it’s that pressure I don’t know what is he welcome useful hopefully you will find this hugely useful my name is Mike get heard I work at pivotal we have an office here in London I’m going to put in the proverbial if you’re looking for a job please come talk to me London is blowing up the new office is beautiful we need a lot of people to fill it so come chat with me so journey from model to micro-services the goal of this talk is to kind of break up some of the marketing hype it sits around micro services these days so we’ll see how well I do so a little bit about me I up until three weeks ago was a consultant that labs I have now become a lead developer so this conference is perfect for me I’m struggling with all of the things that were mentioned earlier I also worked on the spring cloud services teams this is a team inside of pivotal that builds tools using the Netflix tools to allow micro services very easily in Spring Luton Java so if your spring spring boot Java developer and you’ve questions please come see me I am also trying not to be the chief principal senior consultant scientists they got that from Russ miles at another conference in Stockholm my goal here is to not sell you on micro services not to sell you on monolith it is to give you information about what I think a path might look like and tell you why I think that and tell you the constraints that I worked in to get to that path such that you can make your own decisions as to whether or not you want to follow the path and I’m constantly forgetting to advance my slides to make the color go so let’s see how this goes so about you how many people have a monolith that needs migrating yeah come on really alright let’s keep your hands up how many of you actively migrating that monolith okay keep your hands up please how many people are building micro services right now where the rest y’all do and I thought this was like the greatest thing like this is it this is all we do a software developers so it’s good so hopefully you’ll get something away from this so I’m going to tell you a little bit background where this idea came from none of this is new so if you’re sitting in you’re about halfway through the talk and you’re like yeah yeah this all makes sense I was doing this 10-15 years ago you are absolutely correct unfortunately have forgotten some of this so that’s why I continually remit like to remind people we’ll talk about which comes first so monolith whole monolith versus microservice is a discussion I will give you my opinions you can take them or leave it and then we’ll talk about the path like I said this is one path that I think will work there are many many other paths it really just depends so this idea while not new was kind of formalized by this guy named Mike Beranek he works at tittle as well he was her office director in Boulder for a very long time he came up with this idea of the app continuum so if I’m writing Sinatra and I have 300 lines of code I really don’t have to do a lot with that there’s really not a whole lot I can do with that so I can start here at this end very unstructured as my app grows I can move into namespaces libraries applications with libraries or services this is a continuum this is not that shall pick monolith or thou shalt pick microservices you might end up right here the start of an app and I kind of explain why about six months ago I saw mr. Simon Brown let me know Simon will you please tell him that I think he’s brilliant he has this idea of well-defined in process component as a stepping-stone to out of process component so Dan and I were just talking about this whole idea if you can’t build a well-structured monolith what makes you think you can build a well-structured distributed system full of micro services I love this idea because it gives me room to make mistakes early on and then 1e I can then move along and do the hard stuff so what better way to try this is on a client project yeah this was fine so we had a big client in Colorado think cable communications company what’s so funny okay so big big company getting ready like everybody else to be disrupted by some Silicon Valley company this one just happened to be Netflix and Hulu they came to us and like hey we’ve got this thing it’s working but it’s not the future so they hadn’t migrated a monolith it was a big rails app

unfortunately production making money to a more sustainable filip solution for the future they knew they needed scalability so we’ve Netflix Hulu have proven the fact that as you get more users you are going to become very very popular and your app needs to not fall over when the NBA Finals run or the NCAA finals run so they knew this this was not a guest they knew this they wanted multiple teams to be able to deliver business value quickly that’s almost a given like who doesn’t want multiple teams to deliver business value quickly and they wanted to be able to add and reduce resources pretty quickly so this means getting someone ramped up very quickly they might work for you know a couple of months and then have to go somewhere else so this this was their goal their current state as you can imagine instead of I API servers multiple clients including JavaScript so think Xbox set-top boxes web front-end mobile devices lots and lots of the things this was a fun one set in a meeting one day is like what does this code look like you know how much how much is you’re using they’d had inherited some of this code they’re like well we know it’s between zero and 100 I knew it wasn’t a hundred because the app actually ran and they were making but we didn’t know how much dead code there was so this is dangerous if I don’t have I don’t know how much dead coder is I don’t know what I’m using coupled with the fact that they had a lack of comprehensive current API tests makes that a super dangerous situation to live with why to make it such a super dangerous situation to live with anybody all right we’ll keep going if I take dead code out and I nest no tests fail I assume that that code is not needed until someone calls up and says their player doesn’t work anymore so this was really scary to us okay sweet that doesn’t make is happy so we decided to move along and this is my favorite Oh God say quote of all time from as an engineer so I have two engineering degrees I have a bachelor’s in chemical engineering and a master’s in software engineering so the engineer tried-and-true I love this because as an engineer I know it always depends which is why the huge caveat up front of telling you this is my story in my journey it may or may not resonate with you so there is a drinking game that goes along with this talk every time I say it depends you should drink if you’re drinking coffee you might be a little jittery at the end of this talk if you’re if you’re drinking water it’s okay to head out to the bathroom so which comes first um you know that’s the thing we can go model up to microservices we can start with microservices you ask six people on Twitter you will get seven different answers from said people I am personally leaning towards well-structured monoliths firsts I do not trust myself to get the bounded contexts right for my application to build micro services first that said if you were building a banking app and the app hasn’t changed in 15 years and you don’t foresee it changing for the next 15 years you’re bounding context are probably pretty ok so everyone when I say bounded context I’m talking Eric Gavin’s the blue book which is great nighttime reading if you have trouble sleeping there’s another book it’s a red book I enjoy that better because he actually moves bounded context to the beginning of the book which I feel is the most important piece of the book unfortunately Eric when he wrote his book put at the end so you’re kind of like getting to the back like and not important so these bounded contexts are what we’re doing with our micro-services everybody got anybody on SO a service or any architecture yeah you’re like well this is just that’s the way I’m like yes exactly what bounded context that was the mistake we made with SOA is we didn’t have bounded contexts we put all the logic in the bus and now we had tight coupling in the bus and nobody knew where the logic love so this is why I start with a Model S’s I could play with about it context first before I get distributed systems problems so the path you wanna make a guess what step one on the path is no nice try though how many people know pivotal what do we do first we write test so this analogy of rebuilding this is like flying an airplane so this airplanes flying along it’s not doing so well you need to build another one so you have two options you can land the airplane build the next one move everybody over and take the second plane off or you can fly another little airplane up to the first one at certain means so we built some API level tests

so I’m talking big black box hit from the outside don’t get to touch the database internally at all type tests and we wanted to make sure we didn’t break any client-facing behavior that was our goal because it’s things in production the airplanes flying we don’t want to drop somebody you know 30,000 feet to the ground that’s bad news so this is what your app looks like now we want to go to this this is our end state for the refactoring why not write your test that way it’s just going to hit all these same endpoints the nice thing with these if we decide to gut the application and rewrite it in a new we can still leverage the test to tell us of whether or not the thing still flies any other level of test I believe is waste because they may or may not be reality at this point unit tests those all go out the window because we’re going to change what this thing looks like we use packed any thought workers cool was interesting we had a little trouble with a JavaScript client but it was really cool because we now define contracts between the clients the consumers of the api’s and the producers and the whole idea being if I have contract what’s the first thing you do when you test a JavaScript application you write some little server that just serves up dummy JSON and on the other side when you write the backend you write a bunch of tests that say when I hand you this JSON you’re going to hand me this JSON back the cool thing about pact is you write the contract in JSON it will generate both sides of that for you so you can now run all of that in both test Suites to assert that you haven’t broken the contract because that’s a danger of stubbing things out is if the contract shifts a little bit now you’re dropping people 30,000 feet to their die so we use these to shore up the contracts between the client and the server so that we could run them in both test Suites so now that we had these in place we know when we’ve broken some and we know it very early we get these fast feedback loops we’re not waiting to go to production as the NBA Finals start and then someone complains they can’t run you know the Xbox client or something like that or some ancient version of the client application so step number two you want to arrange your application so you can see your domain nobody knew who ankle bob martin is seeing his talk architecture the lost years this is where this comes from so if you look at this picture what can you tell me about this application it’s a ruby application it’s probably rails because I have modeled views and controllers can you very quickly at the glance tell me what the domain is of this application not very easily about this one this have to be Java spraying but you can do the same thing in rails you can say it’s their web application the web application is separate from the domain and it deals with orders and users very quickly if I need to change something in orders the orders domain what is the maximum number of directories I have to go into to make that change 3 in this application was the maximum directories one maybe two if I’ve got to go up higher into the web application because I’ve got API changes so this is what I mean by organizing your application so you can see the domain granted in Java at this hierarchy of folders you can ignore that so the first thing it does it minimizes the number of directories I have to change or go into change it’s less costly to evolve bounded context and experiments with boundaries because I’m just shuffling files around in a git directory I’m not having to go talk to another team and say hey I want to move this file into your system will you move it heaven forbid into your complete separate git repository I’m a big mono mono repository fan we can discuss that offline but I can just shuffle these things around for a while if I don’t know what they look like it’s a low cost of entry I’m also delaying architecture decisions always delay of the architecture decisions to the last responsible moment and you can just sit here and just iterate on your software so if you’re an early-stage startup you want to be spending money on doing your startup stuff not architecting software if you’re a large bank you might already know what that looks like so you might not want to do this it really just depends the third step is to break out some components so I’ve already given myself a little bit of room by giving myself directories I can now start to put maybe multiple teams remotes of developers into a bounded

context they could begin to understand that there’s not this explosion of where I have to go to find things but now I want to solidify those because when I get to micro-services it’s like having a brick wall between my my applications I’m just going to start to move in that direction of net we had rice paper when they were in the same app I’m now moving closer and close to something like drywall between my bonded context so here java application i have a controller and an application this is my layer i then have a bunch of unbuilt jar files that contain my components i choose to use these things called use case objects they’re simply method objects they are verb named and they have one method called run that’s now my external API to my web application when you could have multiples of these the kicker becomes databases where does the database stop live does it live in the application does it live in the components this is where I get really hand-wavy it really depends the one rule I have is that my migrations only can touch one table why do I make that the hard and fast rule in these code bases winner so I can later separate the databases without having to go into a file and like split up files I can lead to start moving things around so yes they only can touch one table so what have I done I’ve made more room in my code bases so you’ll notice a pattern this set of cost and I had a set of a set of benefits as long as the costs are not greater than the benefits then I’m okay to move on to the next step but if my costs are higher than benefits I’m gaining from moving to the next step I might want to think twice about moving to the next step so I make more room in the code bases for multiple teams they just own that jar file just iterate away the boundaries are getting a little more solid this is a really cool one that rails I believe has floundered on for awhile I bashed rails a little bit but there are other frameworks Java using Java apps to do this – I have no a stricter boundary between my domain which is the important stuff and my framework so if I decide to scrap spring and go to play on this application are the bounded context ever affected by that change go if I do a good job of keeping my framework over here and I’ve out a context over here I can change the applications without changing the amount of context as long as the a pads don’t change I’m moving closer to micro services without the overhead of micro-services so this is where Simon Brown takes it to the next level he will actually say in an application like this the only public interface that I would have are my use cases nobody from the outside world actually knows whether or not I’m using or my sequel or anything like that which sounds a lot like microcircuit cept they’re running on another machine and you get a lot of benefits from stopping here without the overhead of microservices because people will fail to tell you when they sell you on micro services or their huge overheads we put in the next couple of slides so now I’ve decided to promote my first micro service a reasons for this I might want to scale something differently so the problem with monoliths if I have to scale one piece after the whole thing I might have reuse that I want this is a touchy one depending on who you talk to you’re gonna get different answers as to whether reuse is actually legitimate reason for breaking out of micro service there are many other reasons how many people have read building micro services cool so Sam new sam Newman has a great book and if there’s 12 reason while you drag outta my your service 10 12 something like that I am NOT going to cover those I’m actually thinking about a second talk that would cover those you’ll have to stay tuned maybe I can get it ready for next year’s conference and come back and tell you all about it so here’s what I’ve got I’ve got an application the big blue box and I’ve got a couple of components that are talking to each other where I’m going now is this I have two applications talking across the network to each other the greatest thing about this component thing is when I break out email the steps I have to take our build new application right new controller layer communication layer to the outside world

and slot in component that’s it I build a new app I just changed the dependencies in a way I go I now have a problem though cuz I’m talking over a network so I’ve got a big cost the first one is because I was in process before I didn’t have to worry about dispatching of messages that happened automatically by the language now I need to know where that second service is on the network I also need to know possibly how many of them there are how I’m going to route traffic to them how I’m going to load balance them all of this stuff pops up when you break out your first micro service I always have network communication problems now so everyone is a cap theorem what you do this becomes the CA theorem Pickers pick a C or pick an A because I now will have network partitions that’s just a thing I may have vm’s that disappear magically on Amazon who knows so those are my two new costs that I’ve incurred by doing this so I need now need to mitigate those costs the first thing I’m going to do is service discovery I want a phone book so that when billing needs to know where email is I have a layer of abstraction between those and every layer of abstraction I add adds an intuition additional cost that’s the cost I’m dealing with right now I want to mitigate that side of this so not only do I have two more network partitions that could happen but I also have a third application to run a third application that had zero business value I have now simply added overhead to my system the nice thing though so that’d be overhead I got to monitor that thing so if you’re not monitoring your micro services I would suggest you do that but I now get this increased flexibility so I can scale email independently and the billing app doesn’t really know anything about that it’s service Discovery’s job to take care of that the next thing I need to do is deal with partition tolerance because it will happen so what I want to do is prevent this I don’t want the network to fail here and then have everything come crashing down around my head I want this thing to be well behaved I now the distributed system welcome to having a new puppy you have to teach it not to pee in the house you have to teach it all kinds of things and this is one of them is this network partition problem so I would now have this I have a fourth application to more network calls so these network calls are billing asking hey is email okay am I allowed to call email because the last thing you want is one service hammering another service when it’s like treading water trying to keep up because that’s what causes the whole system to fail at Netflix I’ve heard the story that email is their recommendation service so you have this service that they have trouble keeping up I’ve heard stories if you if you notice to be false I’ll stop using it just come let me know you know this goes old wives tales and technology but what I do now is I create this layer such that I know if email is working if email is working I can just go ahead and call through if email fails I am alerted to that fact and given the option of a default method to be called so I now have a fallback so all you functional programmers out there the whole op tional pattern this is it this is the maybe monad in distributed systems I just made that up you can all use that all I want is attribution it smoothly says if ok do this thing if that breaks call this other thing it forces me to think about my fallback methods so my users at the other end don’t get this 400 or 500 5 that comes back I’m sorry I couldn’t complete your request it Netflix it’s the hey here are 10 movies I think you might like but they’re not your from your queue they’re just this can 10 top movies that Netflix gives you so that’s what this does it prevents me from this thing falling over this thing falling over and then my client being getting sad panda but now I have 50% of my applications or non-business value-adding so there’s the cost so I’ve gotten more applications to run and monitor if you’re running Cloud Foundry this becomes a little less of a cost because I can just push applications like nobody’s business really easy if you’re waiting six months to stand up a server to run circuit breaker now there’s a little bit more cost there I have an increased resilience to a system because the network will fail and I’ve got increased visibility of the system as a whole so it’s part of this circuit breaker pattern you want to do some monitoring that you can see what what circuits are open and closed every familiar with circuits circuit breakers in your house you shut them off so you don’t electrocute yourself and you’re like changing lights and things like that if one of these things is open you want to know because you want to get it fixed quickly so the one that we use is histor extreme netflix it’s got a big dashboard and I can see very clearly what services are up what services are down and things like that so that’s it so I now have my

first micro service I have two apps to support it I can continue to break out micro services I can just keep going I’ve already paid a lot of upfront cost like announcer two amateur eyes the cost of that over more of more of my micro services I can change up the communication interface pretty easily because if I change to like a rabid mqq or messaging I just change the application the domain knows nothing about how it’s getting its information or I can do nothing the choice is really up to you as to what the next step is based on your your constraints so some resources this didn’t just pop magically out of my head like Athena so I wrote some stuff about application structure those two pictures of the rails versus spring app came from that blog post the app continuum by Mike Beranek it’s a whole long blog post as a bunch of code that leads you through the steps so you can actually see how this goes down the video from Simon Brown is awesome highly recommended you got a bunch of good good good videos Sam’s book building micro services highly recommended very even-handed in this world he presents a lot of things and says here you make the decision it’s not this you will do this you should do this it’s a little frustrating though because you like I just want the answer what do I do what is step 4 what is the next decision tree I make unfortunately don’t get decision trees anymore they’re really hard to come up with one because we’re high it’s a hard problem and two were very early on in this this evolution of this architecture so we just don’t know what those decision trees looks like yet you know as our many things Martin Fowler is kind of my go-to person for for microservices stuff he’s doing a lot of cool work of bringing other people into write on his blog so I minimized my communication channels by just going to his blog and seeing what’s going on you might have your own and then as far as Java and spring go there’s a project called spring cloud which takes all of the Netflix open source wraps in a really nice spring boot wrapper and makes you do really cool things so for example in spring cloud in order to stand up a Eureka server I think it’s 12 lines of Java code and one annotation and you’re done it’s that easy hystrix is the same way I think it’s same 12 lines of code in a different annotations so some really cool stuff going on in the Java space around this and that’s all I have there may be questions for me there time sweet all right so if you have questions come find me and we’ll go from there so thank you so very much [Applause]