The Stateful Microservice

I did a quick search for the term and did not find anything concrete, so I thought I might as well publicly document my thoughts.

On Stateless Microservices

This post discusses the stateless microservice design pattern; it is meant as support material for other posts of mine that discuss microservices, mainly michael.gr - The Stateful Microservice.

Is statelessness a requirement for a microservice?

In another post (see michael.gr - So, what is a Microservice, anyway?) I examine what a microservice really is, and I come to the conclusion that from a purely technical standpoint, a working definition could be as simple as this:

A microservice is a scalable and resilient module.

Even if you disagree with the terseness of this definition, and you regard microservices as necessarily more than that, I hope you will at least agree that it is precisely scalability and resilience that statelessness in microservices aims to address, so this definition serves its purpose at least in the context of this series of posts.

There are many who will try to convince you that in order to build a scalable and resilient system, you need statelessness; so much so, that microservices have almost come to be regarded as synonymous with statelessness. This post examines whether this is that in fact so, and what is the cost of doing things this way.

So, what is a Microservice, anyway?

This article attempts to shed some light on what a microservice really is; it is meant as support material for other posts of mine that discuss microservices, mainly michael.gr - The Stateful Microservice.

What is a microservice?

If you go looking for information on what a microservice is, you will find many different descriptions, exhibiting considerable difference of opinion. Most claims about microservices are non-technical rather than technical, for example the allegedly "independent" software development style around microservices, or some alleged organization of microservices "around business capabilities". Even when the claims do stick within the technical realm, they are often unwarranted; for example, I have seen statements to the effect that a microservice is supposed to live in its very own source code repository, that microservices must communicate with each other via nothing but REST, etc. My favorite one is that they must necessarily be stateless. This paper is a first step in dispelling the statelessness myth.

My notes on "Greg Young - The Long Sad History of Microservices"

Greg Young - The Long Sad History of Microservices
From the "Build Stuff" event of April 2017.

Talk begins at 9:45.

Highlights of the talk:

27:00 Placing a network between modules simply to enforce programmer discipline 

29:05 There is other levels of isolation I can go to. I can run a docker container per service. That's the coolest stuff right? What that means is I can make it work on my machine so I send my machine to production. 

29:52 Now, one thing that's very useful is I don't necessarily want to make this decision up front. And I don't necessarily want to make the same decision in dev as in production. I may want in dev to have a different way that we run things, why? because bringing up 19 docker containers on your laptop is not very much fun. I may prefer to host everything inside a single process to make debugging and such a lot easier when I am running on dev in my laptop. Whereas in production we may go off to multiple nodes. 

34:16 If you have maintenance windows, why are you working towards getting rid of your maintenance windows? Is this a business drive or is this you just being like C.V. driven development? 

My notes:

Unfortunately his shrieky voice makes him sound like he is bitching about things, which in a sense he is, but it would help his cause to deliver his criticism in a more palatable tone. Also, in order to make his point about microservices being nothing new he seems to disregard statelessness.

Resources referenced in the talk:

https://en.wikipedia.org/wiki/Queueing_theory

https://en.wikipedia.org/wiki/π-calculus

https://en.wikipedia.org/wiki/Actor_model

Leslie Lamport - Time, Clocks, and the Ordering of Events in a Distributed System
(available on the interwebz)

C.A.R. Hoare - Communicating Sequential Processes
(available on the interwebz)

Devoxx 2016 Belgium - Microservices Evolution: How to break your monolithic database by Edson Yanaga

My notes on Devoxx 2016 Belgium - Microservices Evolution: How to break your monolithic database by Edson Yanaga (I attended this conference)

Reduce maintenance window
Achieve zero downtime deployments
"Code is easy, state is hard"
Changes in a database schema from one version to another are called database migrations
Tools: Flyweight Liquibase
Migrations require back and forward compatibility
Baby steps = Smallest Possible Batch Size
Too many rows = Long Locks
Shard your updates (not updating the entire table in one go)

Renaming a column
    ALTER TABLE customers RENAME COLUMN wrong TO correct;
   becomes:
        ALTER TABLE customers ADD COLUMN correct VARCHAR(20);
   UPDATE customers SET correct = wrong WHERE id < 100;
   UPDATE customers SET correct = wrong WHERE id >= 100 AND id < 200;
   ...
   (later) ALTER TABLE customers DELETE COLUMN wrong;

Adding a column
ADD COLUMN, setting NULL/DEFAULT value/computed value
Next release: Use Column

Renaming / Changeing Type / Format of a Column:
Next version: ADD COLUMN, Copy data using small shards
Next release: Code reads from old column and writes to both
Next release: Code reads from new column and writes to both
Next release: Code reads and writes from new column
Next release: Delete old column

Deleting a column
    Next version: Stop using the column but keep updating the column
Next version: Delete the column

For migrating from a monolithic application with a monolithic database to many microservices with own database each:
    Using Event Sourcing
        tool: debezium.io
    You tell it which tables you want to monitor, and from then on it monitors them
and generates an event for each DDL/DML statement you issue.
The event is propagated to as many event consumers as you want.
So, microservices can receive these events and update their own databases.

"HTTP and REST are incredibly slow"

GOTO 2016 - Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned - R. Meshenberg

My notes on GOTO 2016 - Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned - R. Meshenberg

They have a division making a layer of tools for other teams to build their stuff on top of it.

Exceptions for statelessness are persistence (of course) but also caching.

Destructive testing - Chaos monkey -> simian army - in production, all the time. (During office hours)

Their separation of concerns looks like a grid, not like a vertical or horizontal table.

They have open sourced many of their tools, we can find them at netflix.github.com

GOTO 2015 - DDD & Microservices: At Last, Some Boundaries! - Eric Evans

My notes on GOTO 2015 - DDD & Microservices: At Last, Some Boundaries! - Eric Evans

Microservices and Netflix - what is the connection?

Isolated data stores

"A service is something that can consume messages and can produce messages"

GΟΤΟ 2014 - Microservices - Martin Fowler

My notes on GΟΤΟ 2014 - Microservices - Martin Fowler

Characteristics of Microservices

1. Componentization
2. Organized around business capabilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary Design

With services we typically use some kind of interprocess communication facilities such as web service calls or messaging or something of that kind.

How big should a microservice be?
    "It should have one responsibility" --too vague
"It should fit in my head" --fairly good

"You should not have a team that you cannot feed with 2 pizzas"