Building and maintaining software and web services has become increasingly complex in the last few years. Integration work across service and cloud providers, delivering commodity features, and ensuring compliance with standards such as SOC II and ISO 27001 slows teams down with busy work and little leverage.
I think we can do better.
A lot of work spent on building internal tooling should ideally be covered by a stack that grows with your team, where resource management, preview deployments, granting access to and sharing secrets, and connecting and monitoring your services are all built-in.
To better understand the workloads and infrastructure teams are running, it is important to make it easy for teams to define their infrastructure in the same place. Infrastructure-as-Code (IaC) tools make it easy to configure cloud resources as code, but they’re incomplete.
First, when you’re dealing with multiple services, it becomes hard to keep track of the different layers of your infrastructure. This surfaces when your team starts to grow, as onboarding will involve a lot of meticulously-crafted architecture diagrams, which need to be kept in sync with your source of truth, as they merely represent a point-in-time snapshot of your infrastructure. If you manage your resources in one place, your infrastructure should be visualized using the same data and on multiple layers (configuration and communication via traffic, messages, etc.) granting immediate observability.
Second, writing infrastructure as code is great for engineers, but is far less accessible to other stakeholders, who may require access to parts of your stack, be it the customer support representative, business intelligence, or product management. In cross-functional teams, work depends on collaboration between roles. Keeping your entire stack locked in with engineering creates a dependency that neither your engineers nor other team members will enjoy.
Finally, the untapped potential of using the data from resource management is enormous. From displaying cost estimates across cloud providers to generating code or providing complete services with little additional effort, we can construct an infrastructure graph that spans every service and resource your team has deployed, giving you the insights you need for running your product.
There is a lot that can be improved for teams building software products and services, and I have the conviction that we are still underserving a large group of companies of all sizes that could move much faster and build game-changing products instead of getting bogged down by toil.
Introducing Anzu
I’m excited to announce that I’ve joined forces with my good friend Tim once again. We’ve been hard at work on building the first iteration of Anzu, a product focused on improving the velocity of teams building software and digital services.
We’re taking on the challenge of providing a cohesive solution to all the problems listed above, and more: We want teams to focus on their product and ship changes faster. We strive to reduce the lead time of deploying a change and prototyping new features to hours, instead of days or weeks.
All of this is made possible by building on top of a unified resource management platform. We’re making it easy to integrate with other tools and service providers, so teams can create tailored building blocks that are used to define organization-wide digital infrastructure components.
Using the visual editor, teams can quickly prototype their infrastructure, adding, combining, and reusing cloud resources from any available provider. Other ways of interacting with the resource management layer will be added in the near future, including public APIs and a type-safe SDK to enable automated and Git-based workflows.
After configuring the resources you want to run, simply open a deploy request. Anzu computes the necessary changes using a deployment plan, which will be executed once the deploy request is approved. You can collaborate with your team, adding feedback to deploy requests and making changes until you’re ready to go, Anzu takes care of the rest.
Resources are defined on virtual branches to help teams make changes independently of one another, so it’s easy to try out a new idea or feature prototype while production can be deployed. When you want a feature to reach the main branch, simply sync it.
When deploying, you select one of your existing environments as the deployment target. You can create new environments anytime, so on-demand preview environments are built-in and available for everyone. Just create a new preview environment for every pull request and update the deployed code for every pushed commit, that’s it.
Anzu uses the data on your deployed cloud resources to provide a set of tightly-integrated tools, increasing team velocity. An example of this is the infrastructure map, a comprehensive overview of all deployed cloud resources. This can be used for documentation, onboarding, and evolving your architecture over time, keeping you in the loop at every step of the product lifecycle.
With Anzu, we’re setting out on making the process of building software and services faster, simpler, and most importantly, more enjoyable. These are still early days in the journey of getting there, so if your team experienced some of the problems I outlined earlier, I’d love to show you how Anzu can improve your engineering processes and make your team move faster, happier. Head over to the landing page or get in touch via mail and I’ll get back for a demo!
We’re working hard on making the first iteration of Anzu available for everyone in the coming weeks, so stay tuned for further updates on this blog.
Background
I spent the last six years building and scaling web applications and services. Bootstrapping new products often involved the same manual work, slowing down the process of building considerably. I often wished that tooling would just work, that I could configure my services, generate whatever I didn’t want to work on, write and push my code, and be done with it. Instead, I often spent hours wrestling with some CI setup, configuring environments, and writing the same boilerplate code.
Working at Hygraph showed me other aspects and problems: Growing the team meant that we had to improve our processes, including both workflows (building an in-house solution for preview environments, collaborating on architectural decisions, etc.) and compliance (setting up approval workflows, locking down the infrastructure, etc.). A lot of the challenges that came up were not sufficiently solved by other tools, so we had to spend time on building in-house alternatives that better solved our needs.