Any organization, practice or product is driven by four key pillars. These pillars are Process, People, Platform and Practice. The same hold true for Microservices as well.
In the upcoming blog series, we will look at what each of the pillar means to a Microservices based application and in the current blog, we shall focus on the first pillar which is ‘Process’.
Process
In a high level, Agile is the overarching methodology that fits Microservices well. There are a few key elements that are mandatory for a Microservices architecture which is not required for a Monolithic application. These elements are
- At the beginning of Microservices development, at least 3-4 sprints need to be dedicated to define their Software architecture, Infrastructure architecture, DevOps architecture, Standard guidelines and practices for Microservices. This is very important to avoid massive rework and failures later. The general naming convention followed for these sprints is called “Foundation sprints”
- Once development has started, multiple parallel scrum teams need to run the Microservices that are in development respectively. A scrum of scrums needs to run, aligning the different delivery goals of the independent Microservices to an overall goal of the product release.
- Testing Strategy needs to be different for Microservices application. Microservices should not rely on manual testing. Since the Microservices are smaller in scope, the time required for this automation testing is generally small and is simple.
Usually, Automation testing is the major factor in driving a faster ‘release to market’. A Microservices success without Automation Testing would not be possible.
The types of automated tests each Microservice should develop are:
- Unit Tests
- API Tests
- Event Driven Integration tests
- Saga Automation tests
- Contract Tests
- End to End Tests
Again, like any other application, these tests follow a pyramid with the highest being number of unit test cases to the lowest being End to End tests.
- A standardized DevOps process needs to be defined for all the Microservices . IaC and pipeline as a code needs to be adhered. It is highly anti productive to define this process for each Microservice. IaC and Pipeline code library needs to be made available from which each of the Microservices can be chose from. If really needed, Microservices can even alter it for their need. This needs to be specifically called out as a task during scrum planning.
- Dependency management needs to be highlighted explicitly during planning and developers should have the habit of tracking where their Microservices are used and thus ensure that their versioning strategy does not affect the dependents. It is highly recommended to use a specialized Microservice dependency tracking system to do this.
- Release process needs to be automated from end to end for Microservices. The stages for the release pipeline and the approval authorities needs to be set in place from the very beginning.
- Periodic audits needs to be conducted to ensure that Microservices are adhering to the prescribed guidelines.
We will further look at the other 3 pillars in the upcoming blogs. Stay tune for more!
- Predicting ROIs to a Microservices Migration – Sowing Seeds to Success - May 22, 2019
- The 4 Pillars of Microservices: Process – The Fulcrum of Strength (Part 1) - May 22, 2019
- Saga – The key differentiator of Microservices - April 26, 2019
Comments