Are Microservices … for real?

Design Principles

Designing microservices requires a deep understanding of the product and its domain. Joe Zack and Michael Outlaw discuss the pitfalls of shared databases, emphasizing the need for each service to have its own data store to avoid tight coupling and deployment issues. They highlight the importance of fronting microservices with APIs to maintain statelessness and flexibility in storage solutions 1 2.

You should never share a database. The reason is, you accidentally start doing tight coupling.

--- Joe Zack

This approach allows for independent deployments and easier management of changes within the system.

   

Service Communication

Effective communication between microservices is crucial for maintaining a cohesive system. Joe and Michael explore the Single Responsibility Principle, where each service is responsible for one specific function, such as billing or shipping 3. They also discuss the importance of using queues to decouple services and ensure that one system's failure does not bring down the entire application 4.

Follow the single responsibility principle. That service should be responsible for one and only one thing.

--- Joe Zack

This method helps in scaling and maintaining the system efficiently.

   

Scaling Solutions

Scaling microservices effectively involves ensuring statelessness and using serverless functions. Joe and Michael discuss how serverless functions can be used to create microservices that are reactive and scalable without the need for extensive infrastructure 5. They also emphasize the importance of keeping services stateless to avoid tight coupling and maintain scalability 6.

By keeping things stateless, you just kind of help things remain atomic and also means that they're independently scalable.

--- Joe Zack

This approach allows for more flexible and efficient scaling of microservices.