Azure Bootcamp 2018 Sofia
Before you start a microservice architecture ask yourself about:
Do we really need to make a microservice application?
Is the microservice architecture the panacea for software development?
How to shoot yourself in the leg?
Microservice architecture is reliable in long term development with multiple teams, but only under specific conditions.
On the left side you see a monolith application and it’s components all locked inside the green hexagon.
On the right side you see a microservice architecture of the same application where all the components are now separate services communicating over REST API.
And when we speak about communication you should think about it like this:
So, if you still want to do it – here are you first tips…
Make an architecture design
Try to design a documentation covering the following key components of the architecture:
- Service granularity (content splitted by criteria into separate microservices)
- Business function segregation
- Performance oriented segregation
- Message size – avoid large data transport
- Quality-of-service characteristics including transactionality
- Service independence:
- Service Communication
- Business Features availability
- Feature toggles management
- Technologies (best per service)
What shall your documentation look like?
- Highlight issues
- Drive architectural decisions
- Establish a framework
- strongly motivated by business drivers, goals, and other principles
- Well articulated
- are not open to misinterpretation (accidental or willful)
Having separate solutions for each microservice and separate teams with independent delivery timelines requires more collaboration in planning phase of each sprint (feature toggle and message contracting), automated and independent service testing, shared component delivery across the teams (advanced version control) , automated delivery rollback based on advanced service monitoring.
For all this to work you need to use Github branching model, continuous deployment and “extended” cross-team scrum process.
Git vs Github branching model
Git branching model (left) brings complexity and requires human moderation for release, versioning and hotfixes.
Github branching model ( right ) simplifies versioning, feature toggling, automated testing and release management – but your “master branch is potentially releasable”
“Potentially releasable” master branch is preferable than the branch chaos you may have in case for example like this – 40 microservices * ( master + dev + hot fix + UAT release branches) = 160 branches to manage.
Automated Quality Gates
Development environments – one for each developer / engineer – where developers have full access, so that they can develop, test and change feature toggles states.
Often in those environments there is only one microservice (not all the services) and development is done against message communication contracts or test-driven (against integration tests).
Integration environment – may be only one – this is the first shared environment (cloning of production environment) where all microservices work together.
There developers have limited access and they can only monitor logs and read storage data.
This environment is operating a blank databases (or other storages) that are seeded on each deployment.
All the tests runned here are working only with seeded data
Test environment – may be only one – this is the end-to-end test environment designed for the QA to build full-scale start-to-end workflow UI tests.
UAT or Staging environment – is a standard UAT environment that is working with production data
Production environment – no need to describe it 🙂
The standard Software development cycle (above) will now contain several more steps.
The Requirements phase shall be extended with “cross-team requirements segregation” that will include feature toggling design and message contracting.
The Planning phase shall contain “cross-team knowledge transfer“
The Development phase shall contain “Shared component release/adoption phase” and “Test data exchange”
Also Testing shall be extended with “feature toggle on/off” tests
Tip 3 Resource insolation
Tip 4 Make it asynchronous
Tip 5 Strong versioning
Tip 6 Automated testing
and “simple” tricks