Custom Devservices

[Stuart Douglas]

Hi Everyone,

I have been working on a feature at [1] that allows for any image to be used as a Devservice.

I think the easiest way to explain it is with a few examples. Say I wanted to start an image that exposed a REST API and automatically wire up my MP REST client to talk to it, I would do the following:

quarkus.devservices.custom.test.image=stuart/getting-started:1.0.0-SNAPSHOT
quarkus.devservices.custom.test.url-prefix=http://
quarkus.devservices.custom.test.ports=8080
org.acme.rest.client.GreetingService/mp-rest/url=${quarkus.devservices.custom.test.url}

The first line gives us the image name ('test' is an arbitrary name, you can have any number of these, and they are started alphabetically). The second line is used to build the url, and the third line tells Quarkus the port to expose. The file line actually wires up the  REST client to use the resulting URL after Quarkus has started.

Let's look at a slightly more complex example, say I want to start a Quarkus application as a dev service that uses a database, but I want it to share the current applications devservices managed database, I would do the following:

quarkus.devservices.custom.test.image=stuart/hibernate-orm-quickstart:1.0.0-SNAPSHOT
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_JDBC_URL=[quarkus.datasource.jdbc.url]
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_PASSWORD=[quarkus.datasource.password]
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_USERNAME=[quarkus.datasource.username]

As above the first line is the image name, but the subsequent lines set environment variables to the properties that were set by the database devservice. This uses a different syntax to our normal expansions, as this is not actually part of the config system (it's not really build or runtime config, it's config that becomes available as containers are started).

This is not 100% complete (e.g. if you tried the example above with Kafka instead it won't work just yet), however I thought I would gather some feedback before I put the finishing touches on it and start writing tests and docs.

Stuart

[1] https://github.com/stuartwdouglas/quarkus/tree/generic-devservices

[Max Rydahl Andersen]

Hi Everyone,

I have been working on a feature at [1] that allows for any image to be
used as a Devservice.

cool.

I think the easiest way to explain it is with a few examples. Say I wanted
to start an image that exposed a REST API and automatically wire up my MP
REST client to talk to it, I would do the following:

quarkus.devservices.custom.test.image=stuart/getting-started:1.0.0-SNAPSHOT
quarkus.devservices.custom.test.url-prefix=http://
quarkus.devservices.custom.test.ports=8080
org.acme.rest.client.GreetingService/mp-rest/url=${quarkus.devservices.custom.test.url}

The first line gives us the image name ('test' is an arbitrary name, you
can have any number of these, and they are started alphabetically). The
second line is used to build the url, and the third line tells Quarkus the
port to expose. The file line actually wires up the REST client to use the
resulting URL after Quarkus has started.

a) should we be able to specify a command to run natively rather than "only" in a container via image ? maybe refer to maven artifact to run ?
b) should http:// prefer for these devservices not just be http:// by default ?
c) the port assignment should be random should it not to avoid conflicts ? also you'll need a port mapping from container to host port won't you ?
d) would it make sense to be able to refer to metadata on the container to expose to quarkus beyond just the port for url building ?

Let's look at a slightly more complex example, say I want to start a
Quarkus application as a dev service that uses a database, but I want it to
share the current applications devservices managed database, I would do the
following:

quarkus.devservices.custom.test.image=stuart/hibernate-orm-quickstart:1.0.0-SNAPSHOT
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_JDBC_URL=[quarkus.datasource.jdbc.url]
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_PASSWORD=[quarkus.datasource.password]
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_USERNAME=[quarkus.datasource.username]

