Pulumi Blog: Matty Stratton

Introducing the Puluminaries

Matty Stratton — Tue, 03 May 2022 10:04:47 -0500

Pulumi is more than a way to build, deploy, and manage your infrastructure and cloud applications. Pulumi is also a strong and vibrant community. We are very excited to announce and showcase our new program of community champions, the Puluminaries!

The Puluminaries program was created to recognize members of the Pulumi community who are experts and leaders in the field of programming and infrastructure, but also who give back to the community to make it grow! They help others get started, give feedback to make Pulumi’s roadmap even better, and educate people through content or public speaking. The program is open to all members of the community, and we welcome anyone to join the program.

While the Puluminaries themselves have been active in the community for quite some time, we officially launched the program at PulumiUP in 2022, and it is our pleasure to introduce the first cohort of members to the program!

Meet The Puluminaries!

Engin Diri

Engin’s excitement for Pulumi is not possible to be measured using current science. He will always share his thoughts on new developments in the Pulumi project, as well as join in for fun and discussion in various PulumiVision livestreams!

Joshua Studt

Joshua is a longtime member of the Pulumi community, and he contributed to the implementation of Automation API for C#.

Kat Morgan

Kat has been a helpful member of the Pulumi community - not only providing feedback on real-world use of Pulumi, but also sharing her knowledge with workshops and webinars

Komal Ali

In addition to being a Puluminary, Komal is also a Pulumni, having spent time working to make Pulumi a better tool for developers - they were ever-present in making our Python SDK better and creating the Automation API!

Paul Hicks

Paul seems to have an answer to everything. He is ever-present in the Pulumi Community, sharing his knowledge to folks who are just getting started, but also bringing to bear his real-world expertise in complex Pulumi implementations. Chances are, if you see a great answer to a question in Pulumi Community Slack, it came from Paul.

Ringo De Smet

Ringo is one of the founding board members of the Pulumiverse - a place to interact and collaborate on Pulumi-based libraries, projects, and educational materials. Ringo (along with fellow Puluminary Simen A. W. Olsen) have brought their vision for expanding the Pulumi community to life with the creating of this community-operated space! Ringo also created the Pulumi Resource Type for Concourse, and is ever-present in every community he is a part of, not just Pulumi’s!

Rizel Scarlett

Rizel brings her remarkable talent for guidance and teaching to the Pulumi community. She has participated in many Pulumi events, including Cloud Engineering Summit, and appearing on the PulumiVision livestream.

Simen A. W. Olsen

Another one of the founding board members of the Pulumiverse, Simen has a great passion for technology communities, but especially for the Pulumi community. Simen was instrumental on the Pulumi GitHub Action rewrite - designing and rearchitecting it in his free time.

Do you know someone who would make a great Puluminary? Let us know! You can email us at da@pulumi.com with your nominations!

PulumiUP Workshop Series

Matty Stratton — Tue, 03 May 2022 08:46:08 -0500

At Pulumi, we’re incredibly fortunate to have over 70 integration partners in our ecosystem – helping shared end-users to build, deploy and manage practically any cloud service they can imagine. Our most popular content often includes workshops that show end-users how to use these powerful integrations. This year for PulumiUP, we’re excited to announce that we’ve teamed up with a number of partners to deliver a workshop track that provides hands-on labs and demonstrations for a variety of platforms and scenarios.

Introduction to Infrastructure as Code

Thursday, May 5th at 2:30 PM PDT

We’ll explain the basics of IaC by exploring how to use Pulumi to build, configure and deploy a real-life, modern application using Docker.

From Zero to Production in Kubernetes

Tuesday, May 10th at 9:00 AM PDT

Our friends from NGINX will show you how to leverage the power of Python with Pulumi to define and manage your Kubernetes deployments and build powerful abstractions that make getting to production easier than ever before. You’ll learn about the new open-source Modern Application Reference Architecture (MARA) that helps you quickly deploy an app platform that includes Amazon EKS, NGINX Kubernetes ingress controller, logstore, logagent, cert-manager, Prometheus, Grafana, and more.

