2 Components

 

Software developers have been chasing the idea of software components since the first electron crossed a transistor gate, and mathematicians have been chasing components for much longer than that. None of us can quite agree on what software components are but we all know that we need them. They are the secret to building large systems.

Our mainstream programming languages are too fine-grained, and operate below the level that we need for large scale work. So we invent component models and design patterns for using these models, attempting to tame the complexity that breeds quickly in our code.

If microservices are to fulfill their promise they too must have a component model. We should think carefully about what that model should be, and what problems it shoud solve.

2.1 The technical debt crisis

The problem is that we can’t write software fast enough. We can’t write software that meets business needs and that is sufficiently accurate and reliable, within the time constraints set by the markets in which our companies operate. When requirements change in the middle of a project, it damages our architecture so badly that we spiral into a death march of hacks and kludges to force our data structures, concepts, and entity relationships into compliance. We try to refactor or rewrite, and that delays things even further. Our component models fall apart.

2.2 How the monolith betrays the promise of components

2.3 The microservice idea

2.3.1 The core technical principles

2.4 Practical implications

2.4.1 Specification

2.4.2 Modelling

2.4.3 Deployment

2.4.4 Security

2.4.5 People

2.5 What you get for your money

2.6 Summary