For microservices: How does your organization decide what “should” be a service? Looking for tips on how to tell when a function needs to be a separate service vs. when to roll it into another existing service.
Chair and Professor, Startup CTO in Education, 5,001 - 10,000 employees
We do not have this type of service. Sr. Director of Engineering in Software, 51 - 200 employees
A microservice is essentially a bunch of APIs or functions that are related and can work independently without the need of interacting with many other microservices. We have defined a microservice as set of similar functions that involve processing and can be triggered by their API interfaces. Any platform or solution can be broken into different set of common functions like logging, monitoring, users management, IAM, reports, auditing etc and main business logic functions. They can be clubbed together and can be developed in form of different microservices. There can certain adapters functions needed during different third-party-integrations, they can also be developed as separate microservice as well.
Director of Engineering in Healthcare and Biotech, 501 - 1,000 employees
We do not have this service but would evaluate keeping it separate or integrated based on the extent to which it would better enhance or boost business.Chief Techical Officer in Software, 11 - 50 employees
Generally when the functionality that it provides is completely standalone and nothing to do with anything else. Then we consider it. It is very rare that we find such a situation but we have found and implemented a few this way.Co-founder & CTO in Finance (non-banking), 51 - 200 employees
When it comes to deciding what should be a microservice in our organization, we follow a set of guidelines and considerations to determine the appropriate granularity. Here are some tips that can help in discerning when a function should be a separate service versus being rolled into an existing one:Single Responsibility Principle: We adhere to the principle of single responsibility, aiming to ensure that each microservice has a clear and distinct purpose. If a function or feature can be isolated and independently managed, it is a strong indication that it should be a separate service. This promotes modularity and maintainability.
Domain-Driven Design (DDD): We analyze the domain model and identify distinct bounded contexts within our system. Functions that align with different bounded contexts often warrant separate microservices. This allows teams to have autonomy and focus on their specific domain, promoting better organization and scalability.
Scalability and Performance: Performance requirements and scalability considerations play a significant role in determining service boundaries. If a function is expected to have different scalability needs, resource requirements, or performance characteristics compared to the existing service, it may be more appropriate to build it as a separate service.
Independent Deployment and Release Cycles: We consider the need for independent deployment and release cycles when evaluating whether a function should be a separate service. If the function requires frequent updates, has a different release cadence, or requires isolated testing and validation, it might be a strong candidate for a separate microservice.
Team Autonomy and Ownership: We take into account the organizational structure and team ownership. If a specific team or group is responsible for a particular function or feature, it may make sense to have it as a separate service. This fosters ownership, accountability, and streamlined decision-making for that specific area.
Reusability and Modularity: We assess the potential for reusability and modularity. If a function has the potential to be used by multiple services or can be a building block for future functionalities, it might be worth considering as a separate microservice. This promotes code reuse and reduces duplication across services.
Communication and Collaboration Overhead: We evaluate the communication and collaboration overhead associated with a specific function. If the function requires extensive communication or coordination with other services, it might indicate that it should be part of an existing service to minimize inter-service communication complexity.
Operational Considerations: We consider operational aspects such as monitoring, logging, and fault isolation. If a function requires different operational considerations or has distinct infrastructure needs (e.g., specific security requirements or resource constraints), it may be better suited as a separate microservice.
Ultimately, the decision on what should be a microservice requires careful analysis of the specific context, taking into account factors such as responsibility, scalability, domain boundaries, team ownership, and operational considerations. By applying these tips and considering the unique requirements of our organization, we aim to determine the optimal granularity for microservices within our system.
CEO in Services (non-Government), 1,001 - 5,000 employees
More two things must have to consider for principles when analyzing/designing services at the microservice level: N+1 design, Design for Rollback (MSA is complex during solving huge flows, so our Solution Architect should think and design to roll back the micro-service itself in the worse cases).
Director of Engineering in Software, 10,001+ employees
if we have a job/task that is similar for multiple use cases and need to be executed multiple times then that's the best candidate for microservices. CTO in Education, 51 - 200 employees
Microservices are often aligned with bounded contexts within a domain-driven design (DDD) approach. Analyzing the different domains and subdomains within your business can help identify natural boundaries for microservices. Each microservice should represent a specific business capability or a cohesive set of functionalities within a well-defined domain.Senior Vice President, Engineering in Software, 1,001 - 5,000 employees
We follow the single responsibility principle. When the requirements are given to us we take time to understand the domain first and then segregate the various aspects of the application which deal with a single set of responsibilities for ex a service that is purely responsible for handling all the notifications being sent from the application could be developed in silos. At times our engineers tend to divert from this and end up creating 'NANO'-services and we need to guide them and bring them back to the micro level. We need to keep in mind the more services we create the more chatty the end system will end up being and hence more maintenance overhead in managing the interactions.
Manager in Manufacturing, 10,001+ employees
it should provide a value proposition that is not available from other providers.Content you might like
JavaScript and Node JS36%
Python61%
PHP3%
161 PARTICIPANTS