Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-06T16:16:09.990Z
Answers: Hi, sorry I haven’t commented because I though you hadn’t finished answering based on the prompt.
Answers: SyCode
Answers: CC BY-SA 3.0
Answers: 2018-04-26T20:08:45.107Z
Answers: @SyCode I have updated the answer
Answers: 030
Answers: CC BY-SA 4.0
Answers: 2018-06-03T15:36:56.740Z
Answers: thanks for your comments, though very insightful the core question isn't answered.
Answers: SyCode
Answers: CC BY-SA 4.0
Answers: 2018-06-03T15:40:55.480Z
Answers: What is the core question?
Answers: 030
Answers: CC BY-SA 4.0
Answers: 2018-06-03T15:49:57.987Z
Answers: 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 ?
Answers: SyCode
Answers: CC BY-SA 4.0
Answers: 2018-03-03T12:49:48.050Z
Answers: 2019-09-02T08:14:22.830Z
Answers: 2019-09-02T08:14:22.830Z
Answers: 030
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-03T11:56:58.613Z
Comments: What research did you do? Could you add the findings to the question?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-03T11:58:17.333Z
Comments: `In a standard cloud based microservice application, there could be two main categories of microservices`. Where did you read that? Please add the source.
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-03T12:00:32.900Z
Comments: 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.
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-03T12:11:57.503Z
Comments: ok, thanks ... I will, i could not find tags for microservice components such as service registry/discovery e.t..c
Comments: SyCode
Comments: CC BY-SA 3.0
Comments: 2018-03-03T12:13:24.513Z
Comments: I think that this is more a question about the architecture. Perhaps you could add the architecture tag.
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2019-09-06T16:55:13.943Z
Comments: 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.
Comments: Dan1701
Tags: <microservices><architecture>
Title: Microservices terminology i.e. distinguishing between "core " and "other service instances"
UserDisplayName: SyCode
ThreadText: # 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 ?  
  
  ---
  
  