The Ops Community ⚙️: Erik Lundevall Zara

Tidy Cloud AWS - Shift focus to solutions from tools

Erik Lundevall Zara — Wed, 11 Oct 2023 07:28:00 +0000

Hello all!

Welcome to this issue of the Tidy Cloud AWS newsletter!

In this issue I write a few reflections on Pulumi, and also OpenTofu vs Terraform. There are many things to write about tools and vendors, but I hope we focus less on the details of specific tools. Instead, the focus should be more on solving the problems and issues we are trying to solve.

Whether we use Neovim, Visual Studio Code, or Intellij, it doesn't affect problem-solving in software development. For some problems, we can ignore that relational database we use, as long as it supports some flavour of SQL.

Will we get to that point with cloud infrastructure automation? I hope we will, in a few years.

Pulumi gets more ka-tching

Last week, Pulumi announced they had got more funding from investors, 41 million USD to be more
precise. This means they have received about 98.5 million USD in funding, if my numbers are correct.
They also announce that they have now over 100 employees, over 2000 customers on their Pulumi Cloud platform,
and over 150000 community members - people who use their tools.

I am not sure of what the revenue and profit numbers may be for the company. I have seen estimates of both 1.4 and 3.6 million USD in revenue for 2022. So the company might not be profitable yet, in that case. As far as I can see, they have more than doubled the company size, employee-wise, in the past year.

They have fewer employees than HashiCorp (around 2000), and may be larger or about the same size as Upbound (creator of Crossplane).

I think they are in a good spot in the market, though. If you have a software development background, I think it is one of the more approachable offerings out there to manage cloud infrastructure.

Not only is the documentation getting better and better, there are also multiple examples and templates to start a project with. Plus, you can also use their Pulumi AI tool to kick you off to get some idea on how to write the infrastructure. It can be a good starting point.

The strength with Pulumi is that they are on a good path to make the core Pulumi tool itself less relevant. Instead better tools and services will be built on top of Pulumi - either by Pulumi themselves, or by others.

Pulumi AI statistics

In Pulumi's newsletter The Pulumipus #27, they included a small infographic picture about the usage of their
Pulumi AI tool. So far, people have sent about 100,000 prompts, with approximately half of them being for AWS.
Also, Typescript and Python are clearly the dominating languages here.

Most likely, these statistics reflect what people use or prefer to use. It could also be where they have the most pain and difficulties, or a combination of those...

Infrastructure as Tofu

If you have an interest in the Terraform ecosystem, you may know that HashiCorp changed their license for all of their core products to no longer be open source, but use a business source license. This includes Terraform, arguably their most widely used tool.

This resulted in a fork being created from Terraform 1.5.x, which still has the open source license, then called OpenTF. Apparently, the name was too close to the original with the TF part, so the name had to change, and it became OpenTofu.

Despite the horrible name, OpenTofu might become a significant part of the infrastructure as code space.
Companies that have been betting on HashiCorp's multi-cloud strategy and use many of their tools will most likely stay with Terraform. Other companies that rely on various non-Hashicorp products and services built on top of Terraform will more likely go with OpenTofu.

My prediction is that in the long run it will not matter that much in a few years. In the long run, we won't care or may not even know if it is Terraform, OpenTofu, or something else, because tooling will mostly hide it in a few years.

The products and services that will succeed are the ones that make it easier to build better interfaces and solutions on top. We are not there yet though, so in the short term, it will still be important.

Those who will make the Terraform vs OpenTofu choice irrelevant for the rest of us will be the winners, I think.

You can find older newsletters and more at Tidy Cloud AWS.
There you can also find other articles to help your cloud engineering work be more productive, efficient,
and enjoyable!

Until next time,

/Erik

Tidy Cloud AWS - command-line productivity

Erik Lundevall Zara — Mon, 04 Sep 2023 08:03:00 +0000

While I enjoy graphical user interfaces and use that every day - much of the time I still spend with the command-line. It can be development tasks, troubleshooting, trying out various things - I do a large portion via the command line.

In this issue, I want to include a few tips on command-line tools that I have found to be quite useful. They are all open source, so you can try them out for a bit - you only will commit a bit of time for it.

Enjoy!

TaskWarrior

The first command-line tool I am covering in this issue is TaskWarrior. I find it an amazingly versatile to-do-list type of tool.

In the past, I have used GUI tools like Todoist for many years. I have also tried to use plugins in Obsidian to organise my tasks as well. I also have to deal with Jira boards for various customers, as well as GitHub issues.

I discovered TaskWarrior through a YouTube video that discussed making a user interface for the program. I got curious about what TaskWarrior was all about, and investigated.

The idea of a to-do-list tool on the command-line intrigued me, and I installed it (brew install task) and tried it out. It is easy to get started with the basics of adding and completing tasks. Digging further into the documentation, I found it was quite rich in features.

Features

TaskWarrior can handle simple tasks, recurring tasks, and tasks that should only appear after a certain time. It handles due dates; it handles dependencies between tasks. You can set priorities on tasks. You can annotate tasks with extra notes, and these are automatically time-stamped.

Projects can have associated tasks, and we can create a hierarchical structure. You can tag task with tags of your choice, and you have extensive filtering and reporting capabilities. You can define different contexts, so that you, for example, only see work-related tasks if you have a context defined for work.

TaskWarrior arranges tasks in an "urgency order" using information like priority, age, and due dates that you provide. You can also adjust the weights that are used to perform the urgency calculations.

