Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopting the distributed architecture #47

Open
SleeperSmith opened this issue Feb 12, 2020 · 1 comment
Open

Adopting the distributed architecture #47

SleeperSmith opened this issue Feb 12, 2020 · 1 comment

Comments

@SleeperSmith
Copy link

SleeperSmith commented Feb 12, 2020

Businesses nowadays have begun to understand the importance of "Service Oriented Architecture(TM)" and "Micro Services(TM)". Netflix does micro services, so clearly enterprise nowadays must have it to be profitable.

There are a few key attributes to "distributed architecture"

  • All services must call into all other services. This is what's called a "service mesh"
  • Any one service going down would cause all other depending services to go down. Thus it is critically important to ensure the failure of health check immediately triggers a company wide email alert.
  • Because the database is shared across multiple services (clearly), the data access code for the database should be packaged as a library and referenced in all services.
  • Service endpoints must be versioned and put into /v1 /v2 /v3 paths. This automatically guarantees backward compatibility and thus the API can be modified at will.
  • Since it's called "micro" services. Most services must not have more than 5 classes and no more than 10 lines of code per class. However enterprise patterns still requires a lot of lines of code (factories, managers, but to name a few) so a few selected, ideally 1, central service(s) will have all the rest that's required. It is not uncommon for this one central service to have 10s if not 100s of thousands of lines of code. This is what's required to ensure services are "micro". Special points for services with less than 10 lines of code. The bleeding edge paradigm of nano services is just 'round the corner.

This is a complex paradigm and I have barely scratched the surface, but I'm sure everyone understand no enterprise can be as disruptive and innovative as FANNG without micro services / distributed architecture.

@joaomilho
Copy link
Owner

That's a GREAT idea. I'm not sure about the need for versioning in the APIs, given Enterprise™ is non-deterministic – and therefore ready for whatever laypeople understand quantum computing to be. Also, I wanna understand how is this compatible with CORBA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants