reactive microservice architecture with groovy and grails

Download Reactive Microservice Architecture with Groovy and Grails

Post on 30-Jun-2015




2 download

Embed Size (px)


  • 1. Reactive Oriented Architecture withGrails and GroovyBy Steve PemberCTO, ThirdChannel 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.@svpemberWelcome everyone to Reactive Oriented Architecture with Grails and Groovy.!My name is Steve, I work for a Boston-based startup called ThirdChannel, and Ive been drinking coffee literally all day.Lets talk about Architecture

2. Weve got a journey ahead of us folks, over an hour.Ill stop periodically for questions.Last session of the day, I know its a haul. Were almost there. 3. Agenda: 1. Monolithic Apps Will Ruin You 2. Service Oriented Architecture and Microservices 3. Reactive Applications 4. Practical Development (Caveats) 5. Case Studies (Including 3C)THIRDCHANNEL3While I will be talking about Reactive Applications with Groovy, theres a good deal of information surrounding the approach that should be covered first.From a high level, Id group these points into the following topics:1. Monolithic Apps are Evil and will Ruin You2. Service Oriented and Microservice Architecture, specifically their benefits and when you would or wouldnt want to use them3. 4. A Few Questions 5. Have you ever...Gone through a major refactoring of yourapplication?THIRDCHANNEL 5 6. Have you ever...Gone on an Archeological Expedition inthe codebase to add a new feature?THIRDCHANNEL 6 7. Have you ever...Thought Why are there so many #@$!%tables in this database?!THIRDCHANNEL 7Have you ever been distraught at the number of joins needed to fetch a batch of records? 8. Have you ever...Dreaded executing the test suite?THIRDCHANNEL 8-Who here has worked on a major project where the unit tests took longer than 15 minutes to run?-30?- Did you ever notice that developers tend to ignore running the tests when that happens? How was build stability?- On the flip side, has anyone worked on a major project that had effectively NO tests? 9. These are all symptoms of a Monolithic application. If you laughed, Im assuming that the answers were a yes. 10. Monoliths 11. -A monolithic app is: Single, logical executable or unit, often comprised of 3 components for a web app: the View layer (CSS/HTML/JS), the middle tier(contains business logic) and the data storage.-For example, heres an example of an e-comm app: product browsing, catalog management, order processing, shopping cart 12. Monoliths Feel Natural Contains EverythingTHIRDCHANNEL12If youre just starting out with building an application, a Monolith feels natural!The Monolith Contains all application features and all logic necessary for handling a request within a single process. 13. THIRDCHANNEL 13Your developers can generally run ANNNND test the entire app at once, on their laptops 14. Monoliths Feel Natural Contains Everything Minimum Viable Product can be reached quicklyTHIRDCHANNEL14 Perhaps their most attractive feature, is that a development team - even a very small one - can reach the Minimum Viable Product very quickly. 15. Monoliths Feel Natural Contains Everything Minimum Viable Product can be reached quickly Single DeploymentTHIRDCHANNEL15Theres only a single artifact to deploy, which makes deployment and DevOps incredibly easy! (he says sarcastically) 16. Monolithic apps scale horizontally by deploying whole new instances of the monolith, probably behind a loadbalancer.!This is wasteful, as we scale the entire application rather than just the portions that require it.For example -> if were receiving a flood of requests to the Order Processing, we dont need to scale the wholething! 17. However 18. I generally regard these single, logical units as an Evil piece of software.Like I said, it feels like the right thing to do and they tempt you with how easy it is to in the beginning.Why? 19. You start out strong, adding controllers here, domain objects, etc.You can be blinded by early gains toward your first release that you become shortsighted and arent thinking towards the future. 20. As those Domains grow, you start adding relations all over the place.Can you really look at a class or schema diagram like this and really think, Yeah, thats awesome. Nailed it.?-btw, this was the largest I could find on Google images. Im sure weve all seen the massive versions of this that cover multiple pages, taped to the wall.- If you ever have to tape to the wall, done something wrong 21. The Complexity of your application will soon become enormous.!Any gains you think you may have made at the beginning of the project will not continue, particularly once you start to attract users...And grow your team. 22. Scaling Development ishardScaling Development is hard work 23. The ability to add new features, fix bugs, or resolve technical debt cannot scale with the size of the application. Throwing more developers at it also will nothelp, theyll just get in each others way.- One of the best passive-aggressive statements Ive seen- Passive aggressively scrawled on the wall: You cant make a baby in 1 month with 9 women. 24. -And trying to refactor anything? Forget it.-Ive seen it happen plenty of times: Your company will start out by creating a team to reimplement a feature or rebuild an application. Sounds good?Eventually, this team will start taking too long. Soon enough, the managers will be screaming for updates or new features on the old app. So, you end upwith *two* teams, one maintaining the old app, while the other continues the rebuild AANNND maintains feature parity with the old system. 25. THIRDCHANNEL 25As the size of your codebase increases, the computational complexity will exponentially increase and will have adverse effects on maintenance. This hasbeen known for some time; theres been papers written on the subject. Although its difficult to accurately measure. 26. It can also just be downright miserable. Has anyone here ever opened their project, looked at the maze of controllers or domains - that seem to justexplode out at you when opening the folder - and just give an exasperated sigh?Toiling away on a project which is always growing always broken and never seems to get fixed. You work on a small piece all day and nothing everseems to get better? This can have an adverse effect on developer morale and motivation. 27. This is such a misguided architecture, it makes you wonder how exactly we collectively ended up here. 28. I blame it largely at the feet of the large, popular web frameworks, e.g. Rails, Django, Grails.!Dont get me wrong, they have their uses.And yes, I see the irony in complaining about them while at a framework conference! 29. But theyre touted as if theyre the magic cure for building your app or product; that your company should bebased entirely within a framework. You hear folks say, Oh, what are you using in your startup? Why, Were aRuby on Rails shop, obviously!.!Iargue that your framework choice is largely irrelevant (unless its Grails ;)! ). When people ask you whattechnology are you using? the answer should be something like Ugh, well, thats difficult. 30. Architecture Choice is MoreImportant Than AnyFramework 31. Architecture Choice is MoreImportant Than AnyFramework**And we all know that only JVM languages should even beconsidered 32. Questions so far? 1. Steve really hates Monolithic apps! 2. Monolith Development will not scale! 3. Architecture Choice > FrameworksTHIRDCHANNEL32So, to recap:!!Any questions? 33. Shattering the Monolith 34. -Lets take our anecdotal design, an e-commerce store. 35. With SOA, one would break up each feature into an individual component or service, and setup communication between each service over some directservice calls. Eg SOAP or REST.-Note that these calls are traditionally Synchronous over http, so its imperative that each node return as quickly as possible 36. This architecture keeps keeps the individual features easier to manage and keep track of, which reduces overall complexity dramatically as we canexamine each service in isolation, rather than one big code base 37. However, before I go into why thats so important: SOA, specifically, is not without its own issues.!First, having that web of interconnected services can grow out of control. Having to configure service nodes so that each knows where the others arelocated in the network can be cumbersome to manage. 38. ESBTHIRDCHANNEL 38Furthermore, anecdotally, organizations tend to treat SOA differently and have different definitions for what, exactly, SOA is.-In many cases, Enterprise Service Buses (or ESBs) have arisen to deal with complicated traffic. An ESB acts as a piece of middleware that intelligentlyroutes traffic to the appropriate server. Which sounds useful, except This adds an additional layer of complexity to an already complex approach,especially if youre rolling your own ESB.-Often, Ive seen clients that would hook up several monoliths together and call it SOA-Its terrible when these all come together. 39. The Rise ofMicroservicesGiven those pain points, I think that leads right into talking about Microservices, which is a buzzword you certainly couldnt have escaped hewing aboutafter that keynote last night. And every other talk here at SpringOne 40. Microservices Distillation of SOATHIRDCHANNEL40So what exactly is a Microservice architecture?!Ifirmly believe Microservices were born out of a desire to be more specific when we talk about Service Oriented Architecture.! 41. If you look at what people are writing about the approach, you can see that it is clearly an attempt to be more focused about using services.And, certainly, how we manage the teams working on them! 42. Microservices Distillation of SOA Single ContextTHIRDCHANNEL42A Microservice should be concerned with only one context. This helps to avoid having each service become a monolith on its own 43. Back to this example, here weve split up each of the specific components into their own bounded context.!Isay bounded context because thats an important metric. You may h