Microservices

By making our micro services stateless we make them more testable and scaleable, a stateless service must take some input data and return an output, being as it doesn't store any state. This is easier to test as we can essentially write the data that we pass in and check what it passes back for each test case.

Where does my state go?
Most applications will likely still need to have quite a large amount of data that is stored in a storage mechanism (i.e. document database or sql), but if we can move these interactions to the start and end of our service chains then it should enable us to still have as much functionality as possible in easily testable services.

- Load data from store (this service is simple as all it does is load)
- send to service to do work (this service is easily tested)
- Save any data required (again should be simple)

Micro services enable us to work in new ways

• When the application is split up smaller different services can take advantage of different programming languages/frameworks and storage mechanisms.
• For larger projects teams can work on separate services and release individually of each other.
• Because we are using multiple pieces to make up our application we can run them on different hardware and increase the amounts we run of individual services to scale out.