As it has all these capabilities, it has a relatively simple interface and you can just use some bare basics. As any command-line tool, you can create scripts and aliases to help you perform more complex tasks or reduce typing.

My workflow

I am a fan of the Getting Things Done (GTD) method, and I found this to work out well with TaskWarrior. For multi-step tasks, I use projects to keep the steps together. I can use dependencies to set which order they should be done, and I can use the wait feature to hide tasks until some future date/time.

By default, TaskWarrior sorts the tasks by urgency and shows the ones that can be performed next, and I rarely find it necessary to change their priority.

I can use the tagging feature to add extra information such as location, if there is a need. So far I think it works better than any other to-do-list tool I have used.

It is a very versatile tool, and also quite accessible.

There is also plugin and hook mechanism, which allows to extend the features of TaskWarrior. There is a list of various tools on the website, but I want to mention two of them which I think are quite nice: taskopen and bugwarrior, see below.

I can also include some YouTube videos here, which I found quite useful to get an idea of what you can do with TaskWarrior and how to use it:

Taskopen

Taskopen is a simple and useful tool. If you add an annotation with a URL or a file path in it, you can reference the task with taskopen, and it will open the URL or file for you. You can also add a "Notes" entry in an annotation, and taskopen will open a text editor to put in more long-form text. I keep these notes in my Obsidian writing vault along with other notes, and I can also add references/links there.

Taskopen is written in nim, and you need to check out the GitHub repository and run the build script to get the executable. Plus, you need to install nim.

Bugwarrior

If you want to integrate TaskWarrior with other task tracking systems, chances are that bugwarrior is what you need. It supports various applications like Trello, Jira, Bitbucket, GitHub, GitLab, etc. Also, it integrates with Gmail.

So far I have used it to integrate with Jira, and can run bugwarrior-pull to sync the Jira issues with my task warrior tasks. It works well. They include the comment history from the Jira issues as annotations in the TaskWarrior tasks.

The integration is one-way though, so if I complete the task in TaskWarrior, it will not automatically be completed in Jira. It is still much better than to need to jump around in multiple systems just to check what tasks are there.

Bugwarrior is written in Python, so you need to have Python installed in your environment to use it.

TimeWarrior

All that task management sounds great you may say, but what about tracking the time I spend on these tasks?

Glad you asked!

TimeWarrior is a companion tool to TaskWarrior, which is developed by the same group of people. It focuses on being a quite nice tool for time tracking, and it can integrate with TaskWarrior - if you add a hook, any task you work on in TaskWarrior will automatically be tracked in TimeWarrior.

TimeWarrior has a quite simple user interface as well, and in its simplest form you just start and stop time tracking. You can add tags to each time interval tracked to categorize time in any way you want.

You can add missed time periods and edit times later.

You can adjust time periods absolutely or relatively, split or merge them, and remove them. You can track your time by setting specific periods, and the timer will skip non-working hours, weekends, and holidays if you configure that.

It also has nice filtering and reporting capabilities.

In the past, I used Toggl Track to track my time, and it worked well - but it was a GUI, and did not integrate with the systems I had to put in the time into. I still transfer the time manually right now, but the time summary and entries to copy have become simpler for me with TimeWarrior.

TimeWarrior is still relatively new for me, but it has been working well so far.

Git branchless

I have mentioned Git branchless in a previous issue of the newsletter, and it is something I have used more extensively in the past month.

As the name implies, it is a set of extensions to regular git which try to make trunk-based development nicer, and avoid feature branching and pull request type workflows. It does not stop you from using branches, but it allows you more freedom to work in parallel with stacks of associated commits. It allows for more experimentation, and better safety nets from messing up your main branch.

The git branchless tools took more effort to work with than I thought. The documentation could have been better in explaining good practices. Straightforward at the concept level, sometimes harder when you get into the nitty-gritty details.

However, I am happy to have started down this path, and now I run a git branchless init on most of the repositories I work on.

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

Until next time,

/Erik

Tidy Cloud AWS - Go for the future

Erik Lundevall Zara — Fri, 01 Sep 2023 08:14:00 +0000

Today I want to talk a bit about Go - the programming language, not the board game. I want to talk about why I think some features of the language and its ecosystem are great for cloud engineering work, and also what could improve.

There will be an added focus on Go in the next coming weeks from my end, both in the newsletter and in blog posts on Tidy Cloud AWS.

Enjoy!

Benefits of Go

The creators of Go intentionally designed it to be a language that should be relatively easy to learn and work with. Google made Go, which is used for many popular cloud software tools such as Docker, Kubernetes, Pulumi, Terraform, and others.

There are a few reasons which I think make Go a very interesting language:

Small language. There is a limited set of features in the core language itself. It is thus relatively easy to learn and keep in your head.
Great bundled tooling. The bundled go tool has helpful features for testing, documentation, code checking, and formatting. It is all there, no complex process of installation and set-up.
Fast compilation. Go is a compiled language, but the compilation is quick. You can compile and run code without worrying about delays, most of the time.
Simple deployment. Go programs compile to a single binary, which makes it easy to deploy. No complex runtime environments to set up.
Compatibility. The designers of Go are very careful about not introducing breaking changes in the language. This makes upgrades of Go uneventful things. Go code that was written many years ago will probably still compile and run.
Good community. You can find documentation and learning material for Go in many places, and I find people often being quite helpful overall.

Note that I have mentioned no features of the language itself here. Instead, most of these benefits are things that make the general life of maintaining solutions build in Go easier. For cloud engineering work with infrastructure and operations, I find this precious.