As above the first line is the image name, but the subsequent lines set
environment variables to the properties that were set by the database
devservice. This uses a different syntax to our normal expansions, as this
is not actually part of the config system (it's not really build or runtime
config, it's config that becomes available as containers are started).

you mean the key quarkus.devservices.custom.* is part of the config system but the value [quarkus.datasource.password] is to be resolved lazily later. Makes sense ....not a super fan of alternate syntax ....could we just have it be escape ? \${quarkus...} or use $[quarkus...] to say ${} is resolved eagerly and $[] is lazily/later ?

This is not 100% complete (e.g. if you tried the example above with Kafka
instead it won't work just yet), however I thought I would gather some
feedback before I put the finishing touches on it and start writing tests
and docs.

Looks interesting for sure.

/max

Stuart

[1] https://github.com/stuartwdouglas/quarkus/tree/generic-devservices

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cxLYhr%3Dq1MeKAYrAPAGjK63-vODPdAgwFtDOKnJmG%2BNxA%40mail.gmail.com.

[Stuart Douglas]

On Fri, 1 Oct 2021 at 18:00, Max Rydahl Andersen <mand...@redhat.com> wrote:

Hi Everyone,

I have been working on a feature at [1] that allows for any image to be
used as a Devservice.

cool.

I think the easiest way to explain it is with a few examples. Say I wanted
to start an image that exposed a REST API and automatically wire up my MP
REST client to talk to it, I would do the following:

quarkus.devservices.custom.test.image=stuart/getting-started:1.0.0-SNAPSHOT
quarkus.devservices.custom.test.url-prefix=http://
quarkus.devservices.custom.test.ports=8080
org.acme.rest.client.GreetingService/mp-rest/url=${quarkus.devservices.custom.test.url}

The first line gives us the image name ('test' is an arbitrary name, you
can have any number of these, and they are started alphabetically). The
second line is used to build the url, and the third line tells Quarkus the
port to expose. The file line actually wires up the REST client to use the
resulting URL after Quarkus has started.

a) should we be able to specify a command to run natively rather than "only" in a container via image ? maybe refer to maven artifact to run ?

We can do that as well, but IMHO this is a different thing. I think the main use case for this would be things like starting a frontend server when you start dev mode.

 

b) should http:// prefer for these devservices not just be http:// by default ?

Probably. You can start any protocol, not just HTTP, but this is likely the most common. At the moment if you don't specify this you just get a property with host:port that you can use however you like.

 

c) the port assignment should be random should it not to avoid conflicts ? also you'll need a port mapping from container to host port won't you ?

Port assignment is random, 8080 is the port to expose from the image, the actual mapped port ends up in the  URL property (also in quarkus.devservices.custom.test.mapped-ports.8080);

 

d) would it make sense to be able to refer to metadata on the container to expose to quarkus beyond just the port for url building ?

Yes, possibly, but let's not run before we can walk. The main use case I am thinking of here is automatic remote dev, so if your image is a quarkus mutable jar and you run remote-dev in the project that corresponds to  it then it will auto connect and you can easily work on both projects at once.

Potentially if the other project is also a quarkus project we could also generate metadata based on that projects devservices info, and use it to auto connect stuff with no configuration (in a similar manner to what we already do with label based discovery).

 

Let's look at a slightly more complex example, say I want to start a
Quarkus application as a dev service that uses a database, but I want it to
share the current applications devservices managed database, I would do the
following:

quarkus.devservices.custom.test.image=stuart/hibernate-orm-quickstart:1.0.0-SNAPSHOT
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_JDBC_URL=[quarkus.datasource.jdbc.url]
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_PASSWORD=[quarkus.datasource.password]
quarkus.devservices.custom.test.env.QUARKUS_DATASOURCE_USERNAME=[quarkus.datasource.username]

