Design note: from components to microservices
This note goes with the application section of Structure of EK9. EK9 builds components, applications and dependency injection into the language. That is not an invitation to build one very large application.
Not a monolith
A very large monolithic application leads to:
- Team coordination issues
- Excessive application size
- Increased memory foot print
- Slower startup times
- Close coupling
- Dependency conflicts
- Lack of scalability
- Much longer build cycles
- Reduced flexibility in deployment models
Once software passes a certain size (and judging it takes rules of thumb and experience), you have to move to microservices, even in a desktop application. Microsoft does it with the Language Server Protocol, and AWS with almost all of its services; it clearly has merit.
But you have to architect the solution, and not leave it too late. Agile is the current practice, but you still must plan an overall design and focus on coupling and cohesion.
When to move
- Too many components. When you feel you have too many, start thinking of microservices. If you have wrapped your components well, refactoring them into microservices is easier. The application loses some 'snappiness' to marshalling and network latency, and gains maintainability, development agility, and better scaling and robustness.
- Team size and autonomy. If part of an application can be isolated, with its own development and deployment lifecycle, consider making it a microservice.
Hedge your bets
Components, packages and module naming together are the key to formalising interfaces that can be turned into microservices. Design with all three in mind and you have hedged your bets if the software starts to get really large.
Back to the car manufacturing analogy: a vehicle designed to standards (bearing sizes, connectors, wiring capacity) can take alternative or additional components, such as bearings with higher performance, more load or higher speeds, or more electrical load for navigation, automation and sensors. Those innovations fit only if the original design envisaged future change.
EK9's service construct is how you build the microservices themselves.