<p>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.</p>

<p>Reasons:</p>

<ul>
<li>architect that only read a blog about microservices and claims that he is the expert of microservices</li>
<li>team members that lack knowledge, but indicate that they know everything about it as the architect told them about it</li>
<li>lack of DevOps mindset</li>
<li>no support from management</li>
<li>thinking that microservices are the holy grail, i.e. Y=>X instead of X=>Y</li>
</ul>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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. </p>

<p>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.</p>

<p>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.</p>

<hr>

<p>Note: once the current backlog is complete, an additional paragraph about</p>

<blockquote>
  <p>If Microservices terminology i.e. distinguishing between <code>core</code> and
  <code>other service instances</code></p>
</blockquote>

<p>will follow.</p>

<p>April 26 2018</p>

<p>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.</p>

<p>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).</p>

<p>The common code will be moved to separate repos as well and published as artifacts so they could be used by the microservices.</p>

<p>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. </p>

<p>Microservices are not the holy grail</p>

<p>Automation is key</p>

<p>"Do one thing and do it well".</p>

CC BY-SA 3.0
2018-03-06T16:16:09.990Z
Hi, sorry I haven’t commented because I though you hadn’t finished answering based on the prompt.
SyCode
CC BY-SA 3.0
2018-04-26T20:08:45.107Z
@SyCode I have updated the answer
030
CC BY-SA 4.0
2018-06-03T15:36:56.740Z
thanks for your comments, though very insightful the core question isn't answered.
SyCode
CC BY-SA 4.0
2018-06-03T15:40:55.480Z
What is the core question?
030
CC BY-SA 4.0
2018-06-03T15:49:57.987Z
Its a question about the naming convention for types of microservices. For example, your project you consists of several microservices `API, writer, selector, insert and tableCreator.` etc. These will perform the custom functionalities you want,  however for them to work within the concept of `microservices` , there is need for co-ordination etc therefore other services like API gateway, discovery/registry, load-balancer etc might be included. What will be the name for these two categories of microservices, the former (custom) and later ones ?
SyCode
CC BY-SA 4.0
2018-03-03T12:49:48.050Z
2019-09-02T08:14:22.830Z
2019-09-02T08:14:22.830Z
030
<p>In a standard cloud based microservice application, there could be two main categories of microservices: </p>

<ul>
<li><code>core services</code> such as service registry &amp; discovery, api-gateway, load-balancer etc. </li>
<li><code>service instances</code> e.g customers, billing and postage services. </li>
</ul>

<p>In this illustration, I used  <code>core services</code> and <code>service instances</code> to distinguish the two main groups. Are there standard naming conventions for these two or is my classification/thinking right? </p>

<p>Here are some demo projects about the subject and each of these consists of the mentioned services: <a href="https://microservices-demo.github.io/" rel="nofollow noreferrer">Weaveworks Socks Shop</a>, <a href="https://github.com/spring-petclinic/spring-petclinic-microservices" rel="nofollow noreferrer">Spring PetClinic</a> and <a href="https://github.com/sqshq/PiggyMetrics" rel="nofollow noreferrer">PiggyMetrics</a>. These applications have top ranking stars on GitHub.</p>

CC BY-SA 3.0
2018-03-03T11:56:58.613Z
What research did you do? Could you add the findings to the question?
030
CC BY-SA 3.0
2018-03-03T11:58:17.333Z
`In a standard cloud based microservice application, there could be two main categories of microservices`. Where did you read that? Please add the source.
030
CC BY-SA 3.0
2018-03-03T12:00:32.900Z
Please remove the docker and load-balance tags as this question is a generic question about microservices, i.e. there are alternatives to docker and microservices could be run without loadbalancers.
030
CC BY-SA 3.0
2018-03-03T12:11:57.503Z
ok, thanks ... I will, i could not find tags for microservice components such as service registry/discovery e.t..c
SyCode
CC BY-SA 3.0
2018-03-03T12:13:24.513Z
I think that this is more a question about the architecture. Perhaps you could add the architecture tag.
030
CC BY-SA 4.0
2019-09-06T16:55:13.943Z
I wouldn't get hung up on this nomenclature. While there is a broad distinction between the services which you are creating to solve business problems vs. those that are in support of your own stuff (likely 3rd party), these are not standardized categories. I would use whatever terminology you need to accurately describe your tech stack for to your developers and users.
Dan1701
<microservices><architecture>
Microservices terminology i.e. distinguishing between "core " and "other service instances"
SyCode
# Microservices terminology i.e. distinguishing between "core " and "other service instances"

(Asked by: username_0 on 2018-03-03)

In a standard cloud based microservice application, there could be two main categories of microservices:

* `core services` such as service registry & discovery, api-gateway, load-balancer etc.
* `service instances` e.g customers, billing and postage services.

In this illustration, I used `core services` and `service instances` to distinguish the two main groups. Are there standard naming conventions for these two or is my classification/thinking right?

Here are some demo projects about the subject and each of these consists of the mentioned services: [Weaveworks Socks Shop](https://microservices-demo.github.io/), [Spring PetClinic](https://github.com/spring-petclinic/spring-petclinic-microservices) and [PiggyMetrics](https://github.com/sqshq/PiggyMetrics). These applications have top ranking stars on GitHub.

**Tags:** microservices, architecture

> **Comments:**
> **username_1**: What research did you do? Could you add the findings to the question?  
> **username_1**: `In a standard cloud based microservice application, there could be two main categories of microservices`. Where did you read that? Please add the source.  
> **username_1**: Please remove the docker and load-balance tags as this question is a generic question about microservices, i.e. there are alternatives to docker and microservices could be run without loadbalancers.  
> **username_0**: ok, thanks ... I will, i could not find tags for microservice components such as service registry/discovery e.t..c  
> **username_1**: I think that this is more a question about the architecture. Perhaps you could add the architecture tag.  
> **username_2**: I wouldn't get hung up on this nomenclature. While there is a broad distinction between the services which you are creating to solve business problems vs. those that are in support of your own stuff (likely 3rd party), these are not standardized categories. I would use whatever terminology you need to accurately describe your tech stack for to your developers and users.  

---

## 1 answers

### Answer by username_1 on 2018-03-03. Score: 1

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".

> **Comments:**
> **username_0**: Hi, sorry I haven’t commented because I though you hadn’t finished answering based on the prompt.  
> **username_1**: @username_0 I have updated the answer  
> **username_0**: thanks for your comments, though very insightful the core question isn't answered.  
> **username_1**: What is the core question?  
> **username_0**: Its a question about the naming convention for types of microservices. For example, your project you consists of several microservices `API, writer, selector, insert and tableCreator.` etc. These will perform the custom functionalities you want,  however for them to work within the concept of `microservices` , there is need for co-ordination etc therefore other services like API gateway, discovery/registry, load-balancer etc might be included. What will be the name for these two categories of microservices, the former (custom) and later ones ?  

---

