Microservices Paradise
Take a moment and ask yourself some questions:
- have you experienced the problem of working with microservices hell?
- have you experienced the pleasure of working with microservices paradise?
Take a moment and ask yourself some questions:
- do you believe that it's possible to achieve?
- are there practices and guidelines are you going to follow?
- what practices and guidelines are you going to follow?
#1 Design strict rules
What are layers in your application?
- Frontend Services (BFF - Backend For Frontend)
- Flow Services
- Stateful Services
- Gateway Services.
It's very important that services go with flow of calls in parallel; Only TOP-DOWN:
No DOWN-TOP interactions!
We're thinking about how services are executing their functions; and in this terms we'resaying the strict rule: No CROSS-FUNCTIONAL interactions.Think about API call where you also have to trigger a push notification / or message / oremail - it will be invoked from the API level service as well;and you want more examples - like real life examples - please, come to me after this talk and I can share with you or we can do a Drawing design session!
When we're thinking of our services as separate from FRONTEND PUBLIC API Servicesand GATEWAY PUBLIC API Services - there should be no CROSS-FUNCTIONALinteractions as well!
Note #1: Top-Down Cross-communications are allowed
Note #2: Skipping levels is allowed
#2 Following the good naming
Take a moment and ask yourself some questions:
- What does good naming mean to you?
- How many big business domains do you have?
The first rule is to define the big domains your organisation is running.If you don't know where the domain is set up, or you develop plugins and tools settled acrossmany businesses - start with infrastructure.
Bad naming: trust me, those services exist and are running in production and even doing their job!
Example of domains:
- Retail
- Business
- Trading
- Infrastructure
Example of package names:
- 'retail-direct-deposit'
- 'retail-card-payments'
Example of class names:
- RetailDirectDepositResource
- RetailDirectDepositRepository
Example of BAD naming:
- 🪐 Saturn
- ✨ Andromeda
- 🐘 Elephant
- 🍨 Vanilla
- 🪵 Cinammon
- 🌸 Blossom
Those names are not jokes - they exist on the moment of writing this blogpost and running inproduction by even doing a great job! However, it's really hard to understand who isresponsible for them and WHAT ON THE EARTH they're doing!
#3 System Design Review Expert Committee
Take a moment and ask yourself some questions:
Do you have the process of System Design, RFC, ADRs in your organisation?How many people are involved in this process?
A System Design Review Experts Committee is typically a group of highly experiencedprofessionals and subject matter experts responsible for evaluating and providing feedbackon the design, architecture, and development of a system. Their goal is to ensure that thesystem meets its intended requirements, adheres to best practices, and is technically sound,scalable, secure, and maintainable.
Here are key attributes of such a committee:
-
Diverse Expertise:
- The committee usually comprises experts from different domains relevant to
the system being designed. This could include:
- Software Architects: Experts who assess the system's architecture.
- Infrastructure Specialists: Evaluators of cloud, networking, and hardware infrastructure.
- Security Experts: Professionals who focus on cybersecurity aspects.
- Quality Assurance (QA) Experts: Ensuring the system is testable and meets quality standards.
- Domain-Specific Experts: Specialists in the industry or area where the system will be deployed (e.g., healthcare, finance).
- The committee usually comprises experts from different domains relevant to
the system being designed. This could include:
-
Objective Evaluation:
- The committee offers an unbiased, critical assessment of the system's design, helping to identify risks, weaknesses, or gaps.
- They ensure the design adheres to industry standards, best practices, and regulatory requirements (if applicable).
-
Collaboration and Communication:
- The committee works closely with the system's design and development teams, facilitating open discussions to improve the design.
- They provide detailed feedback and suggestions, helping to refine the system and mitigate risks early on.
-
Decision-Making Role:
- The committee often has authority to approve or reject designs based on predefined criteria. They may recommend changes before further development proceeds.
- They ensure alignment with project goals, budget, timelines, and technical feasibility.
-
Documentation and Reporting:
- They document their findings and provide reports that outline the system’s strengths, weaknesses, and any necessary revisions.
#4 System Design Review Expert Committee
Take a moment and ask yourself some questions:
Do you have the process of the Risk Assessment on the system change?
How many people are involved in this process?
What metrics are you using to perform the Risk Assessment?
Examples of materiality metrics:
- How many users are affected by this change?
- How many public APIs are involved?
- Is the change required by regulators?
Examples of complexity metrics:
- How long will it take to implement?
- How many teams are involved?
- Has it ever been done before within the company?
Examples of the final rate:
- Tier / Severity
- Levels 0-1-2-3
- 0/1 - changes require System Design Review
- 2/3 - smaller changes; don't require System Design Review
#5 Do the system design review
- Create an automated process
- Prepare templates
- Level 2-3 - review inside department
- Level 0-1 - review on the level of company
Summary
👉 Design strict rules
👉 Following the good naming
👉 Introduce the risk assessment
👉 Establish the expert's committee
👉 Do System Design Reviews
… and enjoy your journey!
If you have any questions please feel free to connect with me through LinkedIn
