Today it’s time for our Chief Architect Frans to round off his blog series about microservices in a final blogpost.
In my previous blogpost I wrote about the pros and cons with microservices and problems arising from introducing them prematurely. When things are very uncertain and there is need for experimentation, microservices may be an unnecessary burden and make it harder to do certain unplanned changes.
However, if you let your product’s functionality and your development team grow too much before introducing microservices, you will run into other problems and it might be too late to refactor. Ideally, you would like to plan and prepare for microservices in advance but keep things as simple as possible to save time and money.
A good approach – which we have adopted at Kiosked – is to educate the team about microservices and what our future microservices architecture could look like. This allows developers to plan the interfaces in code in such a way that refactoring the components into microservices is less painful when the time comes.
At Kiosked we always draw high-level architecture diagrams where all components are already shown as separate microservices. This is just to incorporate the idea, as early as possible, that the codebase will one day be split into microservices. The quality of all interfaces in the code will be quite good since the developers know that the interfaces will one day be exposed as REST APIs.
During the years, plenty of components never made it as microservices. The usual reason was that there was really no significant need. Sometimes this was because the component never grew big enough or things changed and the component became obsolete.
At Kiosked we have a bunch of components in full use still waiting for the right time to be extracted into microservices. If we had decided to build everything as microservices immediately, we would probably still be working on those initial obsolete components.
Architecture is an ongoing discussion at Kiosked. We have a team of highly-skilled senior developers who are all contributing to the architecture. They often build separate Composer components, which are kind of halfway to microservices, since these components are already separate projects under version control. When the time comes, it is fairly trivial to write REST APIs for the interfaces and have the components deployed to separate servers.
So in the end, it all comes down to understanding the tradeoffs and having a great team where every member shares the same future architectural vision. We are lucky to have that at Kiosked.