Managing microservices means looking after lots of small systems talking to each other and automated provisioning as well as infrastructure automation is crucial, James Lewis states when sharing techniques and practices that have helped him manage the increased operational complexity a microservice architecture gives.
James, a consultant working for ThoughtWorks, describes the origin of microservices as a reaction to how we have been building big monolithic applications that are difficult to change, test and manage; essentially big balls of mud with tangled spaghetti code. The solution being building smaller things and make them communicate in some way.
For James microservices means taking a large application, identifying the bounded contexts and business capabilities within and splitting them out, crucially taking data with them, i.e. application databases instead of one integration database. The key thing is starting at the top with a context map in order to understand the business domain and James refers to his colleague Ian Cartwright:
There should be business and architecture isomorphism. A business person should be able to look at a high level map of the architecture and see the business represented there and similarly as technologists we should be able to look at the business and see the architecture represented there.
An important aspect of microservices is size and James sees Single Responsibility Pattern (SRP) as a good measure. A service should have a single reason to change which in practice means it should be small and focused enough to be possible to grasp conceptually.
A core concept of microservices for James is the possibility to independently deploy and scale each service; a service may be deployed as several instances and different services may be hosted on the same server. When building and deploying distributed systems, a focus on automated provisioning is crucial James emphasizes, each service or application have to be built, deployed and scaled automatically. With microservices a lot of the complexity comes from integration but we can apply patterns to solve this and refers to the book Continuous Delivery for patterns of build pipelines.
Infrastructure automation with tools like Chef and Puppet helping in automatic provisioning of machines is central in managing the complexity coming with lots of services. Phoenix infrastructure patterns describe how we by using infrastructure automation always should be able to recreate all infrastructure, e.g. we should be able to wipe a box and run a script to rebuild it complete with all dependencies.
The microservice conference James mentions is scheduled for late November in London.
