The Ops Community ⚙️

Cover image for Tidy Cloud AWS issue #40 - Productivity, Pulumi, Platforms, possible spark of joy
Erik Lundevall Zara
Erik Lundevall Zara

Posted on • Edited on • Originally published at cloudgnosis.org

Tidy Cloud AWS issue #40 - Productivity, Pulumi, Platforms, possible spark of joy

Hello all!

Welcome to the next issue of the Tidy Cloud AWS bulletin! In this issue, there is a mix of different interesting reads around productivity and efficiency, interesting AWS blog posts, nice command-line tools and Pulumi updates.

Enjoy!


Reflection on Tidy Cloud AWS

The purpose of both the Tidy Cloud AWS bulletin and the Tidy Cloud AWS website are to communicate and explore ways and tools to make working with the cloud environments less messy, but also to make the cloud work spark joy. I think this goes hand in hand - for tools or ways of working to spark joy. They are more likely to be tidy and nice.

The other way around may not be true, though. There are many things that may look tidy and nice, but do not fit well for the context and persons using it - they do not spark joy.

The expression spark joy comes of course from Marie Kondo’s 6 rules of tidying - Ask yourself if it sparks joy. Sometimes it is good to take a step back and think about the processes and tools we use, and if they spark joy. If not, why are they not, and how can we make them do that?

I do hope that the material here may spark some joy with you, and your cloud environments gets a bit more tidy and nice in the process!

Command-line tools that spark joy

Speaking of sparking joy, the tools from Charm_ definitely fit into that category, as well as the website itself!

There are both libraries to use for making nice command-line tools in Go, and tools you can use directly in shell and scripts, like vhs and gum.

Maximizing developer effectiveness

I recently came across a blog post from two years ago by Tim Cochran from Thoughtworks, titled Maximizing Developer Efficiency. He discusses the importance of shortening different feedback loops in the work of a developer to make the work more efficient, which I think is spot on. The text focuses on developer productivity and efficiency, but I think the ideas and principles apply also if you do ops work, as well as many other types of activities as well.

Tim also continues to discuss micro feedback loops and how making the small activities that are done often is an important aspect to improve efficiency. He continues to discuss how organisations work to optimize efficiency and feedback loops, and scaling these efforts through platform engineering.

It is a well-written post, which seems to have appeared in several places since it was first published.

Platform engineers vs DevOps engineers

Charity Majors from Honeycomb wrote a blog post a few months ago about the shift happening in terms of ops and infrastructure management roles, titled The future of Ops is Platform Engineering. I think an important takeaway here is that the roles and tasks of ops and infrastructure management are shifting in this era of cloud infrastructure and services.

The problems with infrastructure as code

A nice blog post by Luke Shaughnessy titled Infrastructure as Code is not the Answer! caught my attention recently. There are many proponents of using infrastructure as code, including myself. What Luke objects to, and which I agree with, is the idea that everything will be great, if we just use infrastructure as code.

The cloud infrastructure and the processes to manage it will not become nice and tidy automatically, just because we use infrastructure as code tools. It still can be quite messy, and it may not spark joy.

Luke uses terraform as a specific tool example. Many of the issues he brings up are valid regardless of the tool, while some issues are not so relevant when using other tools. There are many good points in Luke’s post, and worth thinking about.

Pulumi updates

Around two months ago, Pulumi introduced Pulumi deployments, a feature which allows Pulumi to run infrastructure as code deployment workflows for you, into your environments. As I noted in my test of Pulumi deployments, you really do not want to have permanent credentials set up for critical infrastructure outside of the cloud provider’s environment. This was possible to accomplish, although required the use of the Pulumi deployments REST API to do that.

Now Pulumi announce support for OpenID Connect (OIDC) in Pulumi deployments, which makes it possible to set up the deployment workflows in Pulumi to use temporary credentials from the cloud provider(s), and also set fine-grained control over what stacks these credentials are valid for. This is a nice improvement, and great to see that Pulumi has responded well to the feedback.

Another neat announcement is the preview of .NET support to write Pulumi providers. Previously, you had to write the providers in Go. Now the supported .NET languages can also be used. This a nice step to make Pulumi tooling more applicable and attractive. Nice work Pulumi!

Interesting AWS blogs

I do not read AWS blogs daily, but now and then I look for some interesting blog posts.


You can find older bulletins and more at Tidy Cloud AWS. You will also find other useful articles around AWS automation and infrastructure-as-software.

Until next time,

/Erik

Top comments (0)