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.

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!

5. Microservices
https://martinfowler.com/articles/microservices.html

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

8. Monolith First
https://martinfowler.com/bliki/MonolithFirst.html

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?

12. Modular 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?

15. Modular Architecture

16. Some Good Patterns
https://dzone.com/refcardz/patterns-modular-architecture

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?

21. Micromodules Architecture

22. Splitting your system into
manageable, self-sufficient
services modules

23. Bounded Context
https://martinfowler.com/bliki/BoundedContext.html

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

34. Growing Microservices

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

37. Database
SEPARATION TO “MICRODATABASES”
Core
Core
0
2
Payments
Payments
Database
Core
Core
Payments
Payments
DatabaseDatabase
Core
Core
Payments
Payments
1

38. EVENTUAL CONSISTENCY

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

40. Practical Advices

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