Lockhead – Page 4 – lockhead.info

AWS SWAG that is used and not just grabbed – sustainable SWAG :-)

Ever since I’ve attended my first AWS re:Invent in 2017 one of the SWAG items that I received is part of close to every trip that I do, regardless if its a business trip or a personal trip, this AWS bottle always joins me in traveling:

This bottle does not only look good, it also keeps the water cold when we go on longer, warm hiking trips.
What is your favorite SWAG item? Do you have any SWAG that you regularly use?

I have a lot of other SWAG, but this is really the only item that I regularly use.
Do you have some SWAG that you like to carry on?

Here’s the AWS Community Builders SWAG kit that I receveid a few weeks back:

It’s also cool, but I’m not yet using either of the items on a daily basis 😉

Why CDK changes the everything for building DevOps teams that own something end-to-end

Software Engineers, Developers, etc. are all “Builders” in my mind. Builders try out a lot of things and most of them are eager to try out new technologies and possibilities.
While doing that, a lot of them behave like these engineers “in real world”:

people working on building during daytime

What does that mean?

They go to the top of something, climbing somewhere and taking risks, but a lot of times they forget what is “below” what they are building.

For these workers in real life, it will most probably obvious that they are not risking their life by climbing up there – because they can see what is below and are aware of the groundwork below the wall they are climbing on.

How is that different in our “Cloud-Software/SaaS-industry”?

I believe that the main difference to day is, that most of our “Engineers” (= Software Developers) are not aware of the infrastructure components that are required to bring their application or microservice up and make sure that it can consistently run.

Why are they not aware?

One of the challenges that I am seing in my day to day job is that we have a lot of “abstractions” that we have build for software developers to make it “easy” to develop and test software. Think of “Docker” or “Kubernetes” (k8s) as making it easy to test applications or microservices locally and make them look, feel and behave the same as in the “target environment”.
However, that is not essentially the truth.
During the development cycle, the engineer will test locally – or maybe within a Continuous Integration environment – but both of these environments will usually not have “production like” data assets and thus will never be comparable to a production environment.

So – it is a real problem, because engineers test against infrastructure (and maybe even deployment strategy) that is not even close to how the service will run in a production environment.

How do we change that?

It should all start with a plan…and everyone that is part of a products lifecycle should be part of it.

person working on blue and white paper on board

CDK changes everything

CDK – and for me this includes awscdk, cdktf, cdk8s – gets the engineer where they feel “home”:

We can describe and write infrastructure in “the developers native language” – Java, Typescript, Go, .NET.

With this, everyone can be empowered to write infrastructure code and feel responsible for it. No more excuses: I don’t like YAML / JSON, I dont know HCL, I don’t know the services, etc.
If you are a developer, you can now write infrastructure code.

This opens up new possibilities for building DevOps teams

Now, with CDK “in the game”, we can empower “developers” and “operators” to talk to help each other “in one joined language”.
Operators can help Developers understand the infrastructure required to bring their service up to speed – and Developers can help Operators to develop infrastructure code.

On the other side, if you start a new DevOps team, you can directly start building out the infrastructure “as it would look like in production” using CDK!
This really makes the developers think about how the service should be running in the production environment later and that will help to drive the correct architecture decisions right from the start.

If you want to learn CDK – look at the CDK Workshop: https://cdkworkshop.com/

More to follow around why I believe CDK is making every cloud developers and DevOps engineers life better soon!

There is nothing like a “perfect” DevOps engineer!

In my last post I wrote about the “T-shape” model of a “great DevOps engineer” – but does that person actually exist?

I understand the DevOps team that builds & operates “something” in a complex environment. This includes the required software development aspects of it, the CI/CD pipeline, the monitoring tools required, the database or persistence layer, the infrastructure, … – everything that you need to be able to successfully operate what you have built as a team.

Wait… is it only that?

