Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Let's mythbusting micro service architecture


Published on

44 uadevclub meetup

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Let's mythbusting micro service architecture

  1. 1.
  2. 2. Let’s Mythbusting MSA
  3. 3. not a day without cute kitten...
  4. 4. About me
  5. 5. Now
  6. 6. A few weeks before... ● CTO@WhyNot? (European technological startup) ● Experience in IT 9+ years ● 3.5 years experience with SOA, MSA ● XP fan ● OCPJP ● Scrum Master
  7. 7. What is MSA
  8. 8. But MSA is... Expectations Reality
  9. 9. Byte Code, etc. Var, Methods/func
  10. 10. Byte Code, etc. Var, Methods/func OOP: Classes, Objects
  11. 11. Byte Code, etc. Var, Methods/func OOP: Classes, Objects Packages/namespaces
  12. 12. Pack age/ modu le Monolith
  13. 13. Pack age/ modu le Monolith Client-server SOA
  14. 14. Pack age/ modu le Monolith Client-server SOA MSA
  15. 15. Martin Fowler article mythbusting
  16. 16. Scaling
  17. 17. ● It’s all about single AppServer vs multiple AppServers ● Almost Same CPU&RAM (even more with MSA) ● Less CPU&RAM when a LOT Microservices only (1 service should not be deployed at all servers) ● more network with MSA (communication between services through network encrease) ● Both can horizontal scaling
  18. 18. Scaling
  19. 19. Componentization via Services One main reason for using services as components (rather than libraries) is that services are independently deployable. If you have an application that consists of a multiple libraries in a single process, a change to any single component results in having to redeploy the entire application
  20. 20. ● It is not a reason, when deployment in Java is mess (Java 9 promise to add more modularity) ● More complexity to deploy multiple services: ● each service has own deployment cycle => nonlinear deployment process
  21. 21. Ok, wait bro, what do we need to deploy monolith? ● Use normal languages (that supports zero downtime re-deploy, etc.: PHP) ● In case of Java, etc. : 1. use already written tools (ElasticBeanstalk etc.) 2. Or just simple solution: 1. turn off one of this guy (load balancer will do rest, if your app stateless of course) 2. redeploy whatever you do 3. turn on 4. Back to p.1 while you have app servers
  22. 22. But wait... If you have MSA, it doesn’t mean that you don’t have all those problems with redeploy Cons: ● You should always think about API backward compatibility, cause redeploy only one service, within incompatible API, could broke everything => your environment should be consistent anyway ● Service could be on differ languages and differ environments => complexity of deployment process encrease Proc You made really MSA and good Continuous Delivery cycle, and you have strong DevOps in team - in this case add new services/redeploy existing could be easy...compared to “bad” teams within manual delivery cycle
  23. 23. Componentization via Services
  24. 24. Organized around Business Capabilities ● When looking to split a large application into parts, often management focuses on the technology layer, leading to UI teams, server-side logic teams, and database teams. ● When teams are separated along these lines, even simple changes can lead to a cross-team project taking time and budgetary approval. ● A smart team will optimise around this and plump for the lesser of two evils - just force the logic into whichever application they have access to. Logic everywhere in other words. This is an example of Conway's Law in action.
  25. 25. Wrong
  26. 26. Right
  27. 27. But why you can’t do like that?
  28. 28. Because it is little bit more complicated? ● You need to separate layers more clearly ● Not to allow mix business logic and data access layer (for example) ● Make regular code review
  29. 29. BTW, we know that cross functional team is better long time ago
  30. 30. Hey, and what about “Logic everywhere” ● In just need: ● XP practices: TDD, Code Review, Pair programming ● Prevent spaghetti code ● Read Clean Code (written at 2008) ● ...and Big Ball of Mud ( written at 1999 If folks wrote good code almost 20 years ago, why you can not today?
  31. 31. Looks like Martin Fowler compare creepy team that build monolith peace of s***t and excellent team that’ s build high quality products. So...
  32. 32. How big is a microservice? ● 2 pizza team per service ● 1 dev per service ● *habr idea: 1 service should fully placed in 1 dev head
  33. 33. My best practice ● You should split by logic, not by size, team members ● From practice: 2week - 2 mo / V1 service /1dev-2pizza size team ● Split only by logic. You should not have “functional” services (ex. DbCrudService)
  34. 34. Products not Projects ● Project Team Support team ● Not good for product. Less responsibility ● Team should own a product over its full lifetime ● There's no reason why this same approach can't be taken with monolithic applications, but the smaller granularity of services can make it easier to create the personal relationships between service developers and their users
  35. 35. Smart endpoints and dumb pipes ● No ESB ● RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool ● common use is messaging over a lightweight message RabbitMQ or ZeroMQ ● Reduce communication between modules
  36. 36. Decentralized Governance ● Differ tool for differ type of apps ● Node.js to standup a simple reports page? Go for it. C++ for a particularly gnarly near-real-time component? Fine The main idea here is that we don’t need to use Enterprise Service Buses (ESB)
  37. 37. Microservices and SOA ● What is SOA? Actually it is Microservices that could live on ESB, could use smart pipes (could use EIP) ● From My Point-of-View - MSA is special case of SOA
  38. 38. EIP today, it is the same as use stored procedures nowadays. No one use it in modern projects. All BL execute on endpoints
  39. 39. Smart endpoints and dumb pipes Decentralized Governance Microservices and SOA
  40. 40. Decentralized Data Management You can use polyglot persistence in a monolith, but it appears more frequently with microservices
  41. 41. Let’s remember what polyglot persistence is?
  42. 42. What should we do with dao? ● Implement dao on each layer mean that we break KISS ● If we made dao module, we can’t use it in different programming languages ● In case of many NoSQL (ex. Schema-less, document-oriented DB) we can’t control validation (ex. field should/shouldn’t be Null) ● Convention over configuration add much more cross-team sync (we try to get rid of it) ● How to manage access level for each microservice? How to make that one microservice could make full CRUD, and other one only Read? Add user groups on DB level force to use smart pipes and centralized Governance (we try to get rid of it)
  43. 43. My solution ● DAO modules with differ access level for group of services ● Try to reduce modules on differ languages that need to use same DB Anyway: MSA + DAO == Re-investigate the well, every time you need this layer
  44. 44. Decentralized Data Management On monolith much more easy to implement Polyglot Persistence. Anyway...
  45. 45. Many languages, many options ● Many languages ● JVM-based languages ● High level and DSL languages
  46. 46. Let’s be honest, when customer hire us, he describe product, like: ● Awsome ● Innovative architecture ● Completely new design ● This product will change the world
  47. 47. In real life, 95% of all projects looks like this: Service provider 1 Service provider 2 Service provider N Custom API Adapter to single API Client Web Client Moblie Very old business logic written on Java 1.3
  48. 48. In multilanguage MSA projects you expect:
  49. 49. In practice you’ve got:
  50. 50. What is the common thing in the next technologies?
  51. 51. It’s all legacy
  52. 52. What is really more important: ● You could start new modules with new version of existing language/technology ● You have ability to add new language if it’s really need ● You’ve got more happy and could hire more qualified developers: support old legacy code - it’s only one part of work. Most time you write new microservices. No one likes to support legacy and fix bugs 100% work time
  53. 53. Risks ● Most of apps - don’t need multiple languages/technologies ● Requirements to Developers qualification - increase ● New technologies - new business risks ● If you wrote microservice on “popular” technology, and single developer, that knows this “exotic” language, fired - you could not find 2nd same developer on market
  54. 54. One more important thing: do you remember this slide?
  55. 55. We want cross-functional team ● How to prevent creating Java/Python teams? ● Siloed teams could be made on more high-level, with more complex problems
  56. 56. Just imagine ● 1 cross functional team should write&support 3 modules on 2 differ languages ● Let’s say - 2 modules on Java and 1 module on PHP ● For 1 module - 1 PHP developer should be enough...but you should hire 2 - because you will break all good XP practises (code review, knowledge sharing for ex.) ● Architector/team leader - should also know both Java & PHP to manage team in right way (cost of such kind of pearson - encrease)
  57. 57. Anyway, Many languages, many options, used wisely - is always good
  58. 58. Battle-tested standards and enforced standards ● HTTP, ATOM and other microformats ● IETF My Point-of-View: ● No need to use outdated approaches in development (ex. SOAP) ● New Microservices could be written with new version of language/technology No need to follow old convention-over-configuration ● No vendor-locks Definitely
  59. 59. Infrastructure Automation ● The main idea in this paragraph: if you already have Continuous Integration and Continuous Delivery - it doesn’t matter how many services you have. ● If you able to make CI and CD on monolith - you could easily scale this practise on MSA
  60. 60. It is NOT working like that Differ service => differ build cycle & differ deployment cycle What else do you need to add new MicroService: ● Define your silo requirements (what kind of DB, 3rd party services, network config you need, to test/build/deploy your MicroService) ● Add new vcs (ex. git) repo ● Add new artifact repository (ex. nexus) repo ● Add new CI process (how we will distribute that concret service: deb/rpm, docker) ● Add new CD process (how we will delivery that concret distribution: chef, bash etc.) ● Configure silo according to your requirements (install&configure DB, 3rd party services, network)
  61. 61. Add new MicroService could be automated if... ● Services as alike as two peas in a pod In other cases, add new microservice always is adventure So you need a guy in team that will do that job permanently. It’s called DevOps
  62. 62. DevOps complexity
  63. 63. Trend for more Virtualization Typical app: DC => Server Container => Server Rack => Physical Server => VM => LXC (Docker) => xVM => AppServer => your code
  64. 64. Not really “cheap” Infrastructure Automation ● Avoid situation, when your infrastructure takes 2 times more than your code. ● You definitely need, CI and CD but with MSA it’s more complicated ● Maybe it time to think about something like: Infrastructure Driven Development. Let’s make devs responsible for everything: find out business requirements, develop it, test it, ship it.
  65. 65. Design for failure ● Since services can fail at any time, it's important to be able to detect the failures quickly and, if possible, automatically restore service. ● Microservice applications put a lot of emphasis on real-time monitoring of the application ● This isn't to say that monolithic architectural styles aren't capable of sophisticated monitoring setups - it's just less common in our experience ● Microservice teams would expect to see sophisticated monitoring and logging setups for each individual service such as dashboards showing up/down status and a variety of operational and business relevant metrics. Details on circuit breaker status, current throughput and latency are other examples we often encounter in the wild
  66. 66. More about monitoring Like almost everything in MSA: you’ve got more atomicity, but complexity increase Basic monitoring: you know that everything work or not working Advanced monitoring: you know exactly what was broken
  67. 67. Evolutionary Design ● independent replacement and upgradeability ● rewriting without affecting its collaborators ● many services to be scrapped rather than evolved ● replaceability ● granular release planning ● only use versioning as a last resort
  68. 68. And even more from my practice: ● Happy developers ● Less bug fix work ● Doesn’t need to keep working with deprecated, old, legacy technologies
  69. 69. Monolith first ● Almost all the successful microservice stories have started with a monolith that got too big and was broken up ● Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble ● you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile
  70. 70. ● MicroservicePremium, which means they are only useful with more complex systems ● Yagni
  71. 71. Keep code and layers clean (follow boy scout rule), make it “microservice- migration ready”, and one sunny day you will migrate to microservices. Yeah, right...
  72. 72. Are you familiar with it?
  73. 73. Try to make sure that you able to add new microservices around existing monolith core
  74. 74. Monolith first
  75. 75. It’s coffee time :)
  76. 76. Visibility area. You think your architecture will look like this?
  77. 77. No way. Commonly it’s looks like this
  78. 78. Access modifiers Commonly in OOP languages access modifiers have next level : public, private, protected, package-visible In MSA I have identified the following access modifiers: Public NoAuth UI MicroService SSL. No Auth Public +Auth UI MicroService SSL + Auth Private NoAuth Private Services MicroService VPN + SSL. No Auth Private +Auth UI MicroService VPN + SSL + Auth Optional.Service Could be autonomy Optional.Service Could be autonomy
  79. 79. But I just want MSA... MSA == over engineering...mostly Try avoid redundant architectural complexity ● Start with a few “public” services ● Don’t try to over engineering ● Try to follow YAGNI ● KISS works for MSA too ● Loose coupling high cohesion (read about GRASP) ● Try to follow next man: Monolith => multi-module => keep components close to each other by logic, not by functional layers (admin panel should keep UI, REST and BL in different layers but in same module) => microservices
  80. 80. Refactoring You have CRUD service and you need rename method name TODO refactoring in monolith ● Shift+F6 (refactoring rename) TODO refactoring in MSA ● :)
  81. 81. How to do refactoring in right way? You can’t change all suppliers synchronously? Ok, than: ● You should mark existing API as Deprecated ● You could versioning your API It’s all true not only for RestApi, also for public libs
  82. 82. Only use versioning as a last resort ● Backward compatibility ● Flexible deserialization ● Case insensitive ● Service-dead ready ● Smaller services == less versioning ● Avoid dependency hell
  83. 83. Communication issues Monolith MSA Client HTTP POST Server /service/weather [{“city” : “Paris”}] [{“t” : “+16”, “wind: 25 km/h”}] REST RESTFul WebSocket Queue Legacy protocol
  84. 84. Yet Another communication issue... You can’t use proprietary (ex. language-lock) tech. Hopefully there is an analog ● Java RPC => Json-RPC ● Object serialization => marshalling
  85. 85. Debugging ● Avoid service start ordering ● Make sure that your service support “multi-DB” (in case of heavyweight prod DB) ● Difficult unreproducible scenarios: someone already read your message from queue, some required services even doesn’t up yet...
  86. 86. Useful techniques
  87. 87. VS Prepare service to Dead not to Reuse: ● Think more about MicroService public API ● Don’t focus too much on scaling ● Make service as small as possible to fit this service requirements ● Half of your app should not go down, when you throw away single service ● Do not make “single point of failure”
  88. 88. Do not try to Service-ish everything At least 3 types of modules: ● MicroServices ● Shared components (dao, entity) ● Common libs (utils) Depend on language, business type. But my current proportion 1:1:1 It doesn’t mean: 3 modules - 1 MicroService, 1 Shared Component, 1 lib It’s mean: ~50 modules: ~15-20 microservices, ~10 Shared Components, ~ 5-10 libs
  89. 89. IT: it’s a lot about money ● Development costs are higher in short & middle-term ● More expensive employees... ● ...with a desire to self- development ● You can’t hire “code-monkey” guys, even if you really want
  90. 90. TDD Without TDD - you have nothing to do in MSA world
  91. 91. But even a “sharks” of TDD and XP could fail
  92. 92. Pyramid of testing
  93. 93. Unit & Compo nent Tested Integration Tested
  94. 94. Unit & Compo nent Tested Integration Tested “Forgot” End-to-End testing A B
  95. 95. Integration testing complexity ● BDD, CDD... ● All of these new techniques will only to be learned ● New cool tools for complex MicroService testing will waiting for us in future
  96. 96. Evolutionary of development methodologies
  97. 97. Than folks remember about Agile manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
  98. 98. Do you remember following slide?
  99. 99. Pack age/ modu le Monolith Client-server SOA MSA
  100. 100. MSA - it is not “the END” should be something more granular
  101. 101. Continuous Modularity
  102. 102. How to build good MSA?
  103. 103. There is NO silver bullet ● Be smart ● Do not over engineering ● Use critical way of thinking ● Do not use all fashion technologies and techniques together ● Always start your day with good mood ● Don’t forget about users. You do your apps for them, and to make world a better place to live
  104. 104. Special Thanks to
  105. 105. Q&A
  106. 106.
  107. 107. Used materials: Strong.jpg EgDhdK2rCWUzZOJS0OFiGpoi9qn8iMH2nuXHgWg2PA=h900 food.png Jamie-Hyneman-in-Mythbusters.jpg https://lostcoastoutpost. com/media/uploads/post/14486/57a5f0dd57a47e1bdb441cb7c5efc6 96.jpg jpg/revision/latest?cb=20130711155107 10-23-at-5.45.58-PM-300x142.png 10-23-at-5.45.31-PM-300x146.png http://connectivity.opentext. com/common/images/articles/server_network.png icon-update.png content/uploads/2014/09/microvsmono.png failures/ https://assets.graffletopia. com/production/canvases/137/1973/1400528214/original.png? 1400528214 png http://vignette2.wikia.nocookie. net/assassinscreed/images/7/73/Trollface.png/revision/latest? cb=20110812045715 https://hsto. org/getpro/habr/post_images/16d/aad/a99/16daada99ab921ea5311 c6418e459e18.png 2/nvidia-cuda.jpg
  108. 108. Used materials (continue): net/media/TNBlogsFS/BlogFileStorage/blogs_msdn/swiss_dpe_tea m/WindowsLiveWriter/Migratingfrom.NET1.1to2.03.0and3. 5_9C76/image_thumb.png BC%D0%B8%D0%BA%D1%81%D1%8B-%D0%BA%D0%BE% D0%BA%D0%B0-%D0%BA%D0%BE%D0%BB%D0%B0-%D0% B4%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%BE-troll- face-76278.png png?version=1&modificationDate=1335877101387 48x48.png content/uploads/2015/05/vagrantlogo.png whale.png 150x150-9262_128x128.png https://d3kjp0zrek7zit.cloudfront. net/uploads/product/image/2075/large_detail_1391172976.png RabbitMQ/master/.media/logo.png warming/wheel.ico Monitor-icon.png
  109. 109. Used materials (continue): window.jpg http://www1.pgcps. org/uploadedImages/Offices/Business_Management_Services/Bud get/Budget-of-punjab-2013-2014.jpg?n=4700 au/sites/default/files/iStock_coffee_Large.jpg png proprietary-chip.jpg https://www.iconexperience. com/_img/o_collection_png/green_dark_grey/512x512/plain/debug. png jpg https://watirmelon.files.wordpress. com/2012/01/automatedtestingpyramid.png jpg content/uploads/2010/12/ILoveTdd.png,h_342, w_618/t_mp_quality/dqnrdue7llwvoah3yvom/fan-theory-did-marty- mcfly-actually-die-in-back-to-the-future-2-344398.jpg s_rihI/AAAAAAAAAd8/WJ2kPvfHn8s/s1600/Uncle-Sam.jpg PJkKTN_rxjk/Upi2D4tKulI/AAAAAAAACNE/rnXZUdlJX9U/s1600/bul let2c.png jpg Flat-270x270.png symbol.jpg
  110. 110. Contact me Skype: privateportal
  111. 111. This presentation under CC-BY 3.0 licence