deft/notes/dynamic_service_architecture_for_big_software.org

Dynamic Service Architecture for big Software

• Introduction
• Plan
  • Introduction
  • Evolution of Code Architecture
  • Components / Services

tags

blog

source

Introduction

???

Plan attempt

Plan

Introduction

Talk about composability in real-word application. How we can think of it in a static way vs a dynamic way. Why part of dynamicity is mandatory. How could this be achieved? Maybe talk about meta-programming with yesod for example.

Evolution of Code Architecture

Why do we need to provide code architecture patterns?

Try and errors, and learning from them. By doing so we discovered a few important architecture design patterns.

1. spaghetti code. Mix everything, everything is coupled. If you change one line of code this will impact other places. Only survival strategy, copy/paste, become a master of massive search and replace.
2. Externalize state. You want to make it a lot easier to scale. So you keep your business logic data in an external DB hopefully choosing one that could scale. So you could easily spawn a new node and the charge will be distributed. This is basic Ops hygiene that gave birth to 12 factor application methodology.
3. MVC. Once you took care of externalizing the state, you then discover that you don't want to mix the business logic with its presentation. So you add a view layer. One very nice property of MVC is that it can be organized and even better composed in components. Each component will provide the three aspects, Model View and Controller. And you can create a framework that will compose them.
4. Last step but not the least, Controllers is where you take care of your business logic. And some will share common usage, you naturally ends up with building the same common components or libraries. So now, you will start to have a lot of components that will not have views and only Controller and optionally a Model saved in DB. Worse, every of these component have a lifecycle. They start and initialize their internal state, then they live, and finally they could be removed and be deleted. So you will end up with a complex mess of internal state that is not business logic state, but only technical local state. To solve this problem you have different architectures proposed but in the functional world this could be components. So you split your logic into different services. Each of them will take care of their own technical internal state.

How does this work?

Components / Services

Service Lifecycle. Every service pass through different phases.

1. init
2. start
3. live
4. stop

There is a distinction between init and start which could be useful for some technical reason. Every component also declare its dependency over other components. Every dependency can be either mandatory or optional.

On top of this every component also exposes a public API.

But that's not all. Every component should be organized into:

• schemas / data-structure
• service declaration
• service implementation
• optional associated web service declaration / implementation
• different default configs per option. LOCAL, DEV, CI, TEST, PROD

• tests:

  • implementation (short)
  • service (big)
  • web service
  • default test configs TEST_SELF_CONTAINED, TEST_INTEGRATION

But that's not all. For modern application you need:

1. Structured traces/logs
2. Very good state layer
3. Centralized business logic