Of course, there are also language features that I think are nice, as well as missing features that would be nice to have.

Picking a language for cloud engineering

In my day-to-day tasks, I often engage with multiple customers, as well as internal teams. Some use Terraform, other use AWS CDK, or tools like Serverless Framework, or AWS Copilot. Those that use AWS CDK may use different languages as well.

Many of the languages and tools in place can be pretty ok, once all the bits and pieces are in place - and you spend at least 40-50% of your work week with them. The problems arise when you have solutions you only touch occasionally, because you seldom need to do any changes.

If there are complex runtime environments (compilers, build tools, testing tools, packaging tools, etc.) that can be painful to juggle. Setting up a specific in a docker container image may ease that pain, but can still be a lot of work. Not only the setup itself, but to re-learn all the different tools and options in place.

For example, I like both TypeScript and Python as languages, but not the complexities of the environments they need to run and maintain the solutions in. Go is much simpler to work with in that regard.

However, with tools like AWS Cloud Development Kit (AWS CDK) the experience with Go leaves a bit to be desired. When you work with AWS CDK, the primary language is Typescript (JavaScript) - all other languages are second class languages. The Typescript-oriented flavour of the tools is noticeable with Go. There are also very few examples for Go - even AWS own documentation lacks Go examples.
Pulumi does a better job here. It's not surprising that Pulumi does a better job here since it's written in Go.

We will explore using both AWS CDK and Pulumi with Go in separate blog posts.

Learning Go

For programming and software development, learning by doing is a key aspect. There are many books and video courses for learning Go. Just reading or viewing video does not work though, instead you need to do stuff.

A few resources that I think are good are:

Exercism - this website has learning tracks for many languages, including Go. You have some learning material for the language itself. They combine this with small and relatively simple exercises to learn different concepts of the language. Some prior programming experience is good, but you do not need to know Go before starting here.
Learn Go with tests - This is an excellent website which teaches you Go by using Test Driven Development (TDD). You should have development experience in another language before starting this, but you do not need prior knowledge of Go.
Gophercises - This is a free course which contains a few mini projects to learn specific concepts and areas of Go programming. You should have some knowledge of Go before jumping into this one.
The main Go website has A Tour of Go, plus references to multiple tutorials and guides.

I am a big fan of Learn Go with Tests and I also like Exercism. A word of caution - if you have a tool like GitHub Copilot or AWS CodeWhisperer active, it may be too helpful for you to actually learn sometimes. Consider turning them off, if you have any of them active normally.

Last, I also want to mention the Go Playground. It is a useful place to try out small snippets of Go code, and it is also very useful to share code with others. For example, if you run into a problem and want to ask for help. It will be much easier for people to see the code that is not working and try it out themselves with a shared code snippet via the Go Playground.

Parting thoughts

Using a programming language is much more than just the specific syntax and features of the language itself. That is good to keep in mind when picking a specific language for a task, be it Go or another language. For cloud engineering related work I think Go is a quite good option to consider.

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

Until next time,

/Erik

Tidy Cloud AWS - Hashicorp goes BSL

Erik Lundevall Zara — Tue, 15 Aug 2023 19:02:24 +0000

Hello all!

Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, I reflect a bit on Hashicorp's recent change to a Business Source License for their products.

Enjoy!

Hashicorp changed their licensing to BSL from open source a few days ago. Others, like Elasticsearch, Redis and Cockroach Labs, have done the same in the past. How will this impact users of their products?

Not as open as before

What this means is that the products will still be free to use for many of the customers. However, competitors to HashiCorp cannot use or embed the source code and products in their offerings. They need to get a special licensing deal with Hashicorp in order to do so. See also Hashicorp's frequently asked questions.

So what are these products then? HashiCorp's website lists Terraform, Packer, Vault, Consul, Boundary, Nomad, Waypoint, and Vagrant as their products. Vagrant does not have a commercial offering, and a few of the other products make more sense if you are into the Hashicorp ecosystem.

The main two products that a good deal of may use without the rest of the Hashicorp ecosystem are Terraform and Packer, I think. The competition mostly revolves around Terraform usage, so the license change will affect those using old Terraform Cloud and Terraform Enterprise, now called Hashicorp Cloud Platform.

Companies like Spacelift, Scalr, and Env0, and maybe Terramate Cloud, are among the competitors. A less obvious one is Oracle Cloud's Resource Manager, which is a managed service that helps manage infrastructure based on Terraform.

Hashicorp confirms they will keep all Terraform providers, SDKs, and Cloud Development Kit (CDKTF) open source.

Hashicorp's Business Source License is for new releases only. The existing release still has the old open source license. Hashicorp will do security patches on the open source releases until December 31st, 2023.

Who will be affected?

While Hashicorp claims only competitors to their commercial offerings will be affected, I believe it could affect others as well. The direct effect is on competitors, but customers who chose them are also affected.
A problem here, though, is that the definition of a competitor is very vague, so it seems to be at the whim of Hashicorp if they decide you are a competitor. If not today, then perhaps tomorrow. Or if you are not competing with their products today, perhaps they will release a competing product to your product later?

There is a lot of uncertainty about this license.

Contrary to companies like Elasticsearch and Redis Labs, the main competitor targets seem to be not the hyper-scale cloud providers. Instead, it seems to be smaller businesses like Spacelift, Env0, and others. Hashicorp themselves has over 2400 employees with a $100+ million in revenue per quarter, some of their competitors only a handful of people. They are not making a profit, though, so this is probably a way for them to make the company profitable.