Kubecrash

Tuesday, May 17th at 9:00 AM PDT

Join Pulumi and the maintainers of Linkerd, cert-manager, and other projects for a series of crash courses about Kubernetes and cloud-native, open source technologies.

Getting Started with Azure and Infrastructure as Code

Wednesday, June 1st at 9:00 AM PDT

In this workshop, you will use Pulumi’s Azure Native Provider, built directly from the Azure API, to provision infrastructure with Pulumi’s Typescript SDK. Join Microsoft Sr. Cloud Advocate, April Edwards, and Pulumi Developer Advocate Matty Stratton for this introduction to IaC.

End-To-End Infrastructure, Apps, and Auth with Auth0

Tuesday, June 7th at 4:00 PM PDT

In this live-coding session, Pulumi and Auth0 will walk through the process of building a three-tier web app: a single-page app built with React, a back end consisting of a REST API managed with Express and MongoDB. Finally, we’ll show you how to enable authentication to restrict access to your app.

AWS Immersion Day: Hands-On Infrastructure as Code

Tuesday, June 14th at 9:00 AM PDT

Pulumi and friends from VirtusLab and AWS have planned an interactive session to introduce IaC concepts using familiar programming languages to provision modern cloud infrastructure. This session will focus on new Pulumi capabilities.

GitOps with GitHub Actions and the Pulumi Operator

Tuesday, June 21st at 9:00 AM PDT

Combining GitHub Actions with the Pulumi Kubernetes Operator helps you to implement powerful GitOps workflows and automation for both your infrastructure and workloads. We’ve partnered with the GitHub team to deliver step-by-step labs to help you to get started with GitOps.

CI/CD Pipelines for Kubernetes Apps with Pulumi & Codefresh

Wednesday, June 22nd at 9:30 AM PDT

The Codefresh team will help you to learn the basics of CI/CD and how to declare cloud resources and set up a simple pipeline for Kubernetes deployments using your favorite programming languages with Pulumi and Codefresh.

Deploying Microservices with AWS Lambda and Pulumi

Tuesday, June 28, 12:00 PM PDT

In this workshop, we’ll examine how Pulumi can rapidly accelerate provisioning of cloud infrastructure. We’ll focus on AWS Lambda and build an example set of microservices utilizing AWS’s newest Lambda features. Matty Stratton (Pulumi) and Marina Novikova (AWS) will guide you through the process of provisioning a set of example Lambda resources in AWS.

Getting Started with Infrastructure as Code on Oracle Cloud

Thursday, July 14th at 9:00 AM PDT Register

Now that we have a brand new integration with Oracle Cloud Infrastructure (OCI) the team is preparing a new workshop to help you to get the most out of the new provider. Laura Santamaria (Pulumi) and Gaurav Jain (Oracle) will show you how to define, deploy and manage OCI resources using your favorite programming languages.

Getting started with Infrastructure as Code on DigitalOcean

Thursday, July 28th at 8:00 AM PDT Register

In this hands-on workshop, Matty Stratton (Pulumi) and Chris Sevilleaja (DigitalOcean) will show you how to stand up basic services using Infrastructure as Code with hands-on labs using JavaScript/TypeScript.

Organizational Patterns: A Developer Portal

Matty Stratton — Thu, 30 Dec 2021 11:00:39 -0600

Using Pulumi is more than just writing code and components. In addition to common software development practices, there are also a number of success patterns related to how your company or team builds and deploys Pulumi programs to successfully build, deploy, and manage your infrastructure and applications. In this continuation of a series, I will explore one of these patterns - using the Pulumi Automation API to create a developer portal.

