Process pitfalls to avoid when developing microservices in 2021
Over the last 20 years I have had the opportunity to work with so many folks in so many different environments I wanted to share some of what I have observed successful teams do in developing successful products and consequently supporting them over the life cycle of the software. Please note that all of these suggestions are generalized, and not specific to any technology. Also please note that the more complex the application the more meetings involved for the development teams and leads. The below is a bare minimum.
(Basic) Things to take into consideration when developing microservices:
1. Choose a methodology for your development to manage work items, features, bugs and sprints. Scrum, Agile, Waterfall to name a few.
2. Leverage the methodology chosen to create daily 30-minute-long virtual standup meetings for each of the application teams doing development. These meetings should include the product owner, product manager and technical dev and dev/ops folks. Current work items discussed, critical updates discussed, patch/security issues discussed.
3. Create one weekly meeting with all dev leads and technical leads to discuss blocking issues across teams. Use this meeting to close out previous weeks work items and prepare for upcoming sprint.
4. Cross train within application development teams with regards to technical responsibilities/expertise e.g., Primary/secondary for containers. Primary/secondary for DB.
5. Create reporting and visibility into sprint buckets for management folks and dev leads to reference and access that provides an accurate picture of development teams progress on sprints. ‘Encourage’ development team members to keep theirs tasking up to date.
6. Provide source control/version control and corresponding process for check-in/checkout, code review and source code validation automation.
7. Determine how versioning process will work across microservices, where dependencies exist between services and how to handle different code versions interop internally between microservices.
8. Provide pre-production environments where necessary, with deployment gates and validation checks used in any automation used to push the software through a release pipeline.
9. Develop a centralized logging and tracing method across microservices. Implement verbosity from Ver 1. Provide development team and QA members access to tools that can be used to review any issues with the application across the pre-production and production environments.
10. Leverage automation on check-in to source control to validate any code updates prior to those updates being pushed to the main branch.
11. Unit test wherever possible. Aim for 100% coverage and be satisfied with 95% for more complex applications.
12. Leverage build automation to validate test cases at each stage of the release process, e.g. pre-production, staging, production. Provide automated reporting to development teams on pass/fail.
13. Create a support process to handle escalations from partners or external entities. Define how escalations will be handled, set expectations for engagement/response time of technical resources and create SLA expectations for incident response. Define any problem management follow up steps that need to occur. Scale as needed.
14. Define change and release management process and communications expectations for changes/releases. Align change process to any business requirements that might limit change windows or require lockdowns from changes occurring on the site.
Once we have all of these items in place, and everyone following the correct routines we can actually get down to the business of software development.
Please let me know if you found this helpful and would like to see future posts expanding on the subject. Feedback is always welcome.