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.
Previously, I looked at Kamatera. This time, I’m going to use StackPath.
I did the work during a live stream, so you can see exactly how easy and exciting this was.
Initial Thoughts Link to heading
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.
Getting an account Link to heading
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.
Stackpath Terraform Provider Link to heading
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
For the STACKPATH_STACK_ID I used the stack slug from the DASHBOARD.
I created the STACKPATH_CLIENT_ID and 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.
Nope.
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.
Struggle Link to heading
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.
Differences Link to heading
Deploying a VM that can run Docker is one thing.
Deploying a 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.
Summary Link to heading
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.
Your Turn Link to heading
Take the repository for a spin and try it out for yourself. Let me know what you think.