Spacelift wrote a short note about this, stating that it is certainly legal for Hashicorp to do this, but questioning of this is ethical to do. Joe Duffy from Pulumi also wrote a short note on this topic as well.

Pulumi should not be affected, since they have their own core engine for infrastructure-as-code. License change won't affect Terraform providers used to access resources which do not have Pulumi providers yet.

Many people think Pulumi is based on Terraform, but it's not. This is a communication challenge for Pulumi.

Oracle Cloud may make a deal with Hashicorp about their Resource Manager offering, but it won't be a big problem for them..

AWS will not care much either. I do not think they use anything of the Terraform core or any of the other Hashicorp products.

But there are many relatively smaller companies that certainly will care and worry about their business.

OpenTF

Gruntwork's Yevgeniy Brikman wrote a great post titled The future of Terraform must be open. He outlines a lot of what is bad with this new license, and presents a new initiative, called the OpenTF manifesto.

The idea is to convince Hashicorp to revert to an open source license for Terraform. If they do not do that, they will fork the open source licensed version of Terraform and work on a version of Terraform that will be open source, forever.

The manifesto has a GitHub repository where you can show your support by signing up.. Several companies and a few individuals have signed. They may provide development support for a fork.

I applaud this initiative, and I hope that Terraform will stay open source.

Final thoughts

I am a bit torn about this topic. It is fine if a company uses a Business Source License for their products, and Hashicorp is not pretending it is an open source license after the change. As they are not profitable and publicly traded, they most likely need to satisfy the investors. For many users of their products, it will not be much or any difference.

However, this is done after several years of being open source, and basically changed overnight. There are probably several smaller companies that might get into difficulties. Their products aren't bad and the competition isn't better, but the conditions they competed under changed a lot. It remains to see which license deals these companies get. It is not a nice way to try to get ahead of the competition.

What do you think?

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

Until next time,

/Erik

Tidy Cloud AWS - FinOps

Erik Lundevall Zara — Fri, 04 Aug 2023 10:19:52 +0000

Hello all!

Welcome to the next issue of the Tidy Cloud AWS newsletter! FinOps is about including cloud cost in engineering work for business value, and promoting collaboration.

Cloud costs may be part of project architecture, but often lack feedback and adaptation. More often, when costs are not as expected, there are specific tasks to optimize costs by dedicated people. The work then is to either optimize and cut costs, or to explain why costs are the way they are. After that, nothing particular happens until the next surprise in costs pop up.

We can do better than that, which is what FinOps is about.

Enjoy!

FinOps

FinOps combines Finance and DevOps, underscoring the significance of financial and business teamwork with developers and operations. A key goal behind FinOps is to optimize cloud spend to maximize business value.

This means establishing practices to get both engineering and business/finance "on the same team" and work together. Companies can appoint specialists in FinOps to assist with that.

Engineers must consider cloud costs in architecture and design. A FinOps practitioner would make it easier for software and finance teams to collaborate.

The FinOps Foundation website is a great resource for information on FinOps. There is a lot of good material available there that explains the ideas and principles behind FinOps. The foundation has a FinOps framework with roles, assessment, and learning material available.

The organisation also has a YouTube channel with plenty of videos and talks around FinOps.

The FinOps Foundation is organised under the Linux Foundation and has over 10000 persons as members from over 3500 companies.

The foundation has defined six FinOps Principles that guide the activities around FinOps:

Teams need to collaborate. Teams in finance, product, engineering teams should work together, in near real time and for continuous improvement.
Decisions are driven by the business value of the cloud. Value-based metrics and suitable unit economics to better show business impact. It is about business value, not cost cutting.
Everyone takes ownership of their cloud usage. Engineers are accountable for usage and cost, and empowered to make their own decisions of usage against their budget. Cost is an efficiency metric to consider.
FinOps data should be accessible and timely. Cost data should be processed and shared as soon as possible with stakeholders, with fast feedback loops and consistent visibility throughout the organisation.
A centralized team drives FinOps. This is an idea of "Cloud cost center of excellence", a centralized support team for the rest of the organisation around cloud cost matters.
Take advantage of the variable cost model of the cloud. Look at the variable cost model as an opportunity to be agile and flexible to drive value, not a risk factor. Apply various techniques to be have fast feedback loops for iterative planning, change, and to be proactive.

FinOps is still a relatively young practice, and there is not a single answer to how to do this, but there is a good foundation to start from and adapt.

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

Until next time,

/Erik

Tidy Cloud AWS - container optimisation

Erik Lundevall Zara — Wed, 26 Jul 2023 13:47:00 +0000

Hello all!

Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, I will cover a few things about running containers in AWS. and making that better, cheaper, faster, more productive.

Enjoy!

Faster container startup in Fargate

AWS introduced Seekable OCI, a technology that enables lazy loading of container image content, almost a year ago.

This technology reduces the load times of container images at startup. Depending on the container image setup, not all files and data in an image are used, or used right away. So by only loading the content that is actually used and needed, startup times can be reduced.

Recently, AWS posted a blog post that Seekable OCI is now supported in AWS Fargate - further down in the post it states that it is specifically for Fargate on AWS ECS, so perhaps Fargate with EKS is still out of luck?

The container images remain the same. New manifests were added that show file locations and sizes in the container image layers.. So any existing container image can be made into a “seekable OCI” and thus can lazy load in AWS ECS Fargate, assuming that the image is loaded from AWS ECR.

