Application Lifecycle Management for Microservices – Tips and Tricks – part 1

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.

Distributed systems

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…

Tip 1
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:
  • Development
  • Testing
  • Deployment
• Service Communication
  • Business Features availability
• Feature toggles management
• Technologies (best per service)
• CI\CD

What shall your documentation look like?

• Constructive
  • Highlight issues
  • Drive architectural decisions
  • Establish a framework
• Reasoned
  • strongly motivated by business drivers, goals, and other principles
• Well articulated
  • are not open to misinterpretation (accidental or willful)
• Understandable
• Robust
• Complete
• Consistent
• Stable

Tip 2
Continuous Deployment

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 🙂

Development cycle

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

… next

Tip 3 Resource insolation

Tip 4 Make it asynchronous

Tip 5 Strong versioning

Tip 6 Automated testing

and “simple” tricks