Summary of : https://medium.com/free-code-camp/microservices-from-idea-to-starting-line-ae5317a6ff02
- Cohesion and coupling is traditionally the technical debt grasping onto our feet, slowing us down.
- Complexity comes from low cohesion and high coupling. Microservices provides the structure to keep that at bay.
- Benefits can include horizontal scalability, testability, reliability, observability, replaceability, and language independence.
- The downside for microservices is that to achieve these benefits, you must provide an underlying infrastructure which supports them. Without that support, you can easily find yourself with an unreliable and opaque system — or you find yourself reinventing the reliability wheel in every single service.
- The overhead will not be insignificant. It will take time and money to do microservices well.
- The macro-architecture is one part provided infrastructure and one part policy requirements for all microservices.
- You could simply provide acceptance criteria to which a microservice must adhere, but provide no implemented library or service to help fulfill the requirement.
- Continuous Integartion: Each check-in is then verified by an automated build, allowing teams to detect problems early.
- Continuous Delivery: A straightforward and repeatable deployment process is important for continuous delivery.
- Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.
- Load monitoring and instance control management should also be considered and facilitated by this portion of the macro-architecture.
- A logging service for centralized logging. This can be the Elastic Stack,
- Definition of trace IDs to enable the location of all logs across all microservices handling a single external request.
- Base formatting requirements for server, service, instance, timestamp and trace IDs.
- The volume of messages, failures, successes, retries, and drops. The latency of requests. The ratio of received messages to sent messages. Status of circuit breakers.
- The macro-architecture of your microservices environment must define how this is done — even if the first iteration is /etc/services.yaml deployed and synchronized to all hosts.
- Using Google Protocol Buffers over raw TCP could be just as available as using JSON RPC over HTTPS
- A microservices infrastructure which wants to permit the use of messaging as a communication device should consider providing an operations-managed messaging bus.
- Providing the infrastructure for your messaging layer also enables you to provide message routing to your services
- Resiliency means remaining stable even in the face of errors. Retries, deadlines, default behaviors, caching behaviors, and queuing are a few of the ways microservices provide resiliency.
- One or more data storage services including an SQL based relational database and a NoSQL storage system. A microservice should utilize unique credentials with limited access to a schema restricted to only that microservice’s data.
- If you allow the microservices to bring their own persistence, you should have strict policy requirements for backups and disaster recovery.
Based on this article: https://medium.com/tech-tajawal/microservice-authentication-and-authorization-solutions-e0e5e74b248a there are diffrent ways of doing it:
- Distributed Session Management: Sticky session, Session replication, Centralized session storage (but you need to limit access for each microservice).
- Client Token like JWT where the information is stored in the client side
- Single sign-on: This can result in a lot of very trivial network traffic, repeated work, and it may cause single point of failure.
- Client Token with API Gateway: This scenario means that all requests go through the API gateway, effectively hiding the microservices. On request, the API gateway translates the original user token into an opaque token.
- Third-party application access
- API Token: The advantage of using the API Token instead of using the username/password directly to access the API is to reduce the risk of exposing the user’s password.
- OAuth: With OAuth, when a third-party application accesses a service, the application prompts the user to authorize a third-party application to use the corresponding access authority and generates a token for access according to the user’s permissions.
- Mutual Authentication: Through mutual SSL, mutual authentication between microservices can be achieved, and data transmission between microservices can be encrypted through TLS. A certificate needs to be generated for each microservice, and the microservices are authenticated with each other’s certificates. In the microservice operating environment, there may be a large number of microservice instances, and the microservice instances often change dynamically, such as adding service instances as the level expands. In this case, creating and distributing certificates for each service becomes very difficult. We can create a private certificate center (Internal PKI/CA) to provide certificate management for various microservices such as issuing, revoking, and updating.
Provide code which developers can bake into their systems to perform the desired functionality. An example here would be a shared library that can be used to perform service location and load balancing. This restricts the ability for teams to choose their own language, but the benefit of not creating this infrastructure multiple times can outweigh that cost.
https://www.youtube.com/watch?v=sSm2dRarhPo
- X Horizantal: Duplicating similar things
- Y Functional Decomposition: Scale by splitting different things
- Z Data Partitioning: Scale by splitting similar things
API Gateway is like a facade that exposes the microservices
- Complexity of developing a distributed system
- Interprocess communication
- Handle partial failure (if one microservice was slow)
- Handle transactions that spans on multiple databases. Can be tricky for businesses like banking.
- Testing is complex as you need to test the microserivce and its dependencies.
- Deployment is complex when dealing with distributed systems.
- Managing development and deployment of new features that spans over multiple microservices.
- Database can be accessible for all microservices with limited access. Each microservice might have the abbility to write on one table. ACID is maintained
CAP Theorem is a concept that a distributed database system can only have 2 of the 3: Consistency, Availability and Partition Tolerance.