The blog post is quite good and presents both a command-line tool (soci) and a deployable lambda solution to make the images seekable. The post also compares start-up times for images that are seekable vs. non-seekable.

Both the results of the blog post and from some customer quotes point to an improvement in startup time by around 50%.

The steps to make image seekable seem straightforward, so should be a useful addition for container deployment in ECS Fargate.

Check also out the video on YouTube's "Containers from the couch" channel that discusses the new Seekable OCI feature in AWS Fargate. It is about an hour long.

Better container images

Another lovely blog post from AWS is one with the title Building better container images. It goes through a couple of items on handling secrets, signing and securing images, and optimising image content. It is a nice piece with some useful tips, most of them which are not specific to AWS.

The blog post here also pointed to a command-line tool called Finch. It is a command-line tool for container-based development. You can consider it an alternative to the docker command-line interface, without the Docker Desktop user interface.

Finch is a wrapper around a few open-source tools in this space, including nerdctl. These are packaged together to make the installation simple. Finch is currently macOS only, but there are plans for Windows and Linux support in the future.

Fargate cost optimisation

Compute Optimizer is an AWS service that analyzes compute-oriented resources and recommends enhancements. Watch Cost optimization on AWS Fargate video on Containers from the couch YouTube channel to learn about using Compute Optimizer for AWS Fargate, on ECS.
The Compute Optimizer considers optimisations for both performance and cost, with a preference for performance.

The Compute Optimizer service is free, you just have to enable it. It can be enabled at the organisation level through AWS Organizations as well.

ECS Blueprints

For some time now, AWS has provided a set of ECS Blueprints which are templates to make certain types of workloads in AWS ECS easier to set up. Initially they have been available for Terraform, but now they have also added blueprints for AWS Cloud Development Kit, as announced in a recent blog post. The code for the blueprints can be found in a GitHub repository https://github.com/aws-ia/ecs-blueprints, both for AWS CDK and for Terraform. The AWS CDK examples are written in Python.

It is a nice addition that AWS added AWS CDK examples here, and I think it is also good that there are examples in Python. There need to be more example code in languages that are not called TypeScript.

There is also an online workshop for the ECS Blueprints, which covers both Terraform and AWS CDK as well.

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

Until next time,

/Erik

Tidy Cloud AWS - Achieving greater value

Erik Lundevall Zara — Thu, 20 Jul 2023 08:00:00 +0000

Hello all!

Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, I talk about the value of AWS certifications, based on a blog post from AWS. We have video recommendations about agile, meetings, and continuous delivery. There is also an alternative project template for AWS CDK in Python.

Enjoy!

The value of AWS certifications

I read a blog post from a new AWS solutions architect who accomplished all six specialty AWS certifications on their first try. This kind of post strengthens my belief that there is not that much value in the AWS certifications if you already have a good amount of real world experience.

It is useful as a replacement for real experience when you are starting out. Not to diminish the accomplishment of the author of the post - it certainly takes some skill and dedication to pass all these certifications. But that it is possible at all diminishes the value of these certifications for experienced people in these areas, I think.

There are four reasons to pursue AWS certifications:

To get (better) jobs in cloud computing when you lack real world experience for that job
Fulfil AWS Partner requirements to uphold a certain status
To do a Pokemon thing of it - got to catch them all
Give yourself a personal goal motivator to learn AWS stuff beyond what you do daily if you need something extra for it.

For number 2, it does not help much to get many certifications nowadays, since AWS counts one certification per individual in the company.

Personally, I have no interest in number 3 and I do not need number 4 for motivation to learn.

Do you agree with my reasons here, and what do you think of the AWS certifications?

AWS CDK project template for Python

Recently I wrote a bit about an initial version of an AWS CDK project template for Python. The reason for making this GitHub repository template is a slight frustration with the existing templates provided by AWS CDK.

I usually rewrite the AWS CDK generated templates for my projects, or instead copy files from an old project. I noticed I was rewriting the same things every time. That’s why I made this template. It’s opinionated, but it is also made to be easily configurable and extensible.

This project template is just for Python and includes some features and handling that AWS CDK itself does not help with. If that is of interest, read the blog post and check out the template on GitHub. It is a work in progress. Let me know what you think!

Video recommendations

How to make the most of meetings

Aino Corry, who is a contributor to the @Continuous Delivery YouTube channel, has a great video about how to make meetings better and more productive, titled You're WASTING Everybody's TIME In Meetings!. She makes some very good points and offers suggestions on how to improve meetings and meeting culture. There are several points about good meetings that many of us know should be part of a meeting, but we do not do it, anyway. Aino makes some good points on dividing up the things that we can do to make meetings better, if we need the meeting at all.

Watch it, and watch it multiple times if you are not taking notes the first time.

How to actually work agile

There is also a great video by Aino Corry about working in an agile manner, titled You're Probably Getting Agile Wrong - How To Fix It. I think this is an absolutely brilliant video!

She presents the 12 agile principles, and continues with that there are too much for people to read, so they do not read them. The Agile Manifesto simplifies this into 4 areas:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

She continues with how these 4 areas get misunderstood in people may skip the right-hand side, which is not the point. Each area is covered and how to go about working in a good way with these.

Aino also points out that agile is not equal to Scrum or any other "agile process framework" - doing Scrum does not make you agile necessarily. You can also be agile while not doing Scrum.

