This is another article based on recent Spring Office Hours sessions.
Spring Boot provides several effective ways to deliver applications, to production, efficiently.
There are many situations
where one of the
hyperscale cloud providers
is not an option, or the best choice.
I figured that going down this path would get easier with each provider. So far that has been true. I’m learning more about Terraform and getting more comfortable. I’m able to map the different concepts and building blocks a little easier with each rep.
As you would expect, nothing out of the ordinary when trying to setup an account. I couldn’t find a free tier or discount code, but I didn’t look very hard. Reach out to me if you know of something that I can share. Billing info is required.
Having a Terraform Provider is what I have set as the bare minimum for this exercise.
The StackPath Provider was surprising.
I consider myself a slightly above average Terraform user.
I have never experienced this as the
default behavior for a
Provider and I am impressed.
The provider only required three arguments for configuration. I decided to use the environment variable approach rather than passing in variables.
STACKPATH_STACK_ID STACKPATH_CLIENT_ID STACKPATH_CLIENT_SECRET
STACKPATH_STACK_ID I used the
stack slug from the
I created the
STACKPATH_CLIENT_SECRET from the
API ACCESS option of the dashboard.
When I ran the
terraform plan and
terraform apply they were so fast I thought it was broken.
I had guessed at the value to use for
STACKPATH_STACK_ID and figured that I must be doing something wrong.
Their platform API defaults to an
async behavior that doesn’t wait for object creation to be completed.
Instead, your actions complete, and you can run
terraform refresh to get the status of its creation.
I’ve used other
Providers that provide this as an option.
In this case, while I was learning and iterating frequently, it felt amazing.
To check on the status I used
terraform refresh and in this mode, it felt like the right way to do things.
Accessing the service felt snappy.
Cleaning up, was just as fast, so iterating through the struggles was relatively painless.
I spent a bunch of time not realizing that I needed the
stackpath_compute_network_policy to allow public traffic.
On this platform, ports are not exposed to the public by default.
Even though I struggled, this made me feel a little more secure.
Simply because I am forced to be specific about what I’m allowing.
Additionally, the container doesn’t have remote access enabled by default.
Deploying a VM that can run Docker is one thing.
container to a
platform is a different pattern.
While I was wondering through the documentation, I was very interested.
There are some very advanced and mature capabilities available.
This is clearly a platform that is designed to support short-lived and very dynamic workloads.
I only scratched the service here, but it worked, and it worked quickly.
There are some very interesting architectures that can be accomplished with
StackPath and I’m excited to go further.
I didn’t know what to expect on this journey.
I can say that
StackPath his raised the bar for my expectations going forward.
Take the repository for a spin and try it out for yourself. Let me know what you think.