5. A monolith is...
● ...an architecture style
● ...a way that your code
and business logic is
structured
● ...usually a single code-
base
● ...usually you can deploy
everything or nothing
Image source: https://www.slashroot.in/difference-between-monolithic-and-microservices-based-architecture
6. Monoliths pros/cons
● Calls are inter-process
● Simple development
● Simple testing
● Simple deployments
● Simple infrastructure
● Lack of domain boundaries
● Single technology stack
● Difficult to change
● Slow build/test times
● Slow QA process
7. Where monoliths break down
● Large development teams (>20 devs)
● Lack of developer discipline
● Each change means that you need a full QA
● Bugs/issues break everything
● Rollbacks cause a bottleneck
● Hard to upkeep a good internal architecture
8. Signs of a good monolith
● Strong, comprehensive, and quick test suite
● Requires no/minimal manual QA
● Can be deployed many times a day
● Internally structures code into modules
○ Domain Driven Design
9. A microservice is...
● ...small enough
● ...not too large
● ...a single domain
● ...can be deployed on its
own
● ...owns its own data
Image source: https://spring.io/blog/2015/07/14/microservices-with-spring
10. Microservice pros/cons
● Clear boundaries
● Smaller teams
● Deploy in isolation
● Diverse technologies
● Scalable
● Complex infrastructure
● Network calls
● Distributed systems
● Difficult integration testing
● Difficult cross-domain changes
● Difficult local development
11. Why testing microservices is different
● A lot of integrations to test, usually a lot of mocking
● Contract failure may not show up until UI tests
● Fewer tests for implementation detail
● Test setup on local machine is complex
35. A bit of advice
1. Have strong assertions
2. Keep the configuration close to production as possible
a. Use the same application.yml for testing and production and
override only where necessary
3. Keep the environment close to production as possible
a. Move from HSQL to MySQL db if your prod db is MySQL
4. The artifact is not the jar, but the docker image in microservices world
36. Tools/Technologies at different levels
Unit tests: Junit5, Assertions on AssertJ
Integration tests: Cucumber, Docker containers
End to end tests: TestRail, Cucumber
Contract tests: Pact
How many are devs, QAs ?
How many have experience with microservices?
How many of you use Java?
How many of you use Spring boot?
Usually involves a lot of mocking
Instead of having API producers build a specification on their own, consumers of those APIs can set expectations by letting the producers know what data they want from the API.
End-to-end tests can be expensive and cumbersome to do for every change to the API.
If you're not testing the communication between your Microservices before production, you're going to have a bad time.