Aino points out that "Individuals and interactions over processes and tools" is probably the one that may be hardest to get right, which I agree with.

I definitely recommend watching this video!

Checklist for continuous delivery / DevOps

The third video on my video recommendation list is the 14 step checklist to achieve continuous delivery / DevOps by Dave Farley. It is a long list, but also has many important steps to consider. Each step is a valuable piece to consider, and it is great to have these summarised like these.

What the video itself does not cover is how to get there, as it is more of a summary on many of the topics that Dave covers in his YouTube channel.

Dave created course and book material on this topic, and the Minimum CD website is a great source for understanding the minimum viable continuous delivery process, broken down.. Some of these pieces are further broken down into pieces as well.

There are many good recommendations there to get an idea on how to achieve continuous delivery and deliver great quality software. You may still struggle to get this in place, but at least you will have some recommendations and material that can help you on the way.

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

Until next time,

/Erik

An opinionated AWS CDK project template for Python

Erik Lundevall Zara — Mon, 17 Jul 2023 12:15:00 +0000

AWS Cloud Development Kit (AWS CDK) is a nice framework to use if you build infrastructure for AWS. It can be relatively quick to define various types of cloud infrastructure for AWS.

However, I have found the experience to set up a new project to be lacking. This project template, found at https://github.com/cloudgnosis/awscdk-python-template, addresses some of these issues, specifically for Python users..

Template summary

The summary here of what is included you can see here, to read a bit more about the reasoning, look further below:

Adding config to CDK context automatically, from TOML files.
Encourage a flatter, non-inheritance approach to resource composition to facilitate refactoring
Simplified stack creation - automatic if single stack project, and always assign AWS account and region to stacks
Simplified stack-level tagging of resources
Modern package manager usage option - PDM
Python development tools include:
- black - code formatting
- ruff - fast linter
- pre-commit - Pre-commit hooks for formatting and linting
- pytest - testing framework
Logging and print debugging
- structlog
- icecream
Extendable model and behaviour processing of project setup options
Requires Python 3.10 or higher currently

Usage

This is a GitHub template repository, so if you re using the GitHub GUI, you can click on Use this template and select Create a new repository.

https://github.com/cloudgnosis/awscdk-python-template

Or just copy the files, or use the parts that fit your use cases. Either way, I hope you find some parts of it useful.

Reasoning behind the template

The core of the template comes from a frustration with the regular cdk init templates, which is not that flexible. I rip out or change a lot of the content - to where I might have set it up from scratch instead.

There is also a certain amount of boilerplate work for handling config data, stacks, tags, and AWS environment setup. I'm a fan of black (code formatting), ruff (code linting), pytest (testing) and pre-commit (run checks before git commit). So these are included by default.

AWS CDK examples encourage building solutions with inheritance, and push most logic into constructors. Grouping resources through inheritance leads to (too) long resource identifiers. Keeping resources after refactoring is difficult because of CloudFormation's restrictions.

Also, I think inheritance is overused. It might be useful for building specific reusable components, but not for everything in a CDK-based solution.

There are multiple project scaffolding solutions that work for Python, but not so much aimed at issues with AWS CDK and Python.

The intention is to provide a rather lightweight template for setting up AWS CDK projects, which may cover some common use cases. It is extendable and many behaviours can be replaced easily, if desired.

Examples

All examples below call a function add_sqs_sns_example() to add an SQS queue and an SNS topic, with the SQS as a subscriber to that topic. This is very much like the default AWS CDK template generated, except that the stack to add them to is passed as a parameter to this function. The same pattern can be used for any resources.

Here is a rather simple example, which will have a single stack, and all resources tagged with Environment = dev:

def main_example():
    model = ias.init_ias_model(
        {
            "deployment_name": "examples",
            "tags": {
                "Environment": "dev",
            },
        }
    )
    stack = model["stacks"]["default"]
    add_sqs_sns_example(stack)
    ias.generate_from_model(model)

This will set up a CDK App, and a single stack with id default and name examples. All resources will be tagged with tag Environment with value dev. The model object is a dictionary that contains the app, stack, and environment resources.

You get the stack from the model, and can call functions to add resources to that stack. When this is done, the generate_from_model() function will create the CloudFormation, the same as calling app.synth() on the CDK App object.

AWS account and region will be determined based on the currently active credentials, in this case.

A slightly more complicated example may look like this:

def main_example():
    model = ias.init_ias_model(
        {
            "deployment_name": "examples",
            "stacks": [{"id": "main"}, {"id": "other"}],
            "tags": {"Environment": "dev"},
        },
        option_processors=[ias.simple_config_defaults],
    )
    main_stack = model["stacks"]["main"]
    other_stack = model["stacks"]["other"]

    add_sqs_sns_example(main_stack)
    add_sqs_sns_example(other_stack)
    ias.generate_from_model(model)

Here there are two stacks, with ids main and other and stack names examples-main and examples-other . There is a different option processor, which in this case includes reading config from TOML files. All config data is available though CDK context, so it can be retrieved via any CDK Construct-type object (Construct, Stack, Stage, App).

The option processors are simply functions that update the input options and return a new set of input options. When all these processors have been executed, the actual model initialisation takes place.

The example resource function that works for the main example functions above look like this:

def add_sqs_sns_example(scope: cdk.Stack):
    config_group = scope.node.id # Use CDK stack id as config group name
    queue = sqs.Queue(scope, "queue", visibility_timeout=cdk.Duration.seconds(300))
    topic = sns.Topic(
        scope,
        "topic",
        topic_name=ias.get_context_data(scope, [config_group, "topic_name"]),
    )
    topic.add_subscription(subs.SqsSubscription(queue))