As above the first line is the image name, but the subsequent lines set
environment variables to the properties that were set by the database
devservice. This uses a different syntax to our normal expansions, as this
is not actually part of the config system (it's not really build or runtime
config, it's config that becomes available as containers are started).

you mean the key quarkus.devservices.custom.* is part of the config system but the value [quarkus.datasource.password] is to be resolved lazily later. Makes sense ....not a super fan of alternate syntax ....could we just have it be escape ? \${quarkus...} or use $[quarkus...] to say ${} is resolved eagerly and $[] is lazily/later ?

The issue is it does not really tie in at all. These properties are not available at the start of build time, but become available as containers are started and ports are mapped. I guess $[quarkus...] makes more sense, but either way it is always going to be a bit out of the ordinary.

Stuart

[William Burke]

Can't you do this kind of stuff with docker compose?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cwHWLY1Cskw%2BhKbHwZP74KT1%3DJ8tTYkS47NUwGf_9Kwmw%40mail.gmail.com.

--

Bill Burke

Red Hat

[William Burke]

On Fri, Oct 1, 2021 at 4:12 AM Stuart Douglas <sdou...@redhat.com> wrote:

Potentially if the other project is also a quarkus project we could also generate metadata based on that projects devservices info, and use it to auto connect stuff with no configuration (in a similar manner to what we already do with label based discovery).

I think this is the more interesting idea of Quarkus automatically publishing configuration points for auto wiring in a docker/kube environment.  Then somebody does not have to define the container and can just deploy the Quarkus app.  The idea I had awhile ago was a kube/openshift deployment service for quarkus that would allow you to take the container out of the equation and punt it so that "we" Red Hat could control the container and take one step out of the dev process.

But, I'm pretty sure the other composition stuff you are doing already exists, specifically with Docker Compose.  And you can always define a set of services for Kube/Openshift too.  What you're doing seems a bit redundant.

[Max Rydahl Andersen]

You do know we kinda already do deploy to openshift and you don’t need to do anything, right ? :)

  Yes this custom dev service overlaps with docker compose but that is what testcontainers are. Automated docker compose for app development as opposed to generic anything docker compose. 

Take this further and this can be used to output a docker compose or a service setup for Kubernetes dev environment. 

The advantage here is that you don’t need to install anything and the wiring / configuration is much more automatic/defaultable (is that a word :)

/max

[William Burke]

On Fri, Oct 1, 2021 at 2:34 PM Max Rydahl Andersen <mand...@redhat.com> wrote:

You do know we kinda already do deploy to openshift and you don’t need to do anything, right ? :)

I thought it was client based, via maven plugins and such?  Imagine if you had 50 microservice projects and they all need to be upgraded to the correct version of the maven plugin?  Much easier to have a simple rest endpoint for deployment and an actual deployment service that can easily be upgraded to use the latest containers.

 

  Yes this custom dev service overlaps with docker compose but that is what testcontainers are. Automated docker compose for app development as opposed to generic anything docker compose. 

I still think this is the domain of docker/kube.  What you're talking about here is cloning an environment and overriding one part of it.  Something that should really be up the stack considering most environments will not be pure Quarkus and will be a mix of node (for ui) and java and maybe even older Spring apps.  Automatically spinning up something like a database is great, because the general best practice is one db per microservice, but when you're talking about cloning the app services of your company it really belongs up the stack.

[Max Rydahl Andersen]

>> You do know we kinda already do deploy to openshift and you don’t need to
>> do anything, right ? :)
>>
>>
> I thought it was client based, via maven plugins and such?

yes - didn't realised you preferred some cluster side functionality - as in
what s2i, buildpack, etc. are doing ?

> Imagine if you
> had 50 microservice projects and they all need to be upgraded to the
> correct version of the maven plugin?

yes ? not following.

> Much easier to have a simple rest
> endpoint for deployment and an actual deployment service that can easily be
> upgraded to use the latest containers.

so upgrade to latest containers but not rebuild nor retest the app using
maven/gradle ?

>> Yes this custom dev service overlaps with docker compose but that is
>> what testcontainers are. Automated docker compose for app development as
>> opposed to generic anything docker compose.
>>
>>
> I still think this is the domain of docker/kube. What you're talking about
> here is cloning an environment and overriding one part of it. Something
> that should really be up the stack considering most environments will not
> be pure Quarkus and will be a mix of node (for ui) and java and maybe even
> older Spring apps. Automatically spinning up something like a database is
> great, because the general best practice is one db per microservice, but
> when you're talking about cloning the app services of your company it
> really belongs up the stack.

