Datawire open source tools help you code faster on Kubernetes. Dozens of cloud native companies and organizations use Datawire tools every day. Define and deploy multi-container applications with Forge. Code and debug services locally with Telepresence. Publish services with Ambassador.

    Shared development models and multi-service applications

    So far, we've talked about a single developer / single service workflow. But developers work as part of a larger application team that consists of multiple services. This presents two common scenarios:

    • How do multiple developers simultaneously develop the same service
    • How do you develop services that are used by other services?

    These two questions generate two disparate requirements for your development environment(s):

    1. you need a way to isolate development from each others
    2. you need a way to integration test your service with other services

    Simultaneous development of the same service

    In order to support simultaneous development of the same service, each development instance of the service needs to be isolated from the other versions. Several approaches for development isolation exist:

    • Multiple local development environments. Each developer deploys the entire application locally, and has complete isolation. The downside of this approach is that many applications cannot be run locally (e.g., they're too complex or they depend on cloud services). Moreover, it does not address the challenge of integration testing.
    • Multiple remote development environments. Each developer gets her own namespace or cluster, and the application is deployed into this environment. This approach can become expensive from a management and cost perspective. Moreover, it does not address the challenge of integration testing.
    • Single shared cluster. All developers develop against a single shared cluster. To prevent collisions, unique names for development services are used. This approach requires a common system for deploying development services.

    Hands-on

    Forge can be used with any of these models. In this walk-through, we'll show how Forge can be used with the single shared cluster model.

    1. Clone the service template, if you haven't already:

      git clone https://github.com/datawire/hello-world-python
      
    2. Let's take a closer look at the default profile in the service.yaml:

      default:
        name: {{branch.replace('/', '-')}}
        endpoint: /preview/hello/{{branch}}/
        max_memory: 0.25G
        max_cpu: 0.25
      

      The default profile is designed for development, and uses the branch name as the name of the service. It also publishes the service under the preview URL.

    3. Create a branch for the service:

      git checkout -b dev/feature
      
    4. Now, deploy the service:

      forge deploy
      
    5. Based on the service.yaml, Forge will automatically add the branch name as a suffix to the Kubernetes service and deployment.

      $ kubectl get svc
      NAME                      CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
      ambassador                10.11.250.208   35.190.189.139   80:31622/TCP   14d
      hello-world-dev-feature   10.11.249.254   <none>           80/TCP         12s
      kubernetes                10.11.240.1     <none>           443/TCP        43d
      
    6. Based on the service.yaml register this service with Ambassador under the preview/hello/dev-feature/ URL:

      curl $AMBASSADOR_URL/preview/hello/dev-feature/
      
    7. By assigning each service a unique name and preview URL, developers are able to independently run and test dev versions of the same service.

    Next Steps