The IaC Weight on DevOps’ Shoulders

This is the complete product tour & demo of the envzero platform as presented originally on the SweetOps DevOps "Office Hours" (2020-12-16).

Transcript

env0, unlike Hashicorp, are not advocates of Terraform. We acknowledge that Terraform is now the de-facto standard for Infrastructure-as-Code, but we're taking a multi-framework approach.

We just added support for Terragrunt in parallel to Terraform and we plan next year to add a few more icons here—Pulumi, CloudFormation, or others—but all in all we aim to support our customers in any technology that they prefer.

I want to explain env0, and the concept in envzero is that you have two types of users: you have the admins (the platform team, the DevOps team), and you have the others—mainly the developers but anybody who needs to update and provision cloud resources.

And envzero has a hierarchy of a few entities. We have the global organization, and then we have the projects. Each project is a logical entity that combines users, git repo, permissions, cloud accounts, and policies in one entity called the “project." And we see for our customers, usually that they have different projects for different types of usages in their cloud accounts. So, we usually see a project for production, a project for dev staging environments. And I think we put a lot of focus on this DNA, which is the on-demand, ephemeral developer pull request environment. So, let's start looking at those. 

So each project, even if it's for production or for on-demand environments, has variables that basically connect you to the cloud account and any other settings that you want. Those are sensitive and hidden. Then, the admin can define who can do what with which privileges. 

So, we have the “viewer” for the CFO or product managers that can look at cloud resources and their cost. “planner”—it’s for the approval flow; A developer in production can change some variable or value, but another person or colleague needs to approve it. So, that's the deployer that can actually deploy cloud resources. So, DevOps in production or developers in production are “developers." 

An “admin” is the group manager that can decide who can do what. And what is the “what?" The “what” is a catalog of a Terragrunt or Terraform based Git repos that already exist in the source control of the customer. But in addition to Terraform or Terragrunt, we have a unique concept of custom flow. 

If you add `env0.yaml` to your Git repo, you can do whatever you want, whenever you want. And when I mean “whenever," it's before or after the terraform.init plan apply destroys success arrow and some other great places. We see a lot of Chef, Puppet, Ansible, kubectl, AWS and other CLIs; Bash, Python, PowerShell for the Windows-oriented that eventually the user can create a new environment from scratch and later on update those environments. So, that's how you create a new environment and you can see the policies that we have here.

So, very unique for the on-demand environments is the TTL policy because it's easy to request resources, but usually those developers or QA or sales engineers for demos need to eventually destroy those resources. So we have the concept of default and maximum time-to-live policies.

Okay, so you can have the flexibility of self-service for the developers, and also give them the flexibility to extend—it but only up to a maximum. And you cannot create more than the maximum unless you are an admin. So that's one thing about the TTL policies.

And the other thing is our hierarchy of variables that we found very useful. We have four layers of places to put variables. We have global, for the organization, per Git repo template, per project, and specific for the environment. And we can simplify if needed with a drop-down list. The options allow for various values for the user. We have the option to deploy all the way or to stop after the plan. So, let's just click here that we want to apply all the way to the actual deployment.

So while this is being created, let's look at an already existing environment and understand how we manage existing environments.

Okay so this is an existing environment. The person who wrote the template can define what are the outputs which are exposed to the users in order to access the resources. But we also automatically provide interesting information—we passed the state so we understand all of the resources that were recreated, the last logs, the recent plugs, all of the deployment history, the variables, values that were used, the number of resources in that workspace, and something very unique for env0—our cost. We do actual “cost over time” and add tags.

If you look at our deployments, there is a step that’s optional. But if you decide to do so, it will execute Terratag. Terratag is an open source project (you can check it in our GitHub) to inject tags exclusively in Terraform code. We support the main three providers—AWS, Azure, and Google—so that injects those tags. We understand which tags in those providers are taggable, and which are not taggable. 

So you don't just have the orange line, you also have the vertical green lines that correlate a deployment to the cost. So, you can isolate and understand that this was a bad deployment that increased the cost. Or, that this was a neutral deployment, or this was a great deployment that reduced the cost. 

You can easily understand from each deployment what happened and how they affected that cost, because if you look at the plan, you will see that there is a good reason why this affected the cost. Because the results here change from from small to medium.

In addition to our TTL policy, we have scheduling. So if you need to destroy those in nights and weekends to reduce cost, perhaps start those automatically on Monday mornings, you can do that as well.