and the example TOML config file:

[main]
topic_name = "my-topic"

[other]
topic_name = "other-topic"

Design considerations

All options and the model structure use the TypedDict feature. This is like a regular dictionary, but also includes typing information for the defined fields. Thus you can get type hints in your editor of choice for these structures, plus it allows for you to extend them yourself as well. It also uses structural typing, meaning that as long as the dictionary includes the required fields, it is a valid data structure. No need to create class objects explicitly. It is kind of similar to the typing experience found in, for example, TypeScript.

Rather than loading resources into the stack constructor, I suggest using regular functions to add them. This should help with building a bit more modular code without too much boilerplate.

Things to do

Add handling for stack dependencies
Generate API docs
- Issues with getting pdoc to work when JSII is involved
Figure out reasonable scope without making it too heavy, for example
- Wrappers for sharing data between stacks? (Parameter store, etc)
- Add (optional) default monitoring (e.g. via cdk-monitoring-constructs)?
- Add (optional) default security/policy processing (e.g. via cdk-nag)?
Get more feedback

Summary

This template is an attempt to make some nicer defaults for people developing AWS CDK solutions with Python. Check out https://github.com/cloudgnosis/awscdk-python-template and tell me what you think of it!

Tidy Cloud AWS - Rebuilding DevOps

Erik Lundevall Zara — Wed, 05 Jul 2023 11:53:00 +0000

Hello all!

Welcome to the next issue of the Tidy Cloud AWS newsletter! This issue looks at System Initiative's announcement and their tools for DevOps work.

Enjoy!

Infrastructure as model

Recently I listened to Changelog podcast #545, with the title Rebuilding DevOps from the ground up. It is an interview with Adam Jacob, who is has been around in the DevOps space for a long time and was a co-founder of Chef.

He is now the CEO of System Initiative. Their goal is to provide better DevOps tooling while still following DevOps principles.

Read the blog post DevOps without paper cuts to understand the pains and challenges System Initiative tries to address. Their very first public talk around what they do was done earlier this year in February: What if Infrastructure as Code never existed?. This talk focuses on the re-thinking process, and that there is a need to "break the rules" and do things differently. The blog post Five breakthroughs on the path to System Initiative outlines a few key items that they tried and changed to make the whole approach something that would improve DevOps-inspired work.
They discuss digital twins of actual infrastructure, referring to infrastructure as a model.
The software is currently in a private beta, with the intention that it will be open source. What System Initiative will make money on is packaging the whole solution as a coherent and production-ready solution. They compare it to RedHat's business model, which has this type of approach.

I appreciate they do not require you to start from scratch. It can live in parallel with existing solutions. You should, in theory, be able to transition step by step in using this infrastructure as a model approach.
This is thanks to the bi-directional support of infrastructure management via digital twin technology.

I find this a very refreshing approach, and which comes from a different perspective than infrastructure from software. System Initiative is very much coming from an understanding of ops problems, and also the ideas behind DevOps in the first place with collaboration between operations and developers.

Infrastructure from software comes very much from a point of view of making building solutions in the cloud easier for the developer, and trying to make infrastructure transparent/easier to cope with.

The paper cuts in DevOps-related work is something I have in my work most days, so it is nice to see something that may be transformative here.

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

Until next time,

/Erik

Tidy Cloud AWS - working backwards

Erik Lundevall Zara — Fri, 09 Jun 2023 11:30:00 +0000

Hello all!

Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, I am coming back to a topic I have touched on before, which I think is worth bringing up again - working backwards and asking why?.

I will experiment with the content of the email newsletter, the Tidy Cloud AWS website, and sites like The OPS community. The general idea is to adapt content more depending on where it is published. The schedules will be different also, with email newsletter being the most frequent.

Enjoy!

How working backward is the best way forward

Have you had a situation where you have chosen a specific solution to a set of problems because it seemed to be the right thing to use, only to discover later that it did not work well at all, was too expensive or no one used it?
I have been there multiple times. It's easy to solve problems without researching first.

An example: At a former employer, we used SumoLogic for a lot of log analytics and monitoring of AWS workloads. It worked very well, and it was quite useful for the operations group. Then some persons from that group joined a startup company and had to select the tooling to use when operating their AWS workloads. Here, it did not work out at all. The same tool was barely used, and the value was questionable.

A key reason for this was that the tool was picked before properly understanding what was needed compared to the old company usage:

Different and smaller organization, different responsibilities and roles
Workloads were not the same, use cases were different, although similar at a glance
Priorities were different

In short, the differences meant that applying the same solution pattern did not provide enough value to the organization. Not that SumoLogic is a poor tool - on the contrary, I think it is a very capable tool and can provide significant value.

Amazon and AWS pride themselves on customer-focused product development, beginning with a press release:

Working backward at Amazon
You don't need a press release like Amazon, but the same idea stands.
A bit of research going backward would have helped to make a better decision for the monitoring solution:

