Skip to main content

Microservices

How might DePIN tech with zk Proofs impact the need to have (closed) microservice architectures?

Principles​

A microservice is a small, loosely coupled, distributed service. It is part of a broader microservices architecture, comprising a set of loosely coupled microservices that operate together to solve a common goal. A collection of microservices can be regarded as a system.

tip

Software architecture matches dynamics of the team that created it - Conway's Law

Benefits​

  • Focused domain expertise
  • Pick the right tool for the job

Challenges​

It is a greater challenge to form a team that works well together than to orchestrate microservices?

  • Deployment strategy for optimal flexibility, cost and efficiency
  • Resilience to failure, meshing
  • Focus on solving domain problems not building infrastructure
  • Leverage serverless platforms with simple code to cloud pipelines
  • Combine multiple languages and frameworks to build a single solution

Education​

Eventual Consistency​

Each service owns it's own database, which requires some data duplication which you don't have in a single normalised database. The benefit of data replication is that services are atomic and easier to scale.

tip

Managing data between services is the hardest challenge in creating an MSA solution

Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value.

  • Causal consistency
  • Read-your-writes consistency
  • Session consistency
  • Monotonic read consistency
  • Monotonic write consistency
tip

Data storage is cheap compared to delivering actionable insights

Deployment​

  • High Availability
  • Scalability
  • Redundancy

Security​

Defence in depth, OWASP top 10

  • Encryption
  • Network
  • Monitoring
  • Penetration testing

Failures​

Why you shouldn't use microservices

DePIN​

DePIN architectures present an intriguing opportunity to enhance and scale microservices deployments in certain contexts. As the DePIN ecosystem matures, we may see more examples of DePIN and microservices being used together to build decentralized, scalable applications.

DePIN enables decentralized computing and computer networks, which aligns with the distributed nature of microservices. The decentralized model of DePIN could provide an alternative infrastructure for deploying and orchestrating microservices.

Completely replacing microservices with DePIN may not be feasible or desirable in all scenarios:

Microservices are an architectural style focused on modularity, loose coupling, and independent deployability of services. While DePIN can potentially host microservices, it doesn't inherently enforce microservices principles and best practices.

Some microservices may have specific hosting, scaling, or compliance requirements that are better suited for traditional cloud platforms rather than a decentralized network.

Potential Benefits​

Despite the caveats, integrating DePIN with microservices could offer some compelling advantages:

  • [Standardization] of common business protocols.
  • Decentralization and distributed ownership of the infrastructure, reducing reliance on centralized cloud providers.
  • Tokenized incentives for node operators to contribute resources, enabling a scalable and resilient network.
  • Ability to run microservices closer to end-users using edge nodes, improving latency and performance.
  • Potential cost savings compared to centralized cloud hosting, especially for large-scale deployments.

Examples​

The Beamable platform is integrating DePIN with their existing microservices architecture. Their "Container nodes" allow running flexible microservices, including custom game logic and off-the-shelf modules.

Tech Stacks​

See tech decisions process.

DotNet Microservices​

Legendary effort!

DotNet Tech Stack

Development Environment​

Case Study DoorDash​

Review of failures at DoorDash.

DoorDash Microservices

Perspective​

Feedback from a Principle Engineer at DoorDash.

The principle engineer argues that microservices should be judiciously applied to solve team scaling issues, but they incur significant complexity costs. The industry needs better tools and frameworks that avoid the pitfalls of microservices while enabling fast development at scale. Careful thought is required to adopt the right architecture for the context.

Benefits​

  • The main reason companies adopt microservices is to enable a large engineering team to move faster without stepping on each other during deployments.
  • With a monolith, if you have 100 developers, they will start conflicting with each other's deployments and changes.
  • Microservices allow teams to deploy independently and own their services.
  • Door Dash had to adopt microservices because their monolith was grinding to a halt and couldn't be fixed fast enough to keep up with growth.

Technical Debt​

  • Microservices can be considered a form of technical debt. They help teams move faster at first by breaking things out, but incur a cost over time.
  • With microservices, you end up with a complex call graph of services that all need to be up. Making changes that span services becomes expensive, requiring many deployments.
  • Most companies end up with a "distributed monolith" where all the services have to be running, contrary to the ideal of loose coupling.

Sociotechnical Problems​

  • Microservices tend to cause sociotechnical problems - issues at the intersection of people and software systems.
  • With hundreds of services, it becomes very difficult to get teams to upgrade shared dependencies, clean up old code, or make coordinated changes.
  • The average fanout for a request can become huge (1000+ RPC calls) as each service refuses to share data models and constantly retrieves things like user profiles.

Future Innovation​

  • The industry needs to develop alternative abstractions and frameworks that provide a middle ground between monoliths and microservices.
  • Service Weaver from Google is an interesting step in this direction, allowing a single program to be split across services. But more work is needed.

Diagram