Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Dmitry Buzdin, profile picture
Uploaded byDmitry Buzdin
702 views

How to grow your own Microservice?

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.

Software◦
Related topics:
Insights on Software Development•
How to grow your own Microservice? Dmitry Buzdin
Started a small consultancy company • DevOps • Test Automation • Software Architecture • Java/JVM • Other Stuff: Agile/Web/Mobile @buzdin About Presenter
Agenda • Why (not) microservices? • Modular architecture • Micromodule architecture • Migrating to microservices • Practical Advices
Welcome to the Wonderful World of Microservices!
Microservices https://martinfowler.com/articles/microservices.html
Splitting your system into manageable, self-sufficient services http://microservices.io/
Why Microservices? • Delivering value faster • Easier to maintain then monolith • Easier to change tech stack • Easier to replace parts of your system • More scalable
Monolith First https://martinfowler.com/bliki/MonolithFirst.html
Why not Microservices? • Difficult to move functionality between services • Sophisticated DevOps rituals • Infrastructure overhead • Distributed communication • Transactional boundaries
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 $
How do you start and improve an Evolutionary Architecture?
Modular Architecture
What is a Module? • Can be reused as a separate file • Has bootstrapping functionality • Could be developed/compiled separately • Depends on libraries/frameworks/modules
Reasons for Modules to Exist • Reusable utility classes • Platform plugins • Client APIs • Service API implementation modules • Others?
Modular Architecture
Some Good Patterns https://dzone.com/refcardz/patterns-modular-architecture
Modularity Breaking Bad and more useful advices…
Module Hell • Module overengineering - module per-layer/per- logical-component anti-pattern • Fake modules - can not be deployed or tested independently • Interdependent modules
Reuse Release Equivalence Principle http://wiki.c2.com/?ReuseReleaseEquivalencePrinciple
How to use modules properly?
Micromodules Architecture
Splitting your system into manageable, self-sufficient services modules
Bounded Context https://martinfowler.com/bliki/BoundedContext.html
Bounded Context Module Database Schema Persistence Layer Application Layer API (Local)
Lots of micromodules are deployed together
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
Same Storage • Common database for many micromodules • Separate schema for every bounded context • Compatible approach for schema migrations
Module Types • Bounded context (documents, users, payments) • Aggregates • Service provider interface modules • Third-party integrations • API Facade • Client API • Products
Modular Monolith CRM CMS Payments CRM CMS Payments AdminMarketing API Facade Database Application Payment Gateway Bank X Gateway Client API My Product Config
Microservice Extraction CMS Payments CRMCMS Payments AdminMarketing REST Facade Payment Gateway Bank X Gateway My Product Config CRM CRM Product REST Facade Config
Thinking in Modules • Run all on local machine • Keep modules small and self-contained • Deliver modules fast • Rewrite later
Why Extraction? • Common service for different products • Separate frequency of deployments • Completely different usage patterns • Deployment topology changes • Scalability reasons • Security reasons
Product Modules • Product specific features • Product specific schema • Single branch - multiple products • Product == Deployment unit
Growing Microservices
STAGED APPROACH • There is no defined “architecture” • Modules come and go • Some modules are upgraded to microservices • Improvements is a constant process
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
Database SEPARATION TO “MICRODATABASES” Core Core 0 2 Payments Payments Database Core Core Payments Payments DatabaseDatabase Core Core Payments Payments 1
EVENTUAL CONSISTENCY
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
Practical Advices
Don’t Write Reusable Frameworks • Keep technical reusable code to minimum • Reuse open sources packages • Minimal common platform code
API-First Design • Sync/Async • REST API • Event-based • Test-driven development • Documented (Swagger, RAML, ProtoBuf, json-schema)
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
Persistence • ORM - data preparation and updates • Direct SQL - read-only data retrieval and aggregation
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!
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
SQL/NoSQL • PostgreSQL • Relational data model (sql) • Property based (jsonb) • Key-value (hstore) • Full-text search
Testing • Integration testing is a must • Relaxed approach to unit testing • Docker for testing and local dev • Acceptance testing is great, but expensive!
DevOps • Automated Jenkins Pipelines • Dev -> Test -> Stage -> Prod • One-click deployments • Limited use of Nexus/Artifactory (artifact in pipeline)
Kubernetes • Becomes the default platform for microservices • Managed platform on Cloud – maybe ok • Local installation, or manual support – think twice!
Summary
Micromodules • Same benefits as micro services, except scalability and hybrid technologies • Greatly reduced complexity • On-demand upgrade to micro services
Start using micromodules now! Migrate to micro services later, when you have lots of money, devops and teams
How to grow your own Microservice?