How to grow your own Microservice?
2 likes695 views
The document discusses how to grow microservices from a monolithic architecture using a staged approach. It recommends starting with a modular monolith broken into bounded context modules that can be deployed and tested independently. These modules can then be upgraded to independent microservices by separating databases, exposing APIs, and moving to an eventual consistency model. The process should be iterative, allowing code to be refactored and services extracted gradually based on factors like scalability needs and usage patterns. Practical advice includes API-first design, avoiding reusable frameworks, using schema per bounded context, and embracing testing and devops best practices.
How to grow your own Microservice?
- 1. How to grow your own Microservice? Dmitry Buzdin
- 2. Started a small consultancy company • DevOps • Test Automation • Software Architecture • Java/JVM • Other Stuff: Agile/Web/Mobile @buzdin About Presenter
- 3. Agenda • Why (not) microservices? • Modular architecture • Micromodule architecture • Migrating to microservices • Practical Advices
- 4. Welcome to the Wonderful World of Microservices!
- 6. Splitting your system into manageable, self-sufficient services http://microservices.io/
- 7. Why Microservices? • Delivering value faster • Easier to maintain then monolith • Easier to change tech stack • Easier to replace parts of your system • More scalable
- 9. Why not Microservices? • Difficult to move functionality between services • Sophisticated DevOps rituals • Infrastructure overhead • Distributed communication • Transactional boundaries
- 10. eBay Architecture • Perl MVP in 1995 • C++ DLL with 3,4 mil single dll in ~2005 • Java services later • Polyglot microservices now http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html Took 20 years, 1000s of devs And billions of $
- 11. How do you start and improve an Evolutionary Architecture?
- 13. What is a Module? • Can be reused as a separate file • Has bootstrapping functionality • Could be developed/compiled separately • Depends on libraries/frameworks/modules
- 14. Reasons for Modules to Exist • Reusable utility classes • Platform plugins • Client APIs • Service API implementation modules • Others?
- 17. Modularity Breaking Bad and more useful advices…
- 18. Module Hell • Module overengineering - module per-layer/per- logical-component anti-pattern • Fake modules - can not be deployed or tested independently • Interdependent modules
- 19. Reuse Release Equivalence Principle http://wiki.c2.com/?ReuseReleaseEquivalencePrinciple
- 20. How to use modules properly?
- 22. Splitting your system into manageable, self-sufficient services modules
- 24. Bounded Context Module Database Schema Persistence Layer Application Layer API (Local)
- 25. Lots of micromodules are deployed together
- 26. Micromodules • Micromodules can be started and tested independently • Deployed on same technological platform • Runs in a single process/VM • One or multiple deployable artifacts in the end
- 27. Same Storage • Common database for many micromodules • Separate schema for every bounded context • Compatible approach for schema migrations
- 28. Module Types • Bounded context (documents, users, payments) • Aggregates • Service provider interface modules • Third-party integrations • API Facade • Client API • Products
- 29. Modular Monolith CRM CMS Payments CRM CMS Payments AdminMarketing API Facade Database Application Payment Gateway Bank X Gateway Client API My Product Config
- 30. Microservice Extraction CMS Payments CRMCMS Payments AdminMarketing REST Facade Payment Gateway Bank X Gateway My Product Config CRM CRM Product REST Facade Config
- 31. Thinking in Modules • Run all on local machine • Keep modules small and self-contained • Deliver modules fast • Rewrite later
- 32. Why Extraction? • Common service for different products • Separate frequency of deployments • Completely different usage patterns • Deployment topology changes • Scalability reasons • Security reasons
- 33. Product Modules • Product specific features • Product specific schema • Single branch - multiple products • Product == Deployment unit
- 35. STAGED APPROACH • There is no defined “architecture” • Modules come and go • Some modules are upgraded to microservices • Improvements is a constant process
- 36. MICROSERVICE INCUBATION STAGES Application Core & Payments Application Payments Core RabbitMQ Payments ServiceApplication PaymentsCore RabbitMQ 0 1 2 3 Application Payments Core In-Process Java API
- 39. REFACTORING TO MICROSERVICES • Staged refactoring approach would increase confidence and success rate significantly • Every “iteration” of changes ends up in a release and being tested together with the product • Existing code gets refactored • Possibility to stop and re-plan at any time
- 41. Don’t Write Reusable Frameworks • Keep technical reusable code to minimum • Reuse open sources packages • Minimal common platform code
- 42. API-First Design • Sync/Async • REST API • Event-based • Test-driven development • Documented (Swagger, RAML, ProtoBuf, json-schema)
- 43. Do Not Expose Internals • API contract annotations with generated client • Defensive coding and validation in the service • Event-based decoupling • Do not expose persistent objects
- 44. Persistence • ORM - data preparation and updates • Direct SQL - read-only data retrieval and aggregation
- 45. Schema per Bounded Context • It is ok to have a lot of schemas in a single DB • Schemas ensure logical data separation • Cross-schema requests are possible • Security control on schema level, not on table level!
- 46. Data Modeling • No foreign keys between different bounded contexts • Simple data structures - use JSON if required • No deletes, few updates - insert only • Everything is auditable
- 47. SQL/NoSQL • PostgreSQL • Relational data model (sql) • Property based (jsonb) • Key-value (hstore) • Full-text search
- 48. Testing • Integration testing is a must • Relaxed approach to unit testing • Docker for testing and local dev • Acceptance testing is great, but expensive!
- 49. DevOps • Automated Jenkins Pipelines • Dev -> Test -> Stage -> Prod • One-click deployments • Limited use of Nexus/Artifactory (artifact in pipeline)
- 50. Kubernetes • Becomes the default platform for microservices • Managed platform on Cloud – maybe ok • Local installation, or manual support – think twice!
- 51. Summary
- 52. Micromodules • Same benefits as micro services, except scalability and hybrid technologies • Greatly reduced complexity • On-demand upgrade to micro services
- 53. Start using micromodules now! Migrate to micro services later, when you have lots of money, devops and teams