Hello all!
Welcome to the next issue of the Tidy Cloud AWS bulletin! In this issue, we cover buildpacks, podcasts and YouTube channels, and a review of old 2022 predictions and wishes.
Enjoy!
Containers and buildpacks
If you are working with container deployments, chances are that you may work with docker files. Sometimes that can be fairly straightforward, sometimes that can be complex to set up and maintain.
This is especially true for application developers, which most likely do not have dockerfile management as a core task. This may not necessarily be something you would do every day in an operation or platform engineer's role either.
Buildpacks is an approach to simplify setting up and managing docker images, in which you normally would not need to care about docker files. A buildpack is a component that detects and set up a part of the software that is needed for the application solution.
For example, if you have a Python application that uses Django web server solution, there would be buildpacks that detect that you are using Django and Python and which versions, what package management tools are used (e.g. pip or poetry). The buildpacks also set up the relevant software components into a container image.
The setup of an appropriate container image should be automatic, and be able to adopt to changes and do patches easily, and across many container images, if needed.
There are multiple services that use buildpacks under the hood to make deployment of certain application code automatic, like Google App Engine and AWS AppRunner.
Each buildpack takes care of one piece of the whole set-up, and you combine multiple buildpacks to handle different pieces of the whole set-up, with buildpacks that reference other buildpacks, etc. At the very top of this hierarchy is a builder, which defines what buildpacks to run and in what order to figure out what is needed for your particular use case.
You can use pre-made buildpacks, and you can also define your own buildpacks. They can essentially be written in any language that follows the buildpack interface specification.
There is a command-line tool, pack, that you can use to run a builder with associated buildpacks. There are also APIs (at least for Go language) that can run the build process programmatically.
If you think you are spending more time that you would like to fiddle around and manage docker files and building images, then perhaps buildpacks may be for you!
A few links that can be useful regarding buildpacks:
https://buildpacks.io/ - the main buildpacks website, a good starting point
https://paketo.io - a registry for many production-ready buildpacks
Accelerating development velocity with AWS AppRunner and cloud native buildpacks
Podcasts and YouTube channels
It has been about a year since I posted some thoughts and recommendations for podcasts and YouTube channels, so here is an updated list of a few recommendations. There are both some old favourites and some new ones.
Ship It! and Changelog podcasts
For the area of infrastructure-as-code, automation, DevOps and cloud infrastructure, one of my favourite podcasts is Ship It!. The tagline is A podcast about getting your best ideas into the world and seeing what happens. It is an excellent podcast with many interesting discussions and interviews. The host Gerhard Lazu does a great job of covering many areas around shipping software solutions, being productive and, above all, the people behind it. As he says a the start of every episode - the focus is on the people, everything else is an implementation detail.
This podcast is just one of a handful of interesting podcasts from Changelog, which in total have 8 different podcasts at varying levels of activity. This includes more language-oriented ones like Go Time and JS Party, as well as specialised areas such as Shipit! and Practical AI, and the general Changelog.
There is also a master feed for all the podcasts, so you can get all the podcasts through a single feed.
Screaming in the Cloud
The Screaming in the Cloud podcast covers topics around cloud platforms, mostly, primarily interviews and discussions with people that do interesting things mostly in the cloud, but not always.
The host Corey Quinn is an engaging and fun person, at the same time being respectful and nice. It makes listening to the podcasts enjoyable. I recommend this podcast for general cloud topics.
AWS Morning Brief and Last Week in AWS
The podcast AWS Morning Brief is another podcast with Corey Quinn. This podcast focuses on news around Amazon Web Services (AWS) and has a fun spin on different news and updates from AWS. Each episode is typically 5-10 minutes long.
Continuous Delivery
The Continuous Delivery YouTube channel with David Farley is a great source of information around software delivery, testing, development, etc. David Farley is one people that coined the term delivery pipeline and has weekly releases, many times opinionated, about topics in the space of software engineering. The videos are simple and to the point, usually around 15-20 minutes long. It is well worth it to check it out; I think.
DevOpsToolkit
DevOpsToolkit is a YouTube channel hosted by Victor Farcic, which produces many videos covering various tools and practices in the DevOps space. There is a lot of focus on Kubernetes and tools in the Cloud Native space. If you work a lot with these tools, this is a good channel to look at.
Review of 2022 predictions
Over a year ago, in the Tidy Cloud AWS bulletin #16, I made a few predictions and wishes for 2022. It was not particularly revolutionary items, but I thought it would be good to check what happened in the past year.
Sustainability - a year ago AWS had recently introduced its sustainability pillar in the Well-architected framework. I here hoped that AWS would ramp up its efforts much more in this area, with genuine improvements to support customers in this space. The result from this year is a bit so-and-so, to be honest. There have certainly been some improvements, like the AWS Customer Carbon Footprint Tool. Still, AWS is still behind for example Google Cloud in terms of transparency, and accessible details in sustainability.
Multi-cloud - I predicted AWS would not make much efforts to support multi-cloud better, in terms of the ability to integrate and cooperate with other cloud providers. I think that is correct. AWS does its own thing mainly and supports some de facto cloud-agnostic standards.
Data transfer costs - I predicted that egress data transfer costs would drop a bit from AWS, but more from other cloud providers. This did not really happen. The costs are about the same still, only the free tier limits have been raised. I guess this is a too lucrative income area to make significant changes here.
Better multi-account support - my prediction was that AWS would make many more services have multi-account views, but not have a consistent experience. I think that is correct. There are certain areas that have been improved for managing multi-account views, but are still not a coherent experience. This was really a wish that AWS would improve here, but I honestly did not expect them to improve much.
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 (2)
Looks like 2.5 out of 4 predictions were correct 🎉
When did you realize that the other 1.5 were not going to come to pass? And do you think the ones you predicted correctly were safe bets, or were you going out on a limb with them?
AWS not doing much for multi-cloud support was a pretty safe bet I think. Data transfer costs would need other cloud providers to do that before AWS, specifically Azure and to some extent Google Cloud. Raising the free limit and nothing else soon after also pointed to that it would not happen I think.
As long as AWS is not separated from the Amazon store business, I think the transparency around sustainability will be more limited.
Overall, I think those that were more wishes than predictions farled to some extent, and the others relatively safe bets within a 1-year timeframe.