...

What are Microservices?

A microservice in PIPEFORCE is an application which runs inside a (Docker) container which in term runs inside the PIPEFORCE (Kubernetes) cluster. Such a microservice can communicate with other microservices inside the same namespace via messaging and REST. A namespace can “host” many such microservices:

...

PIPEFORCE offers a lot of toolings to develop, deploy and monitor your microservices in your namesace. This is called the Microservices Framework.

Microservice or App?

In general, you have three main possibilities to write a business application:

...

• The app should contain:

  • Connections to external systems

  • Data mappings and transformations

  • Forms and lists

  • Stateful workflows

• The microservice should contain:

  • Complex business specific logic

Designing a Microservice​

Typically a microservice is a relatively small application which has the responsibility about a concrete and well-defined part of an overall business process. How you slice the microservices depends on your requirements.

...

See here for a good introduction how to design microservices: https://martinfowler.com/articles/break-monolith-into-microservices.html

Develop a Microservice​

Developing a microservice typically means, developing a business application in the programming language of your choice.

...

• Sync communication - Typically used with RESTful services inside PIPEFORCE.

• Async communication - Typically used with RabbitMQ and messaging inside PIPEFORCE (preferred way).

Deploy / Start a Microservice​

Once a microservice has been developed, it must be wrapped inside a (Docker) image in order to be able to deploy it into PIPEFORCE. The deployment cycle of a microservice in PIPEFORCE is always an 4-step task:

...

• service.start - Starts a new service by deploying an image.

• service.stop - Stops a running service.

• service.status - Returns the status of a service.

Default ENV variables​

Every time a service is started using the service.start command, also some implicit default variables will be automatically passed to this container and can be accessed via the environment variables inside the container. These variables are:

...

Custom ENV variables

Additionally to these default environment variables, you can also add your custom ones by using the parameter env on the command service.start:

pipeline:
  - service.start:
      name: myservice
      image: myimage
      env:
        MY_ENV: "myCustomValue"

Secret ENV variables​

In case you would like to pass secret values to your service ENV variables, you have to do these steps:

...

Shared secret ENV variables

In case you would like to share a single secret across multiple services, you must prefix it with SHARED_ instead. Secrets prefixed with SHARED_ can be passed to any microservice without security check.

...

Monitoring a microservice​

Logging

Everything you log into the standard output of your microservice container can be later viewed by using the command log.list and specifying the name under which you have deployed the service. Example:

...

Additionally you can use the log listing in the web portal to filter and search the logs of your microservice:

...

Service Status

The Services view in the web portal will show you the deployment status of your services. Here you can install new services, see their status and stop running services:

...

• service.start - Starts a new service by deploying an image.

• service.stop - Stops a running service.

• service.status - Returns the status of a service.

Messaging in a Microservice

The preferred way each microservice inside PIPEFORCE can communicate with each other is by using messaging.

...

If you're interested in how to send and receive messages using pipelines, see Messaging and Events Framework.

How to connect a Microservice with the message broker?​

In case you have deployed your microservice using the command service.start, then these environment variables will be automatically provided inside your microservice and can be used to connect to the RabbitMQ message broker:

...

Also remember to setup the dead leader queue in order to not lose any message as mentioned below.

Default Queue Naming​

By default any microservice is responsible to setup and manage its own queues.

...

service_shoppingcart_orders_q

Default Topic​

PIPEFORCE automatically creates a default topic exchange on startup with this name: pipeforce.default.topic.

...

See here for more details about topics, routings and queues: https://www.rabbitmq.com/tutorials/tutorial-five-python.html

Default Dead Letter Queue​

Additionally, a default Dead Letter Queue is automatically configured by PIPEFORCE those name is given by the ENV variable PIPEFORCE_MESSAGING_DEFAULT_DLQ.

...

return QueueBuilder.durable(Constants.MY_QUEUE)
    .withArgument("x-dead-letter-exchange", "")
    .withArgument("x-dead-letter-routing-key", "pipeforce_hub_default_dlq)
    .build();

Default Message Keys​

Here you can find the default message keys, PIPEFORCE will use for internal events and send messages with these keys to the default topic pipeforce.hub.default.topic. You can subscribe to these keys using a binding between your queue and this default topic.

...