Sproutward is a boutique marketing firm that focuses on clients in the midst of a digital transformation. Sproutward’s early successes hinged on their commitment to building the most scalable and secure application ecosystem possible. Driven by the requirements of enterprise customers with robust data security and disaster recovery (DR) requirements, Sproutward built a multi-tenant application and deployed it on Google Cloud– an architecture that would continue to serve as the template for all subsequent customer implementations.
Right out of the gate, Sproutward’s application and supporting infrastructure featured a high degree of complexity. Its many configurations and moving parts far exceeded the capacity of any person or team of people to consistently and reliably manage through manual effort, so automation became a critical component of their success. This, coupled with other requirements like DR, led the team to rely on Terraform to ease the replication of complex infrastructure across multiple dimensions.
However, the solution to one problem often introduces other problems, and Sproutward soon realized that what works well for an engineering team already versed in the intricacies of Terraform works less well for developers whose primary focus is code and application architecture. Meanwhile, Sproutward’s DevOps team didn’t want to operate as a constraint on the speed with which non-technical teams like Customer Onboarding can respond to customer requests.
The situation became especially urgent as the organization sought a low-effort solution to offering “free trials” at volume. The designed solution: Customer Success should be able to fill out a web form with all customer requirements to trigger the provisioning of a new tenant and all supporting infrastructure. To handle this self-service-style infrastructure provisioning with Terraform, Sproutward needed to wrap it with API endpoints that they could call with the submission of the onboarding web form. This was the genesis of their self-service platform – a series of microservices built on a Kubernetes (k8s) cluster.
Architect fit nicely in the gap between developers and Terraform. Sproutward liked that Architect facilitated a simplified deployment process using a common CLI toolset. With Architect, the same commands a developer might use to develop locally also could be used to deploy to a preview environment with no need to understand anything about Terraform. With Architect, developers can
- Bring up services and develop them locally
- Run and operate quasi-production workloads locally for appropriate use-cases
- Deploy to staging and production namespaces on the Kubernetes cluster
Furthermore, whereas other tools are highly opinionated, Architect is flexible enough to fit neatly in a diverse technology ecosystem, allowing Sproutward the flexibility to deploy the best solution for every job across the organization and to evolve those solutions as needs change. For example, Sproutward can register an Anthos cluster with Architect to support the few microservices that cannot operate as traditional Kubernetes pods and need fan-out/fan-in and scale-to-zero capability. Thus Architect does not prevent using “Cloud Run for Anthos” alongside Architect’s own deployment capabilities.
While Architect utilizes gRPC calls between pods, Sproutward can use pub/sub as a communications bus for all services all the way down to local dev using “pull” subscriptions, even including those deployed out-of-band onto Cloud Run for Anthos. And finally, while Architect provides native secrets management, Sproutward was able to utilize a third-party secrets manager.
As Architect continues to evolve, Sproutward looks forward to building on early successes, allowing their DevOps team to focus on finding new opportunities to bring value and impact the organization in ways that directly benefit their customers.