It is becoming more and more common to consider building out centralized web-based “portals” for developers (and other team members) to provision the infrastructure that their services and applications require. In many ways, the pattern of a developer portal takes portions of both the Single Infra Repo and Automation Team patterns covered in previous posts. The difference is that the developer portal is a single, centralized web application that can be used by multiple teams and organizations to provision infrastructure and applications, rather than writing the Pulumi programs themselves.

Depending upon the needs of the various teams, the developer portal could include options to deploy virtual machines into the cloud of their choice (or the organization’s standard cloud; perhaps the choice isn’t…a choice!), to provision cloud resources such as virtual networks, security groups, database instances, or even deployments to a kubernetes cluster.

Generally speaking, the developer portal is created and maintained by a central platform team. This is the team who knows the success patterns/standards that are employed by the organization, and can implement these patterns in the developer portal. The platform team is also responsible for maintaining the infrastructure that the developer portal requires.

One of the great advantages of providing a single portal for provisioning these resources is that all the “other stuff” that is often required (besides the resources from the hyperscaler) can be handled by the developer portal. For example, if the portal is used to provision a virtual machine, the code behind it can register the virtual machine with the company’s infrastructure management system.

A great example of what is possible in a portal can be seen with Komal Ali’s example, the Self Service Infrastructure Platyform. This is example code only, but it shows some of the capabilities of a developer portal.

In the example, the web portal is created using a combination of Python, Flask and Jinja templates (along with the Pulumi Automation API) to provide push-button access to deploy cloud resources according to the standards and patterns of the organization. The code snippets below illustrate some of the concepts (this code is not meant to be run, but rather to illustrate the concepts - the full example code can be found at github.com/komalali/self-service-platyform).

from flask import (Blueprint, current_app, request, flash,
 redirect, url_for, render_template)

import pulumi
import pulumi_aws as aws
import pulumi.automation as auto
import os
from pathlib import Path

bp = Blueprint("virtual_machines", __name__, url_prefix="/vms")
instance_types = ['c5.xlarge', 'p2.xlarge', 'p3.2xlarge']

In the initial snippet above, we are setting up what we need for the Flask application, but the key items to make note of are including the pulumi_aws and pulumi.automation packages, which will be used for the cloud specific resources and automation.


def create_pulumi_program(keydata: str, instance_type=str):
 ami = aws.ec2.get_ami(most_recent=True,
 owners=["amazon"],
 filters=[aws.GetAmiFilterArgs(name="name", values=["*amzn2-ami-minimal-hvm*"])])

 group = aws.ec2.SecurityGroup('web-secgrp',
 description='Enable SSH access',
 ingress=[aws.ec2.SecurityGroupIngressArgs(
 protocol='tcp',
 from_port=22,
 to_port=22,
 cidr_blocks=['0.0.0.0/0'],
 )])

Continuing on, we define the Pulumi program, and set up some of the standard settings that we consider our defaults and that are not selectable by the user.


 server = aws.ec2.Instance('dlami-server',
 instance_type=instance_type,
 vpc_security_group_ids=[group.id],
 key_name=keypair.id,
 ami=ami.id)

 pulumi.export('public_dns', server.public_dns)

This final snippet is what creates the actual instance, and it exports the public DNS of the instance so that it can be accessed by the user and presented in the portal.

Conclusion

This pattern has been implemented and deployed at many larger enterprises, where the platform team has the resources to dedicate to managing the portal as an actual product. This is a key part to remember - the developer portal is a product whose consumers are the developers and other teams in the organization, and it needs to be managed as such!

Don’t forget to check out the previous two posts in this series, Organizational Patterns - A Single Infra Repo and Organizational Patterns - An Automation Team".

Organizational Patterns: An Automation Team

Matty Stratton — Wed, 22 Dec 2021 11:49:08 -0600

I want to approach this pattern with a bit of caution - there are patterns and anti-patterns related to having a single central team focused on automation.

The anti-pattern is to have an “automation team” within your organization who is tasked with creating all infrastructure as code for the entire organization. This is a common pattern, but it is generally rife with issues.