Everything mentioned above is technical, isn’t it?
The “software development” might be Java, Typescript or Go code (or anything else), the CI/CD pipeline is a technical thing. – but is this “enough” for the DevOps team?
I think that we need to add a business view into the team aswell – at the end, anything the DevOps Team builds needs to produce business value or needs to be compared to it.
A “defect” needs to get a dollar value, a new feature needs to produce new revenue and an update to our tools (e.g. monitoring) needs to be translated to costs or time&effort saved.

So what is the perfect DevOps engineer?

Skills shape

A “T-Shaped” DevOps engineer would need to change his skills to have a “Square-Shaped” Skills matrix!

What else does he need?

In additon to the “technical skills”, he will also need to have the business view on the microservice or component he and his team owns.
In an outage, he also needs the communication skills to be able to talk and communicate to clients and a sense of the urgency of the problem.

While I believe that there are a lot of great DevOps engineers around, I have not yet met one that was close to the “target” of being “perfect” in all of the points mentioned – and I am sure I forgot a few…. Feel free to comment!

A perfect DevOps engineer does not exist. It’s the perfect combination of different T-Shaped engineers that act as one team that makes a great DevOps team.
Johannes, March 2022

What are key enablers for a great DevOps team?

Everyone in the team has its skills he is really good at. The really good DevOps engineers are able to “bend” their T-Shaped skills to something that is closer than to the square – maybe not in “all” parts of it but in a few of them.

But what a “great” DevOps team needs, more than anything else is Vision, Trust & Collaboration.

Recent experience from my professional career

Telescope, Insight, Outlook, View, Binoculars, Optics

In my professional career I recently joined a newly formed Development Team as part of a project. We quickly got up to speed with each other and created an atmosphere of trust in all of our (remote-only) meetings.
This made it easy to start collaborating and jointly work on the tasks we had in our backlog.
What we did not have right from the start was a vision, on what we wanted to achieve as a team. Once we had one, or at least a sprint goal for the next two sprints, we where able to quickly deliver value.

A team needs visionary engineers

Hitech, Art, Concept, Digital, Psychedelic, Design

If you want to create a great DevOps team, you will also need visionary engineers, that are brave enough to try out new things by themselves and empower the rest of the team to follow them towards their ideas.

What do you think about how to form a great DevOps team?
Please share your throughts in the comment section!

DevOps and the T-Shape expert

Last year I attended and internal meeting with our UX team and while talking to the team, we touched on a very interesting question:

How do you define a “great DevOps engineer”?

If you ask five different people, I am sure you would get at least six different answers 🙂

So, without trying to “answer” the question but still covering parts of it, let’s try to look at what DevOps actually is and means.

The conversation on the meeting started with a colleague asking for some support around “DevOps” tasks that were needed to perform certain activities around release activities. I pushed back on him, pointing out that for me, everyone should have a little bit of “DevOps” knowledge – but re-defining these “DevOps” tasks as being “Automation Tasks”.

I very much enjoyed the conversation, and it reminded me of something that I’ve leared during my DevOps master certification in 2019:

A “great DevOps engineer” has a T-shaped skills profile.

So what does that mean?

A “T-shaped skills profile” is easily explained: Think about the “old” traditional way of combining an engineering team, you had “Analysts”, “Programmers” (Developers), “Test Engineers”, “Web Designer”, “System Engineer” (build automation, scripting, etc.).

In that case, you had the problem that you hit the “bottle neck” with certain skills during different phases of the project, e.g. the “Test Engineers” needed to work vey long hours right before the next release of your piece of software. That was obviously bad for the overall outcome of the team.

However, if you manage to compose your team with people that have a very broad knowledge base for different skills and a small amount of skills where they are experts, your team becomes more efficient because you can support each other in these “clunchy situations”, e.g. “developers” can pick up a bit of “QA work” right before the release date.

So, what does this mean for you?

Be aware of your “expert” skills
Practices the skills, where your team is “weak” at, to become better at it and broaden your teams capabilities

Why do we need teams that consist of “T-shape-skilled” engineers?

Because in the “DevOps culture”, its all about “collaboration” – and that is easier, if every team member understands what the “expert” is talking about, at least high level.