The last couple of years I am/was part of couple of DevOps teams that are/were creating microservices. Some of the projects failed miserably.
Reasons:
- architect that only read a blog about microservices and claims that he is the expert of microservices
- team members that lack knowledge, but indicate that they know everything about it as the architect told them about it
- lack of DevOps mindset
- no support from management
- thinking that microservices are the holy grail, i.e. Y=>X instead of X=>Y
According to me, a DevOps mindset is that one works together and that one focuses on deliverables, i.e. new software live within two weeks. If one wants to create all microservices in advance then a lot of assumptions have to be done and nothing will be put to production, i.e. available to the customer.
This happened in one of my projects. The architects was continuously talking about "what if this would happen and this" and so on. Outcome? After one year, nothing was running in production.
In my opinion, some companies start with microservices because they have heard about it, but do not know exactly what microservices are. Microservices are not the holy grail, e.g. one could create nanoservices, one should master automation.
My point of view about microservices is that one should start with a monolith first, e.g. if you want a webshop just start with it and ensures that it is running in production within two weeks. Secondly, start monitoring it, check if there are problems in certain areas, e.g. more bugs in component X or component Y is extremely slow. If it is clear that component Y is slow, create a plan of extracting it, rewrite it within two weeks, apply autoscaling.
I am in favor of the "cheese slicer method". As the cheese itself is a product that delivers value and is running in production and the X=>Y approach is used. Start with a problem and check what could solve this problem, instead of thinking about a solution, e.g. microservices (Y) that could solve a (hypothetical) problem.
For your information. I am currently busy with a personal microservices project that consists of two microservices, e.g. an api and a write microservice. I am first solving the impediments and cleaning up my backlog. Off course I have some ideas about next microservices, but I want to put first things first and add value to the customers instead of doing a lot without finishing this microservice project that I have already experienced a couple of times.
Note: once the current backlog is complete, an additional paragraph about
If Microservices terminology i.e. distinguishing between core and
other service instances
will follow.
April 26 2018
At the moment I have a monorepo that consists of 5 microservices, i.e. an API, writer, selector, insert and tableCreator. On one hand it is nice as the shared code could be used directly, but when a code change is pushed then I need to build everything.
The next steps is to create five repos and extract the code from the monorepo to each individual repo. Advantages of this is that a code change to a repo builds the microservice that has been changed, smaller code base (easier to read).
The common code will be moved to separate repos as well and published as artifacts so they could be used by the microservices.
One of the prerequisites is that CI and CD are enabled for each repo. Otherwise it will take a lot of time before everything has been deployed.
Microservices are not the holy grail
Automation is key
"Do one thing and do it well".
In a standard cloud based microservice application, there could be two main categories of microservices. Where did you read that? Please add the source.