Understanding how to build and deploy a service or application requires a certain amount of domain knowledge of that service. If you have a single set of people across your entire company who need to write Pulumi programs for each and every application or service, you are now expecting that small group to not only be experts in Pulumi, but also every bit of infrastructure and software applications (both third party and created internally) across your organization.

A more successful pattern is to have the automation team act as enablers and providers for the other groups within the company. This is a team of subject matter experts in using Pulumi, and not only do they have the knowledge to build and deploy infrastructure, but they are familiar with various patterns and good practices for how to build and deploy infrastructure.

There are different mechanisms for how this automation team can enable others. One way is to embed them temporarily within a product team to work alongside them to build their automation. Then, when the product team is done, the automation team member can go and help another squad.

Depending upon the size and skills of the company and this group, they may also be responsible for creating training materials for the other groups. These are usually based upon existing Pulumi training materials, but customized for the specific needs and culture of the company.

Reusable components

This central automation team also often provides reusable components that might be shared across multiple development teams. This helps the individual teams to not have to “reinvent the wheel” and to bring in these components for their own particular needs.

As a simple example, a component could be created (and published as a library to be consumed by product teams) that defines a Kubernetes deployment.

import * as deploy from "@mycorp/deploy";

const kuard = new deploy.Deployment("kuard", {
 image: "gcr.io/kuard-project/kuard:latest",
 replicas: 1,
});

What’s happened here in our (incomplete!) example is that the published package only exposes the parts that the team needs to change; the rest is provided by the automation team.

The application team don’t need to duplicate values (such as ports) because the abstractions cater for them. The application team also didn’t need to apply any metadata, health checks, and environment variables because it can be inferred through convention, increasing velocity across the organization. When values are provided by the application team, they override convention and they can still iterate and experiment, providing feedback to the automation team.

Final tips

One of the more important recommendations for this pattern is to avoid trying to create a “mandate” for all teams for adoption. The automation team provides capabilities, such as templated CI/CD pipelines, reusable components, and training materials, but it is still up to the individual teams to decide how to use them.

Conclusion

This is a pattern that works well at a larger organization, where it would be beyond the scope of a single group to be able to wrap their understanding around hundreds of services. However, it is a pattern that can be applied to smaller organizations as well!

Watch for the next post in this series, where we will dig into some other patterns! Or revisit the first post, Organizational Patterns - A Single Infra Repo.

Organizational Patterns: A Single Infra Repo

Matty Stratton — Fri, 17 Dec 2021 05:46:04 -0600

Using Pulumi is more than just writing code and components. In addition to common software development practices, there are also a number of success patterns related to how your company or team builds and deploys Pulumi programs to successfully build, deploy, and manage your infrastructure and applications. In this first post of a series, I will explore one of these patterns - the centralized platform infrastructure repository.

An emergent organizational pattern these days is that of a centralized “platform” team, which has various product and service teams (or squads) as internal customers. In this approach, the platform team takes responsibility for the tooling and infrastructure - if it’s not directly product related, it usually falls under the responsibility of the platform team. The platform team provides functionality and platforms to be consumed by the product teams.

For many of the examples I’ll be using to illustrate this pattern, I refer to a conversation I had recently with Jacob Foard, who is the Tech Lead for the Platform Team at GreenPark Sports. This pattern is used at GreenPark Sports, and he was very clear about the benefits of the pattern.

One of the key concepts to keep in mind is that when providing a platform, it is made up of more than just the compute and other resources provided by AWS, GCP, Azure, or even your own Kubernetes implementations. The platform also includes the infrastructure that is shared between the various teams, such as monitoring and observability tooling, version control/pipeline services, as well as secret and key management.

In this pattern, your main infrastructure repository is made up of directories for each product/service that your teams use, in addition to directories for each higher level shared service. Each of these directories is itself a Pulumi program. So it would look something like this:

├── bluth-apps
│   ├── apps
│   │   ├── apps.go
│   │   ├── bananastand.go
│   │   ├── suddenvalley.go
│   ├── main.go
│   ├── Pulumi.dev.yaml
│   └── Pulumi.prod.yaml
├── datadog
│   ├── main.go
│   └── Pulumi.prod.yaml
├── github
│   ├── main.go
│   └── Pulumi.prod.yaml
├── pkg
│   ├── datadog
│   ├── pagerduty
│   └── vault
└── .etc

In the above (fictional, but inspired by the GreenPark Sports pattern) example, the Bluth Company has two main services that are used in all of its environments (“Banana Stand” and “Sudden Valley”). The main apps.go file is the entry point that simply calls functions from each of the various apps to “set up” those apps, as well as the common infrastructure that an environment might require (networks, storage, etc). Note that the way you structure your code is up to you, and likely will vary depending upon the runtime for your particular Pulumi program, but this is the general idea.

Similarly, the github and datadog directories are Pulumi programs that are responsible for the “core” infrastructure for those services (perhaps creating roles, etc). The pkg directory is a directory that contains packages that are used by the other programs to implement that infrastructure. Again, the pkg convention is used by Go, but other runtimes will have a similar approach.

Examples

These examples are not complete runnable code, but used to illustrate the pattern. While these examples are using Go, they are written in a way that is compatible with any language that supports the Pulumi language.

main.go

package main

import (
 "github.com/bluthcompany/infra/bluth-apps/apps"
 "github.com/bluthcompany/infra/pkg/datadog"
 "github.com/bluthcompany/infra/pkg/github"
 "github.com/pulumi/pulumi/sdk/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Create the apps.
 apps.SetupApps(ctx, bananastand, suddenvalley)

 // Create the infrastructure.
 datadog.CreateInfrastructure(ctx)
 github.CreateInfrastructure(ctx)

 return nil
 })
}

apps.go

package apps
import (
 "github.com/pulumi/pulumi/sdk/go/pulumi"
)

func SetupApps(
 ctx *pulumi.Context,

 setupBananaStand(ctx)
 setupSuddenValley(ctx)

)

bananastand.go

package apps
// imports, etc
func setupBananaStand(ctx *pulumi.Context) {
 // Create the banana stand.
}

Setting up a new service in the platform repository

If a service/product team has a new service they want infrastructure for, they simply add a new myapp.go file to the apps directory for their service, and add it to the apps.go file to make sure it is called. This is then submitted as a pull request for the platform team to review.

One important part of this pattern is that the platform team does not want to be a “blocker” for the product and service teams. It’s key to make sure that you have more than one person able to review and merge these pull requests, and to add sufficient testing into your CI/CD pipeline for this infrastructure repository.

Variations on this pattern

In the fictional Bluth example, there is one Pulumi program that is used regardless of environment, and the different configurations are handled by the use of stacks. However, there are situations where you might have complex enough differences between your environments where the amount of conditionals you require in your code to handle this would make for very challenging maintenance and understanding of the code! This is the case with GreenPark Sports, so in their implementation, instead of a single bluth-apps directory at the root of the repo, you would instead have bluth-prod, bluth-dev, etc.

This approach does generate duplication of code, and it can provide challenges at scale, but it is up to you and your teams to determine the tradeoffs of the branching/conditional logic vs separate programs.

Conclusion

This pattern works well depending upon the makeup of your teams and services. It is a pattern that facilitates collaboration between teams and focuses on having a central platform team that enables product teams, rather than getting in their way.

Watch for the next posts in this series, where we will dig into some other patterns as well!

Preview of the Manage Track at Cloud Engineering Summit 2021

Matty Stratton — Mon, 13 Sep 2021 08:00:00 -0500

The Cloud Engineering Summit 2021 is coming up fast, and the speakers are out! To get you ready to attend, let’s take a look at the sessions for the Manage track.

