Hello all!
Welcome to the next issue of the Tidy Cloud AWS bulletin! In this issue, I cover a few ways to practice programming, writing about what I think are the actual goals behind serverless and platform engineering, and an interesting bit about AWS new service CodeCatalyst.
Enjoy!
The art of storytelling in programming
I recently watch this presentation called The secret art of storytelling in programming, which I thought was pretty good. The presenter Yehonathan analyses and presents ways to think about programming to make code fun to read.
He makes a good case for considering how to write code that fits well with how our brain works and thus allows us to consume and learn the code in a good way. It boils down to a couple of good coding practices, and understanding memory, attention and structural spans.
The presentation is at a London Clojurians meetup, but most of the talk is not really programming language specific, although he makes a few points near the end why this works well for Clojure.
Programming practice
As in many areas, you need to practice improving your programming skills. The best is of course if you can practice as part of your daily work routine. But that may not always be the case, and perhaps not with a programming language you want to get better with.
How can you practice then?
One good way is available at Exercism. It is a great website where you can find many exercises for (currently) 61 programming languages. The number of exercises in each language varies. Also, some languages include a learning mode with language tutorials and exercises grouped into different concepts.
You can run the exercises locally on your computer, and for some languages you can also run it in the web browser - nothing to install. Your code needs to pass several tests before the exercise can be completed.
One unique feature of Exercism is the mentoring feature, where you can get a real person to review and comment on your solution. Even if your solution works and passes all the tests, you may have ways to improve in this language. This is one thing these mentors can help you with.
I have used the mentoring in the past, and it is a great feature. It works well, at least as long as there are enough mentors to review and comment on your code in a timely manner. I think it is a great site for small programming exercises.
Another site which provides some good exercises is Code Kata. The term is inspired by katas in karate, which is a way to repeat forms and movements to practice and improve. Code katas work well also to solve as a team or group.
Finally, I also want to mention Advent of code, which is a year event in December where you can solve programming problems, one per day in December until Christmas. It is a good opportunity for practice and something that can be fun to do with friends and colleagues.
Platform engineering trends
An article on DZone, Platform Engineering trends you need to know, discusses the growing discipline of platform engineering. It is worth a read if you are interested in the topic. Even Gartner recognizes that platform engineering is a thing nowadays.
Amazon CodeCatalyst
There were many announcements at re:Invent 2022, one which was the new service Amazon CodeCatalyst, now in preview. It feels a bit like CodeCatalyst is AWS’ new attempt at providing a good developer experience environment, after the failure of Codestar. Will they succeed better this time?
Only time will tell, but I think they might do better by being a bit more friendly towards non-AWS tools. Also, you do not need to be tied to a specific account and region for your identity, instead you use an AWS Builder Id, which connected to individual users instead. Just this little feature makes me want to have a look at it more closely.
AWS intends to release a series of blog posts around various features of CodeCatalyst, starting with Using workflows to build, test, and deploy with Amazon CodeCatalyst
I hope to try this out in a not too distant future.
Serverless and platform engineering, two sides of the same coin - Developer/Ops Delight
In previous issues of Tidy Cloud AWS, I have talked about platform engineering, which is an area which is growing a fair amount. It is closely related to the idea of platform teams, which provide platform components to make life easier for application development teams, to reduce the cognitive load for these teams, with self-service features at an appropriate level.
In short, there is a goal to provide Developer Delight and Operations Delight.
The keywords here are cognitive load and self-service. Before the cloud, the cognitive load for developers was perhaps actually lower than today. Infrastructure and scaling was someone else’s problem - most times it still is, though. It involved lots of waiting for others to fix things that were not in the control of the develops.
Cloud infrastructure and services are very much an adaptation of a self-service idea for the things that were outside of the core development activities. Things can take minutes or seconds, instead of days, weeks, or even months.
This increased speed came with the cost of increased cognitive load for development teams. The serverless trend that took off many years ago was one approach to reduce this cognitive load by avoiding issues with scaling resources and configuring actual servers, even though they may be virtual.
I think serverless is a bad term, since the key benefits that were envisioned were not specifically about the servers themselves, but a reduced cognitive load while maintaining speed in development - only deal with just enough infrastructure, if at all.
A problem here is that while actual server maintenance is not there in the serverless space, the cognitive load has also increased. Building solutions with functions-as-a-service with AWS Lambda requires many solutions to touch many services in AWS, and understanding how they work and how they fail.
Many AWS services do not have an appropriate level of abstraction for developers. This is where platform engineering, and other (3rd party) managed services building on top of AWS and other cloud providers come into play, to hopefully fulfill some goals that originally were attached to the serverless trend.
There are lots of tools and frameworks out there that solve different pieces of this complexity puzzle. Perhaps so many that understanding the landscape there will increase the cognitive load significantly…
The cognitive load issue is not just for developers, but also for operations. The hundreds of services and tools from the cloud providers, the large load of different tools to keep up to date with and figure out can be quite stressful. If you look at the services from AWS, there are no clear labels that say - “for large-scale enterprises only”, “recommended for small IT teams” or something similar.
The ideas behind platform engineering may help to reach Developer Delight and Operations Delight. These are also terms that I think are more appropriate to express the intent, rather than talking about serverless.
You can find the contents of this bulletin and older ones, and more at Cloudgnosis.org. You will also find other useful articles around AWS automation and infrastructure-as-software.
Until next time,
/Erik