4

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, Spring PetClinic and PiggyMetrics. These applications have top ranking stars on GitHub.

  • What research did you do? Could you add the findings to the question? – 030 Mar 3 '18 at 11:56
  • 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 Mar 3 '18 at 11:58
  • 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 Mar 3 '18 at 12:00
  • 1
    ok, thanks ... I will, i could not find tags for microservice components such as service registry/discovery e.t..c – SyCode Mar 3 '18 at 12:11
  • I think that this is more a question about the architecture. Perhaps you could add the architecture tag. – 030 Mar 3 '18 at 12:13
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".

  • Hi, sorry I haven’t commented because I though you hadn’t finished answering based on the prompt. – SyCode Mar 6 '18 at 16:16
  • @SyCode I have updated the answer – 030 Apr 26 '18 at 20:08
  • thanks for your comments, though very insightful the core question isn't answered. – SyCode Jun 3 '18 at 15:36
  • What is the core question? – 030 Jun 3 '18 at 15:40
  • 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 Jun 3 '18 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.