I'm not disagreeing that this also can be done in some other layers and for some
it is useful and Quarkus works fine there, especially for mixed deployment scenarios but
a) requires additional setup/installation
b) many just deploys lots of java/quarkus based services and really happy not having to deal with
kube nor docker setup - see https://www.youtube.com/watch?v=JpafbcOFIGI where 50 service
deployments are done in matter of minutes and using our ability to unify configuration.


/max
https://xam.dk/about

[Stuart Douglas]

On Sat, 2 Oct 2021 at 04:18, William Burke <bbu...@redhat.com> wrote:

Can't you do this kind of stuff with docker compose?

Yea, but there are some definite advantages to doing it this way:

- Integration with existing Dev Services (i.e. you can configure you new images to connect to services started by Quarkus)

- Dev/Test isolation (you automatically get a new container for tests that won't interfere with dev mode)

- It just works, even when running from the IDE

- No port conflicts, as ports are assigned randomly

- Potentially opens up additional options down the line (e.g. automatic remote dev connection to running applications, end to end continuous testing)

Basically this just has less friction than docker compose, and it is relatively simple to support.

Stuart

[Stuart Douglas]

On Sat, 2 Oct 2021 at 04:26, William Burke <bbu...@redhat.com> wrote:

On Fri, Oct 1, 2021 at 4:12 AM Stuart Douglas <sdou...@redhat.com> wrote:

Potentially if the other project is also a quarkus project we could also generate metadata based on that projects devservices info, and use it to auto connect stuff with no configuration (in a similar manner to what we already do with label based discovery).

I think this is the more interesting idea of Quarkus automatically publishing configuration points for auto wiring in a docker/kube environment.  Then somebody does not have to define the container and can just deploy the Quarkus app.  The idea I had awhile ago was a kube/openshift deployment service for quarkus that would allow you to take the container out of the equation and punt it so that "we" Red Hat could control the container and take one step out of the dev process.

In an ideal world with dev services + service bindings you would be able to write your application without ever really configuring anything, it would just be provided for you.

 

But, I'm pretty sure the other composition stuff you are doing already exists, specifically with Docker Compose.  And you can always define a set of services for Kube/Openshift too.  What you're doing seems a bit redundant.

You could also make the argument that we don't need Devservices because a developer can already just directly use docker, but Devservices is a lot simpler.

Stuart

[Thomas Qvarnstrom]

Very nice Stuart!

I wonder if we could take this one step further and if you have a multi-module maven project so that if you start quarkus:dev in a sub module the other modules get started as custom dev service? 

Cheers

Thomas

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2czT6MRAvcnaKhsxow0JSGyCtWS0t8QhnCQV-gPBGmbusQ%40mail.gmail.com.

[Max Rydahl Andersen]

That’s what my suggestion of being able to specify maven coordinates for dependent services was about.

Starting all other modules would be too aggressive so need something to pin down dependents.

/max

[Georgios Andrianakis]

I really like the idea.

"Standardizing" on containers for running dependent services is really elegant IMHO. Furthermore, given the fact that we make it really easy to build and deploy a container image, this should make the experience really good.

I am also wondering if we create and utilize container-image metadata (for services that are built with Quarkus obviously) in order to allow us to make good default decisions when launching them via the mechanism.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/018cf2a7-d809-41ba-9d9d-27533b1cee4f%40Spark.

[Max Rydahl Andersen]

There already are some labels used on containers for figuring out debug options we could look at but wonder what other “good default decisions” you had coming to mind ? 

Btw. I was assuming if we were launching quarkus apps as maven artifacts we would just do it “raw” without container layer in between. Wouldn’t that be simpler ?

/max

[Georgios Andrianakis]

On Mon, Oct 4, 2021 at 10:55 AM Max Rydahl Andersen <mand...@redhat.com> wrote:

There already are some labels used on containers for figuring out debug options we could look at but wonder what other “good default decisions” you had coming to mind ? 

I was wondering whether we could use the labels to decide how to launch a DB for this service for example. Also, the other way around, I was wondering if we could use the labels to somehow automatically configure the rest client to point of the application under development to point to this launched container.

Btw. I was assuming if we were launching quarkus apps as maven artifacts we would just do it “raw” without container layer in between. Wouldn’t that be simpler ?

For me, having the container image as the execution format makes things simpler - you don't need to care about the structure of the repository or anything like that.

[Sergey Beryozkin]

Hi,

I'd like to add that creating a Quarkus Dev UI, which the users like, and which is built around a specific container is something that would be hard to achieve without Dev Services launching the container.

Thanks, Sergey

 

Stuart

 

--

Bill Burke

Red Hat

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2czT6MRAvcnaKhsxow0JSGyCtWS0t8QhnCQV-gPBGmbusQ%40mail.gmail.com.

[Georgios Andrianakis]

I can't shake the feeling that there is some way waiting to be found that will allow us to just "point" to a container image and use it's metadata to configure the rest client automatically.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfU1F0W2%2B2MSROXNfFc7ipjkyw-i5jvP6ooOT%3DqM3sahLA%40mail.gmail.com.

[William Burke]

Dev services for dedicated/dependent/isloated DBsome other appliance makes a lot of sense, but this can get quite unwieldy very quickly if you start pulling in other microservices.  Think > 5 microservices running locally all with their own DBs.  Also think about cross-team microservices where you'd have to learn all about how to configure it and you'd be susceptible to changes you might not be aware of.

FYI: I'm just adding general skepticism to add feedback.  I've worked in an environment with many inter dependent microservices and it was very hard to impossible to clone the environment beyond a dedicated TEST bed.  And was impossible to do integration tests locally without pointing your microservice to the TEST environment.

[Georgios Andrianakis]

I completely agree it's a difficult challenge.

But the scope of it's impact and the fact that container images are now the standard way to launch services makes me think that there should be a good way forward that will be super useful.

[Stuart Douglas]

On Fri, 8 Oct 2021 at 06:54, William Burke <bbu...@redhat.com> wrote:

Dev services for dedicated/dependent/isloated DBsome other appliance makes a lot of sense, but this can get quite unwieldy very quickly if you start pulling in other microservices.  Think > 5 microservices running locally all with their own DBs.  Also think about cross-team microservices where you'd have to learn all about how to configure it and you'd be susceptible to changes you might not be aware of.

FYI: I'm just adding general skepticism to add feedback.  I've worked in an environment with many inter dependent microservices and it was very hard to impossible to clone the environment beyond a dedicated TEST bed.  And was impossible to do integration tests locally without pointing your microservice to the TEST environment.

I know what you mean, and longer term this is exactly the problem I think we should try and solve. Live reload, continuous testing and devservices are great, but they don't help at all if the only way to actually test your change is to package it up and send it to a staging environment.

Basically for low -> medium complexity environments I would like to make it as easy as possible to just have quarkus start a working development environment, which is where this comes in. I think we will be able to enhance it as time goes on, e.g. if all the services are quarkus based services we will potentially be able to generate metadata that makes it easy to wire everything together with minimal config (this already kinda works, services can use the container discovery stuff to automatically attach themselves to existing dev services).

For high complexity environments this is where remote-dev comes in, and I want to look at enhancing this as well (e.g. to support continuous remote testing). This still does not allow the use of Dev Services at the moment though, and is generally speaking still kinda clunky to actually get started with.

For both cases IMHO we don't have to deal with every use case under the sun, but we should have documented and tested 'happy paths', where we can basically say 'if you design and deploy your services like this you will still be able to use all the Developer Joy Quarkus features', no matter how many services you end up with.

Stuart

[William Burke]

On Thu, Oct 7, 2021 at 8:09 PM Stuart Douglas <sdou...@redhat.com> wrote:

On Fri, 8 Oct 2021 at 06:54, William Burke <bbu...@redhat.com> wrote:

Dev services for dedicated/dependent/isloated DBsome other appliance makes a lot of sense, but this can get quite unwieldy very quickly if you start pulling in other microservices.  Think > 5 microservices running locally all with their own DBs.  Also think about cross-team microservices where you'd have to learn all about how to configure it and you'd be susceptible to changes you might not be aware of.

FYI: I'm just adding general skepticism to add feedback.  I've worked in an environment with many inter dependent microservices and it was very hard to impossible to clone the environment beyond a dedicated TEST bed.  And was impossible to do integration tests locally without pointing your microservice to the TEST environment.

I know what you mean, and longer term this is exactly the problem I think we should try and solve. Live reload, continuous testing and devservices are great, but they don't help at all if the only way to actually test your change is to package it up and send it to a staging environment.

At least at my last company, you could test your microservice locally, but you had to point your local microservice to the TEST environment to do any comprehensive integration testing.  We also had an Octo (octopus.com) job trigger and run comprehensive integration tests when any service was deployed to the test environment.   We integrated with a lot of external third party microservices that ran outside of the company which could only be pointed to the TEST bed.  Finally, many tests required a lot of DB initialization in each of the external microservices these integration tests were run against.  It just wasn't feasible at all to run integration tests within a build. 

I think this is great demoware, I just think it will fall apart rather quickly in real deployments.  I'm curious to see how it fairs in the wild.

Remote dev/testing might be a better priority item as maybe it would fit better with existing dev cycles.  Something like that would have been highly useful in my last job.

FYI, I'm just giving feedback here. I'm wrong more often than I'm right, so take it for what its worth.

[Erin Schnabel]

On Thu, Oct 7, 2021 at 8:09 PM Stuart Douglas <sdou...@redhat.com> wrote:

On Fri, 8 Oct 2021 at 06:54, William Burke <bbu...@redhat.com> wrote:

Dev services for dedicated/dependent/isloated DBsome other appliance makes a lot of sense, but this can get quite unwieldy very quickly if you start pulling in other microservices.  Think > 5 microservices running locally all with their own DBs.  Also think about cross-team microservices where you'd have to learn all about how to configure it and you'd be susceptible to changes you might not be aware of.

FYI: I'm just adding general skepticism to add feedback.  I've worked in an environment with many inter dependent microservices and it was very hard to impossible to clone the environment beyond a dedicated TEST bed.  And was impossible to do integration tests locally without pointing your microservice to the TEST environment.

I know what you mean, and longer term this is exactly the problem I think we should try and solve. Live reload, continuous testing and devservices are great, but they don't help at all if the only way to actually test your change is to package it up and send it to a staging environment.

CONTRACT TESTING.

Can we please try to solve this by working through an easier-to-consume pact testing system than trying to stand up actual instances of other services? 

Using mocks for APIs that are protected against drift is the way to do this, and that's doable by a dev service (we can stand up a container that serves the pre-determined responses).

 

[Georgios Andrianakis]

On Fri, Oct 8, 2021, 19:57 Erin Schnabel <ebul...@redhat.com> wrote:

On Thu, Oct 7, 2021 at 8:09 PM Stuart Douglas <sdou...@redhat.com> wrote:

On Fri, 8 Oct 2021 at 06:54, William Burke <bbu...@redhat.com> wrote:

Dev services for dedicated/dependent/isloated DBsome other appliance makes a lot of sense, but this can get quite unwieldy very quickly if you start pulling in other microservices.  Think > 5 microservices running locally all with their own DBs.  Also think about cross-team microservices where you'd have to learn all about how to configure it and you'd be susceptible to changes you might not be aware of.

FYI: I'm just adding general skepticism to add feedback.  I've worked in an environment with many inter dependent microservices and it was very hard to impossible to clone the environment beyond a dedicated TEST bed.  And was impossible to do integration tests locally without pointing your microservice to the TEST environment.

I know what you mean, and longer term this is exactly the problem I think we should try and solve. Live reload, continuous testing and devservices are great, but they don't help at all if the only way to actually test your change is to package it up and send it to a staging environment.

CONTRACT TESTING.

Can we please try to solve this by working through an easier-to-consume pact testing system than trying to stand up actual instances of other services? 

I personally am not sold on contract testing - perhaps because I don't have enough experience with it.

I would much prefer if we could come up with a way to spin up the actual dependencies as containers.