Create simple guidelines and live by them to successfully implement and maintain your Microservices.
As mentioned already in previous blog posts, one important purpose of implementing Microservices is to enable development teams to work indepent from each other and to enable innovation to a greater extent in each team. Well, innovation and independence is all good, but how can one make sure that teams and developers do not go completely out of control and leave a maintenance mess behind them? The trick is to enforce a level of control and coherence without choking innovation in a ton of documentation and control mechanisms. Our solution to address this challenge is to define a number of simple and clear guidelines that everybody is obliged to follow.
Guidelines can be used not only to steer your Microservices initiative, but also to help your developers to get started and be productive as soon as possible. If everybody sticks to guidelines, you will have a code base that is easier to maintain, control and monitor. Our recommendation is to start with a PoC and use the learnings and outcome from that to define your Microservices guidelines. If possible, verify with your first team that the guidelines are easy to understand and live by before going for a full roll out.
5 suggestions for your Microservices guidelines:
1. Define solid Microservices principles
To achieve an architecture that really gives you the desired flexibility and Microservices that performs independently from each other, you need developers to stick to a few fundamental rules. An example; make sure that each Microservice is able to release and function all by itself. As soon as you have Microservices that are connected and dependent on each other when released or operating, you have broken one of the ground rules for Microservices and have decreased chances of achieving your objectives with the initiative. There are probably not more than 3-4 of these very fundamental and absolutely ”no break” rules that you can define for your initiative.
2. Code templates
To help new developers get started and to make sure that they are productive as soon as possible, you can assist them with a few useful code templates. These are not meant to hamper innovation, but rather to sparc innovation by helping them get started and quickly get over potential initial problems that would be counter productive. Code templates can also be used for various simple functions that needs to be performed on each Microservice, which would not only help developers to avoid doing repeatable work, but also make sure that the most efficient function is used and reused for this functionality.
3. Reference architecture
With an established reference architecture you can train and prepare developers on how to best utilise assisting tools and integrate their Microservices in the full platform. With a reference architecture in place and guidelines for how it is supposed to be utilised, you increase chances of your Microservices initiative to be long term successful (more on the reference architecture/platform in coming posts).
4. Ready-made development environment
Through our own experience we have noticed that an easy and smooth onboarding of new developers is important for the success of a Microservices initiative. This is simply due to the fact that the easier you make it for developers to get started working in your project and the better prepared you are to include newcomers, the quicker it will be for them to be productive. We have also seen that the buy-in and commitment to the project from developers increases when you are well prepared and show that you are keen on getting them on board to contribute to the project. With a ready made and easy to use development environment that is easy accessible and easy to install, you will both increase productivity and commitment from your team members.
5. Documentation
Documentation is seldom a hot topic for developers. However, many experienced developers have learnt the hard way (when taking over a project from a colleague or assigned the responsibility to maintain old code), that documentation is very important for the bigger picture. Some might argue that the demand for documentation decreases with Microservices, since each function/code unit will be so small that it is “self explanatory”. This might be true to some extent, but our experience is that even with the best Microservices initiative or project, you will still need to document the purpose of your microservice, how to communicate with it and which API/-s that are available. Also remember that when there is a need to modify or maintain your piece of code, you might not be in the project anymore and someone else is supposed to do it instead of you. What would you require or wish for if it were the other way around? Anyway – with proper guidelines it is not up to the unique developer/person to decide on how and what to document, it should be the choice of the project to define guidelines for documentation and how to adhere to these.
Learn more about our Microservices Ready model here
