What is microservices ?
It is an architectural development style that allows building an application as a collection of small autonomous services developed for a business domain.
It is an architectural development style that allows building an application as a collection of small autonomous services developed for a business domain.
Key principles of microservices
- Autonomy
you have to build your microservices in an autonomous way that is highly cohesive which that its' internal component is strongly related to each other, and also loose coupled which that it not depend on any other service and can be independently deployable.
- Resilience
Microservices architecture complexing developing process to gain ease of deployment so a lot of threats surrounding your microservices like network interruption or high load on specific service and so on, so dealing with these challenges is mandated to stabilize your application like putting load balancers or caching responses to use in case of failures.
- Transparency
Microservices components have to be transparent through system monitoring and logs aggregation so you can monitor your system health, notified when any failure happens or searching and investigating logs to find failure reasons.
- Automation
Manual deployment or testing can be painful in case of microservices as you may have dozen of services to deal with, so building deployment pipelines and enable automation testing is mandatory to avoid hassle derived from microservices architecture.
- Alignment
Building technical and business domain knowledge for development team is mandated, as you will split work among of small teams so having a strong base for all teams about code standards and business goals will boost your development and save you a lot of effort.
When microservices is good choice ?
Mainly microservices has benefits when your application will grow in multiple dimensions, multiple deployments , business requirements grow , organization grows and uncertain domain complexity.
- Multiple deployments
In case you will have a lot of multiple environments you need to ship your system into, microservices will helps you as it contains small , stand alone and single responsibility services easy to ship from one location to another.
- Business requirements grow
As your business requirements grow and you are stick to time to market, microservices will fit there as you can start and go live with small services and features with catching the new requirements without affecting deployed ones as you add new services not modifying exists one.
- Organization grows
When your organization grows and your engineering team grow as well microservices will be good at that which you can distribute services among small teams each team is responsible for small service , and onboarding for new members will not hard as each team focusing on small portion of business only so any member can participate easily.
- Uncertain domain complexity
When you don't have enough knowledge about your domain and its' complexity, it's good practice to go with small steps and keep your choices open as much as possible and this is one benefit of microservices as each component is small and can be replaceable.
Microservices components
- platform
The platform is the infrastructure of your microservices architecture and tools that boost development and deployment process like deployment pipelines (as Jenkins) , orchestration tool (as Kubernetes) , logs aggregation and search facilities , mentoring system, load balancers and service discovery and registry tool.
lacking any tool from the platform will harm the development process, without strong deployment pipelines you will lose main feature of microservice and will suffer from hassle manual deployments and bugs (strong pipelines have to include multiple test stages), also without logs aggregation facility you can not track request journey among services, and monitoring system will proactively notify you about any service failure.
Also one important thing you should consider as platform component is building standards for whole team, standards for writing logs, for building contracts between services and team knowledge share as you could imagine what problems you could face if every team use its' standards while development process.
- Services
services is the tier thar contains application business logic and interact with each other to achieve application goals and organization values, determining the scope and responsibility of each service and set the context of each one is challenging task and requires a strong knowledge of domain problem, also the way of communication between services is vital aspect you should to consider and choose wisely.
services are divided to serve either
business capability
business capability is one of organization/application main service or goal like place an order or submit new post or tweet.
Or, technical capability
technical capability is a shared component or service that serve business capability like send notifications.
- Boundary
The boundary is the functionality or value that application or organization offers like place an order on e-commerce application or uploading video in streaming application these functionalities requires interaction of multiple services to achieve the goal or value.
- Client
the client is user interface that user deal with to interact and fire request to your system and it's good practice to hide and abstract your system from the client by using something like gateway pattern as the client should know only about gateway and gateway has responsibility to froward the request to right service.
If you have multiple clients like mobile application and web application and each of them has different needs and special handling it's also a common practice to build a gateway for each one to avoid adding more responsibilities to one gateway and this is known by BFF (back-end for front-end).
Also notice that gateway can be a single point of failure so you have to deal with this in proper way.
Microservices challenging points
- Communication
Communication between microservices is essential to achieve business capability, and almost the communication is done over network , the way of communication between these services may harms your user experience if you used a lot of synchronies calls (like HTTP) you will build a blocking and tight couple communication and using a lot of asynchronies calls (like Message broker) you will achieve non-blocking and loose couple communication but your internal requests may fail and user didn't know about that, so making balance between these two ways is somehow challenging.
- Adding new feature
Microservices architecture allows you to extend your application capabilities easily, but when you start think about new feature you will have two choices either extend an existing service and put new feature there but you may find yourself attach much responsibilities to one service so it may be hard to maintain in future, or you can build new service to serve this feature but adding new service means more network calls and tight couple between services, so you should take this into your consideration also.
- Identifying your services context
In microservices architecture each service should be responsible for single and small capability, identifying this context is challengeable you should consider either this is much responsibility for service or we built a lot of services and the design and feature is now complex.
- Querying and managing transactions
Instead having one application that have your entire business logic you have now multiple microservices each one has its' data store so managing DB transactions in this case is challenging you can use 2PC (two phase commit) or Saga pattern but each one has its' pros and cons, aggregating data also is painful what you were achieving by JOINs now you have to make network calls to aggregate data.
IF YOU LIKED THE POST, THEN YOU CAN BUY ME A COFFEE, THANKS IN ADVANCE.
Top comments (0)