Welcome to the next issue of the Tidy Cloud AWS bulletin! In this issue, there are items around Cloud and Platform Engineering, Visual Studio Code dev containers, Pulumi and AWS CDK, and also CDK8s.
Cloud Engineering Days
They have had a great line-up of speakers in the past and covered many interesting topics, and not necessarily about the Pulumi product suite. The agenda this year is definitely more slanted towards Pulumi products, which I think is a sign that the offering has matured and there is enough to fill up the conference alone. I look forward to attending at least part of it live, given the time zone differences. There are usually recordings afterwards also, to catch up on other items on the agenda.
Develop as an SRE
Site Reliability Engineer (SRE) is a role that was coined at Google, which touches both operations and development. One blog post by Brandon Willett shares some experiences around how to build software as an SRE.
Boost productivity with Visual Studio Code dev containers
In my work, there have been many clients and projects, which could use different technologies, tools and releases. Sometimes you need to jump back to one of these projects, which may have been months or years since you last worked with it.
There could also be a project where you needed to onboard people, and there is a non-trivial setup for the tool chain to use with the project, which can take some time to get productive with.
In the past (Tidy Cloud AWS bulletin #16) I wrote about one such tool for setting up ad hoc environments, Nix. While it has some very interesting and nice properties, in practice you may struggle a bit here, especially for onboarding new people.
I have found the Visual Studio Code dev containers to provide a nice balance in terms of desirable features and easy-of-use, and posted an introductory article about it: Boost productivity with Visual Studio Code dev containers
The term Platform Engineering was a term that I came across for the first time maybe half a year ago, only to realize that this describes what I am doing much of my time, or aspire to do :-)
Platform engineering is very much associated with the concept of a platform team, which is described in Team topologies, an area which Dave Farley covered in some videos, see Tidy Cloud AWS issue #30.
A platform team and platform engineering is not just a more fancy name for IT support team. Some core principles include:
- empowering developers
- good developer experience
- self-service for developers
It is not something that is enforced upon the developers either. A good mindset here is to think of the platform, whatever that may be, as a product, and the developers in the company are the customers and consumers of that product.
There are a few resources that may be interesting to look at in this space:
Much of these resources point to each other, including a Slack workspace for Platform Engineering.
Pulumi and AWS CDK
If you have developer/software engineering skills and are working with infrastructure as code, tools like Pulumi and AWS CDK definitely can provide a productivity boost, compared to CloudFormation, for example.
Both these tools are similar in programming language support, in that they both allow you to write infrastructure definitions in Typescript, Python, Java, C# and Go. Looking just from a code writing experience, I made some comparisons between these two in an article A tale of two tools - Pulumi and AWS CDK.
I really like both tools, and they both have their strengths and weaknesses. There will be more articles in that space in the future as well.
CDK8s and CDK8s+
Victor Farcic from the DevOps Toolkit YouTube channel published a review of CDK8s, which is a tool to generate Kubernetes manifests in YAML (https://cdk8s.io). I think Viktor is spot on with when CDK8s can be useful and when it is not. If you are working with tools like Helm or Kustomize for Kubernetes, look at it - maybe CDK8s will be suitable for your use case.
On the same topic, AWS also announced general availability of CDK8s+. CDK8s+ is a library of higher-level constructs intended to make certain uses cases simpler to implement. This can certainly be part of reducing the cognitive load to handle manifests in Kubernetes.
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,