Managing a microservice

Creating a new runnable version using new files

  1. Go to a runnable’s detail page to create a new runnable version, click “View Versions”
_images/create_version_1.png
  1. Click “Add Version”
  2. Choose new files, enter a message and click “Add Version”
_images/create_version_3.png
  1. Click name of the new runnable version in Runnable Versions to go to the version’s detail page
_images/create_version_4.png
  1. Click “View Version Runs”
_images/create_version_5.png
  1. Click “Run” and make a run request to make sure it does not have any error. Use a test to test the new version automatically if possible (refer Testing a microservice)
_images/create_version_6.png

Creating a new runnable version by editing an existing file

  1. Often users made some simple typos that they want to directly edit files in the GUI rather than locally using a text editor
  2. Go to a runnable version that you want to edit
_images/read_file_2.png
  1. Click “Read Files.” Choose the file you want to edit. Click “Edit File” button
_images/read_file_3.png
  1. The content background color will change to white. Edit the file as you wish. Then click “Build” to create a new runnable version. Subsequent steps are same as the previous subsection Creating a new runnable version using new files
_images/read_file_4.png

Adjusting weights of runnable versions (A/B testing)

  1. Once you have multiple versions, you can decide how frequently each version should run. Go to a runnable’s detail page. Click “Adjust Weights”
  2. Assign weights for versions and click “Adjust Weights.” A version’s probability of running is its weight divided by sum of weights of all versions.
_images/adjust_weight_2.png

Waking up a runnable version

  1. If a runnable version with zero weight does not have any request within the last 24 hours, it will automatically go to a sleep mode to optimize backend resource usage
  2. To wake up the version to assign weights (a sleeping version won’t show in the adjust weight form), go to the version’s detail page and click the “Wake Up” button which will only show if the version’s status is sleeping

Protecting a runnable from going to sleep

  1. A runnable version with a positive weight without any request within the last 72 hours will go to sleep to save resources to maintain the API
  2. You can edit the “Termination Protection” of a runnable to True to protect positive-weight versions from going to sleep regardless of presence of a recent run request
_images/sleep_2.png

Setting timeout for a runnable

  1. Users can set timeout to stop unreasonably long requests to spend the resources to more immediate requests
  2. Go to a runnable’s detail page. Click “Edit” and enter the timeout value in seconds
  3. The default is 10 seconds. If a run takes longer than the value, it will be recorded as a timeout error. If you believe that the timeout value is too short, increase it. However, this will require more processes to handle long-running requests, which will subsequently cause more cost from using more backend resources. Please refer Monitoring – Troubleshoot an error run for related information.

Making an asynchronous API

  1. Users can set microservices to immediately return the name of a run without actually completing the request. This asynchronous behavior is useful for microservices where clients can just leave requests without having to wait for results. For example, a user can create a microservice that writes input records to a database. Clients do not have to wait for the actual writing to happen. In such scenario, asynchronous microservices will not make clients wait and distribute heavy workload to later time because it uses queues in the backend
  2. In “Edit” form of a runnable, select True for Asynchronous requests. Click “Edit” to submit

Configuring to validate input data first

  1. Users can validate input json before it hits microservices. This can be useful to prevent probing requests. Also, an invalid input might cause an error at the end of microservice’s operation, which makes the resource and time to carry the operation wasteful. To prevent such case, users can configure to validate input first. The Input JSON Schema in the API documentation, which users can edit, will be used to validate input if this option is selected
  2. In “Edit” form of a runnable, select True for Validate input. Click “Edit” to submit

Deleting a runnable version

  1. In a runnable version’s detail page, click “Delete”

Deleting a runnable

  1. In a runnable’s detail page, click “Delete”