Identify stakeholders
- What roles do need information about the state of the solution(s) and what are their responsibilities?
- What do information they require, in what form, and when?
Identify key performance indicators
- What are the business values that we want to ensure are upheld for our customers?
- How is that measured?
- What is the definition of a healthy state for those values?
- At what point is that healthy state at risk?
- What actions should be performed when the healthy state is at risk?
Map KPIs and solution resources
- Identify resources/components that can provide data
- Identify types of insights that can be gained (behaviour, faults, performance)
- Identify the type of information to collect (logs, metrics)
- Identify source to collect from (e.g. log files, system performance data)
- Figure out threshold and/or patterns in resources to use for alarms
Reports, alerts, actions
- What to report to who
- How to deliver report data
- Which formats to use
- Determine Severity
- Actions (automated, manual)

The above is an iterative process - both to get into enough detail to answer questions, and changes in requirements.

The general pattern here applies to many areas, not just monitoring solutions. This also applies to automation. When should you automate a process or activity?

The answer is “it depends”, or rather it is not the right question to ask first. If you ask a question like that, you may get answers such as “When you have repeated it 3 times” or “Always”. But there is no context in such answers.

A better question to ask is why should this process or activity be automated? At the surface level, answers that may come up could be:

To save time for repeated tasks
To be (more) consistent
To avoid human error
To distill expert knowledge into something that others may use
To have some documentation of the steps of the process or activity

But these are still vague. They may all be valid to some extent, however, they should still go back to a defined business value or aim.

Start with your customer and work backward. It requires discipline though, and practice.

Even with Amazon Web Services, where they presumably practice this every single day and it is a part of their corporate culture, they can still provide customer experiences that are quite crappy. I think there are other aspects at play as well though, plus it might not always be clear who is the customer from AWS point of view.

What do you think about working backward from the customer?

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

Until next time,

/Erik

Tidy Cloud AWS #52 - infrastructure - as code, as software, from code

Erik Lundevall Zara — Thu, 01 Jun 2023 10:23:30 +0000

Hello all!

Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, I talk a bit about the terms infrastructure as code, infrastructure as software, and a relatively new term infrastructure from code.

Enjoy!

Managing and surviving infrastructure

In this newsletter, I often cover matters related to infrastructure as code, and sometimes also refer to infrastructure as software.

Infrastructure as code often uses text-based, machine-readable descriptions and version control solutions to manage changes.

That is pretty much as far as the common description and understanding of the term goes. Other software engineering principles are often neglected. This can include things such as modular design, test driven design, test automation, refactoring.

Part of the reason is that some tools are not so well adapted for this, and part of it may be a lack of insight on how to apply such principles to infrastructure.

Infrastructure as software is a way to distinguish it as a form of software engineering, not just simply apply some software-related tools.
It has also been used by Pulumi to describe infrastructure as code, but with regular programming languages. (https://www.pulumi.com/what-is/what-is-infrastructure-as-software/).

It's more important to understand software engineering principles and methods rather than specific languages..

...and now, infrastructure from code

A relatively new term that has popped up is infrastructure from code. The general idea here is that the infrastructure is derived from the application code, or that application and infrastructure code are the same.

There are multiple approaches here. These include:

added annotations in the code for the infrastructure
SDKs and frameworks
new languages and environments built to abstract away the complexities of infrastructure.

The goals are like what proponents of serverless were talking about almost a decade ago - simplify handling of the underlying infrastructure so developers can focus on building applications.

A few players in this space include:

Wing and Dark are new languages, which can be a challenge to get adopted. Wing seems, though, that it should be able to leverage the Node.js ecosystem to some extent.

Some of these tools will generate infrastructure code for other tools, such as Terraform, AWS CDK and Pulumi, under the hood.

Reflections

The infrastructure from code tools are next generation serverless tools, more so than next generation infrastructure as code, in my mind. So I think the term infrastructure from code is misleading.

If you are in a position where you handle both application code and infrastructure code, and run in the cloud, then these tools make sense for some use cases.

Existing infrastructure as code tools will remain useful. Good software engineering practices will help them thrive. To me, that aspect is key more than specific implementation details on how the infrastructure code is generated.

If you want to read more extensive coverage on this topic, there are a few blog posts that are worth reading:

Adam Ruka, former team member of the AWS CDK team, talks about different generations of infrastructure as code tools.
Ala Shiban from Klotho talks about state of infrastructure from code 2023.
Yehuda Cohen has written an extensive post exploring different cloud development tools.

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

Until next time,

/Erik

Tidy Cloud AWS #51 - fixing CloudFormation shortcomings

Erik Lundevall Zara — Mon, 29 May 2023 09:57:00 +0000

Hello all!

Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, I will cover a bit on fixing shortcomings in CloudFormation, at least for some specific use cases.
Enjoy!

CloudFormation custom resource challenges

CloudFormation has had custom resources and custom resource types for a while now.
There were examples of custom resources in the past as early as 2014; custom resource types arrived a few years later..
The features have not been adopted widely, even with vendors creating custom resources.
AWS has difficulty with consistent coverage across its Console, APIs, CLI, and CloudFormation. Custom resources handling has still been too much of a hurdle to be widely adopted to address these shortcomings.

AWS CDK to help

AWS CDK (Cloud Development Kit) is a successful and convenient way to use custom resources with CloudFormation. AWS CDK has custom resources to help with CloudFormation rough edges for various services.

Mostly, you only see that there are custom resources in action when your AWS CDK deployments include more AWS Lambda functions than you have defined yourself.
AWS CDK also includes convenience features to make your own custom resources much simpler to define, at least for some use cases.

Look at my article on overcoming CloudFormation shortcomings with AWS CDK, if you are interested in a concrete example.

From a convenience point of view, it approaches Pulumi dynamic providers, although the underlying implementation is quite different.

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

Until next time,

/Erik