So now, let's talk about how you update an environment. To update an environment you click “redeploy”—everything you see here is using API or CLI as well. You can just get the latest code and change the code that it's based on. You can change the variable values. So you can redeploy automatically on push. You see the plans on pull request in your source control like GitHub, and you can filter it depending on if you have a monorepo or not monorepo and some folders, so you can understand and tell us if you want that for every change/every Git pushed to that repo, or just on the relevant folder. So that’s how you update an existing environment.

A few more interesting things…that's an environment that we created four minutes ago and it will be destroyed automatically in 12 hours. Before it's destroyed, the user will get a notification (we have email support, Slack support, and soon we're going to have Microsoft Teams support). They're going to get a notification in advance: “Your environment is going to be destroyed, you need an extension,” and the user can extend it if they want. So that's a very useful use case for developers to have.

So now the approval flow—if you have something waiting for approval, you get a notification for it that’s also presented in a dedicated way. 

With detention environments—if you look at those environments you will see that you need to make a decision. The deployer can make a decision whether or not to deploy it—”yes” or “no”—and if you have several pending we manage that in a queue.

I will not go over policy as code, but all in all we are integrated with OPA so that's our way to do policy as code. And you know open standard non-vendor locking, you can take your OPA code later on if you don't want to use envzero and use your Jenkins or Scalr or Spacelift.

A few more things: We want to add more capabilities to the managed self service. We want to add limits on what our users can do now that we have environment limits. So you can set no more than three environments per user per project.

We want to add budget limits—that's in our roadmap. Because we have the actual cost, so we can prevent deployments if they exceed $200 per month per user, and $500 per month per team, and $1,000 per project.

I'm pretty much done here. I want to add that we support SAML, that we support SAML by the way, free or not free, the regular paid tiers. So SMBs you can use our SAML. You can use our SOC2 as well and we have unlimited concurrent runs on all of our tiers, including on our free tier.

So that’s our story. One last thing, if you liked it, please follow us on Twitter at @envzero and my personal Twitter handle, @DevOpsOhad.

Thank you very much!

"Using env0, we now can provide an infrastructure to our developers, allowing us to focus on what’s important."

Imri Zvik

Director of Architecture

‍

Background

ActiveFence supports online platforms to protect against harm and malicious behavior. In today’s digital age, it’s a complex feat requiring a lot of tooling across many teams.

As ActiveFence has grown, their reliance on management tools has also increased. They traditionally used basic git workflows, with code living in various places to get things done. ActiveFence chose envzero because of its ease of use, logging capabilities and the fact they would no longer need to “manage their management solution”.

The Challenge

Prior to using env0, ActiveFence developers would clone code to their laptop, make changes, commit it and then try to integrate it into their overall solution. This workflow led to many complications and, in the words of ActiveFence, it was hard to keep things “calibrated”.

Another challenge ActiveFence faced was code drift. As a growing company that was moving fast, high-quality documentation of the infrastructure suffered.

Finally, ActiveFence had several workflows and pipelines, but it was tough to connect them together and to reuse pieces from one workflow in another. Code reuse was also harder because of the underlying permissions on their infrastructure.

The Solution

ActiveFence chose envzero as their centralized IaC management platform. They use envzero for centralized and simplified code management, building, drift detection, and logging capabilities.

The Impact

envzero not only allows ActiveFence to build centrally, but it shows what changes were applied, when, and also provides extensive logging to better help with troubleshooting.

In addition, with env0, the team now has a central hub for all IaC needs, giving everyone visibility into what they apply, where and when. This centralization also removed the need to build locally, reducing collisions with other builds caused by simultaneous Git pushes.

Finally, with code centrally managed, by using env0, ActiveFence can reuse one object in many projects without worrying about collisions or permissions.

Reuse, coupled with pretty plan/graphical diff, makes it super easy for ActiveFence developers to identify and reduce complications in their environment.

What’s Next?

Another big feature ActiveFence sought was the ability for developers to use a self-service portal. With the envzero access control system and templates, this is in the cards as an achievable future project.

As ActiveFence continues to fine-tune their use of env0, their staff say they have only scratched the surface of all the capabilities it can offer. Each change they make saves time, and allows them to get their product out quicker, helping with the mission to support online platforms in protecting against harm and malicious behavior.

‍