The Cloud Engineering Summit’s three tracks are built around three concepts: Build, Manage, and Deploy. I’m Matt Stratton, and I’m your charismatic track chair for Manage. For us, that means managing cloud applications and infrastructure with Policy as Code, visibility, and access controls. For example, managing infrastructure with policies that detect configuration drift, enforce best practices, and even prevent compliance violations before deployment. It means building visibility across your cloud infrastructure so that you always understand its current and past states, including detailed audit history. Finally, you ensure the right guardrails and controls are set in place so that distributed teams can securely develop.

Without further ado, let’s take a look at each of the talks I’ve selected for you!

Overwhelmed by permissions and authorization? Me, too. Fortunately, we have Joy Ebertz presenting Authorization: Ensuring Only Ada Can Access Her Files. Joy is going to cover the various authorization models available to us, with use-cases for each. Authorization can be overwhelming if you don’t have a good grasp of the options available to your organization and an understanding of what works when, so I’m excited for this one.

Taking a higher-level view, Quintessence Anx will be presenting DevSecOps and Secure Incident Response. The introduction of security to the DevOps equation means some shifts in the way we think about the software development lifecycle, and Quintessence is uniquely qualified to talk about why that’s true. A look inside PagerDuty’s 14 Step Secure Incident Response process promises to be interesting for anyone involved in either development or operations.

I don’t think we have the ability to predict the future, but J. Paul Reed wonders if we can develop the ability to forecast incidents just as we have learned to have staggeringly accurate weather short-term forecasts. With Forecasting the Future: Creating a Radar for Risk, Paul will share with us how Netflix uses Risk Radar to collect and make sense of risk in their sociotechnical systems.

When we talk about infrastructure as code, there’s more to it than just the code! Fariba Khan and Stephen Van Gordon will take us on a journey with Lifecycle of a Pulumi Program to share how they leverage a custom state backend with SSO, RBAC, and programmatically configurable pipelines powered by CI/CD tooling and the Pulumi Automation API to drive IaC at their organization.

Snowflake’s Charles Xu will be here to talk about Day-two Operation of Multi-cloud Kubernetes and Vault, a very cool overview of Snowflake’s Kubernetes infrastructure and how Pulumi helps, from blue-green updates, to managing Hashicorp Vault, to rotating TLS certificates. This is a pretty complex topic, so I’m very interested to see where it goes!

Gremlin’s Jason Yee comes to us with Trailblazers: exploration, discovery, & navigating failure - a set of topics that I personally find fascinating and essential! I think we are constantly in a state of discovery and understanding of our complex systems, and learning how to explore them - and work through the inevitable failures - helps us build and operate even more reliable systems.

Rounding things out is the always incredible Tim Banks, with Toxic Velocity: Speed Kills. In this talk, Tim is going to cover the various stressors that put pressure on both organizations and individuals, how they affect us, and what it looks like when things start to spiral out of control. I’m excited for this one because while crashes do happen, we’d all like them to happen less often (or not at all!), and being able to identify some of these things before they become a real problem is better for our businesses and our people.

Explore all of the rest of the great sessions, and don’t forget to register for the cloud engineering summit!

What Exactly Is Cloud Engineering?

Matty Stratton — Fri, 23 Jul 2021 12:46:42 -0500

When we think about the idea of “cloud engineering,” we often think about the concept of taking standard software engineering practices and tools, and making them available and consistent across development, infrastructure, and compliance teams.

It sounds a lot like what DevOps was supposed to accomplish, right? Many great practices have come out of software engineering that we can apply to operations and infrastructure. Likewise, practices from operational disciplines are equally applicable to development teams.

In cloud engineering, we look at how all of these practices are available to multiple functions and teams. It’s a compelling concept, and the more that we refactor our thinking around this, the more effective we can be at delivering value to our customers and users.

Cloud engineering has three main components: Build, Deploy, and Manage. These are all different areas, but they have a lot in common. We will dig into each of these areas in detail in upcoming posts in this series, but here are the key concepts around each.

Build

This might sound like it’s just about writing code, but the build area of cloud engineering is about creating services and infrastructure that provide what our customers need. In today’s world, we use cloud resources to build applications, services, and infrastructure. These resources can make up a shared service platform, giving a single, consistent experience across multiple teams.

It’s also advantageous to create reusable infrastructure components so that application and service delivery focuses on differentiators rather than “reinventing the wheel.” Reusable components provide a consistent and standard implementation, using our organizations’ and teams’ existing practices.

Besides expressing our own best practices and common configurations and approaches, when we build our infrastructure using standard programming languages, we can take advantage of the entire ecosystem surrounding them! We can leverage existing IDEs, test frameworks and approaches, and other wonderful tools available for those languages. Using modern architectures also focuses on the value our services and platforms provide, rather than bespoke and custom implementations.

Deploy

It doesn’t count until it’s in production, right? Code and infrastructure don’t give any value until it’s in front of our customers and users. But doing this in a manner that is highly efficient and quality-consistent is key. Deployment processes that take too long or require too many manual steps can block us from getting new features to our customers or resolving service issues.

When we apply software engineering practices to our deployment processes, this can ensure that we ship the same way, every time. It’s become common practice to apply the principles of continuous integration and delivery to our application software, but we can use the same principles with our infrastructure. This means that new and changed infrastructure resources can meet our quality controls and be tracked and understood when we are investigating the dreaded “what changed?” problem.

The value of automating deployment isn’t just about providing the tests; it ensures all the steps we require are performed every time. Regardless of years of experience, every human is capable of missing a step or making an error. We want to have our skilled humans focus on the areas that benefit from human expertise and not waste their time on the things that don’t.

“But what about checklists?” Checklists are great! But they are even better when a human defines them and are run by software. The power of a checklist is in defining steps, and in many ways, automation expresses our checklists in code. Code that can be tested, reviewed, and managed.

But beyond simple automation, having a unified approach to deployment for both application code and infrastructure changes allows us to consider automation as the key part of the application. We think about infrastructure as a critical and essential component rather than something that happens “on the side.”

Manage

Getting our services into production is a key step, but it’s not the end. Our customers constantly use our services and applications, and we need to manage all of the resources in use. As it applies to our applications and services, visibility across all of our infrastructure allows everyone on our team, regardless of their role, to have a common understanding of what’s going on.

You may be familiar with the adage “security is everyone’s job.” What that means in the world of cloud engineering is that we consider security and compliance (whether regulatory policies or organizational policies) to be closely integrated into our work. Treating our policy as code, just as we treat our infrastructure as code, is a powerful idea! When we express these policies as code rather than prose in a document, we can apply these policy checks both before and after we deploy our services and infrastructure. Doing so extends the common “vocabulary” for collaboration across all teams, regardless of where they sit in the org chart.

Another key piece of the manage story is that we need controls in place to allow who can make changes and what they can change! We trust our team members to want to do the right thing, but we also need guardrails and controls to ensure that they can do so. This means that we need visibility into all changes that occur - treating our infrastructure just like we do our source code in git! Additionally, having the capability and intentionality around fine-grained access controls is critical to make all of our team members successful, provide reliability around our services, and provide confidence for our customers.

Summary

When we take the ideas of cloud engineering and apply them to our organizations, we can deliver value to our customers and users. We can do this by applying the practices and tools already available to our teams and applying the same principles to our infrastructure and application code. We get increased collaboration capability within our teams, a higher level of trust and confidence in our services and applications, and a better handle on the complexity of the modern cloud. We will explore some specific practices and tools around each of these areas in future posts and how they can be applied to your organization!

Do you have a great story around your experiences with cloud engineering? We would love to hear it at the upcoming Cloud Engineering Summit! Submit your proposal to the CFP by July 31st!