Blog Image

DevOps Vision Blog

AWS DevOps Engineer Pro Exam – Experiences

Cloud, DevOps Posted by andersPosted on Sat, February 06, 2021 06:01AM

Yesterday I made another milestone in my professional career. I managed to get a pass on the AWS DevOps Engineer Professional Exam.

My last (quite extensive) post was about my PASS of the AWS Solutions Architect Pro (SA Pro) Exam. Since the preparation methods I used was very similar I’ll make this post shorter and explain more of what I actually learned from my studies.

The SA Pro exam is very broad. When reading through the preparation material provided by AWS I got a feeling of that I could more or less can get any question on any AWS Service. Which also was shown to be (almost) true for the SA Pro exam. That is not the case for the DevOps Pro Exam.

All 6 domains, except the one SDLC Automation (described in more detail below), in the DevOps Pro have some overlap to the SA Exams. In other words I could heavily make use of the knowledge i gained during my SA studies.

I mentioned in my last post I’m not a big fan of certifications. In the way that a certificate “proofs” your knowledge, my opinion has not changed. You really should NOT hire me just for having these badges. Although the “requirements” to get a PASS claims that you need extensive experience working with AWS, I still not believe that is the case.

However, since I anyway continue to study for certifications, there is one thing with these studies that for me make the effort valuable…

– I learn things I probably should not have learned in my daily work!

…and these learnings have shown to be valuable in my daily work.

SDLC Automaiton

I got one big sad learning from my AWS DevOps Pro journey. The AWS Code* (CodeCommit, CodePipeline, …) is really not services suited for medium or larger organizations. There is one big advantage with these services:

They are all serverless and mostly well integrated with the rest of the AWS services ecosystem. IAM integration and so on.

…but there the advantages ends :-(.

Disadvantage #1 – Pipeline versioning

You can not version the pipeline (CodePipeline, pipeline.yml) in the same repository as the code it automates. Of course you can put the pipeline.yml file in the repository, but an update of that file will not update the actual pipeline itself. In my private AWS Organization I had to do a hack with an home made lambda that made that possible.

Disadvantage #2 – Pipeline progress usability

Having used GitLab and GitLab CI for many years, I’ve been used to the (almost) instant and good overview of the pipeline progress visualization. With Code- Commit/Pipeline/Build/Deploy I sometimes end up in 10 clicks just to get the logs for a pipeline execution. Not developer friendly at all.

Disadvantage #3 – Amount of code needed

Having experience from GitLab CI (and a bit of GitHub Actions and BitBucket Pipelines) writing tiny pipeline.yml files for automation. Then start define CodePipeline definitions is not a pleasant experience. I estimate CodePipeline definitions to have about three times more yml-code compared to the more competitive alternatives.

Disadvantage #4 – Code collaboration capabilties

CodeCommit is based on Git which is good. But (currently) there are zero capabilities for code collaboration. When you got used to search through all code on github.com you really can’t live without the global search feature to find code among your code repositories. – Come on CodeCommit team!

Summary

To end in a positive way I must really say that my learnings from the AWS CloudWatch service has been VERY pleasant. Of course CloudWatch and the teams behind the service was released 10+ years ago. The Code*-teams are quite new and hopefully will also start to listen to customer feedback.

…and my result:



Effective DevOps

Book review, DevOps Posted by Anders LundsgårdPosted on Sun, September 15, 2019 07:29PM

Three years since Jennifer Davis & Kathrine Daniels published the Effective DevOps book – Building a Culture of Collaboration, Affinity, and Tooling at Scale.

It was also three years since I read the book and when I found it during cleaning my dressing room I decided to go through all my favorite quotes marked with a yellow pen.

My top quotes from Effective DevOps

The end goal is to create and maintain a successful organization that solves a problem for your customers.

The more quickly software changes make it into production, the sooner individuals see their work in effect. Visibility of work impact job satisfaction.

Affinity is the measure of the relationship strength between individuals, teams, business units, and event companies.

Empathy allows ops engineers to appreciate the importance of being able to push code quickly and frequently, without a fuss. It allows developers to appreciate the problems caused by writing code that’s fat, or slow, or insecure.

In the devops community, there is a big emphasis placed on postmortems and retrospectives being blameless.

In a blameful culture, discussion stops with finding that specific person made a mistake. In a blameless culture, a human error is seen as a starting point rather than an ending one.

Rather than silos, we view different teams or organizations as islands. Thus, we need to build bridges between the islands.

The designated ops engineer for a given team is not necessary responsible for single-handedly doing all ops-related work for that team, rather that they will be the primary point of contact for that team.

Developers have full AWS access to the development environment and we’ve just enabled read-only production IAM access as well.

Engineers should not be put on pedestals at the expense of other employees, as it takes more than just engineering skills to grow and maintain a successful business.

Devops is about encouraging every member of the organization to contribute to provide value to the whole.

There is no “finally” anymore. There is only an endless cycle of adaptation, change, and learning.

Misconceptions and Anti-patterns

You can not buy or install devops.

Devops is relevant only to web startups. Web startups are not alone in benefiting from improved collaboration, affinity and tools.

There is no separate “enterprise devops” with different tools and practices that applies only to companies with a large number of employees.

If your organization is in a state where the development and operations teams cannot communicate with each other, an additional team is likely to cause more communication issues.

Negotiation or conflict resolution styles – Avoidance; You might see long email threads where people try to shift work or blame without being too direct without ever talking directly with the people being complained about.

People tend to say “I’m not an engineer” or “I’m not technical” as if it were some immutable fact that could never change.

Remember to avoid the trap of “but we’ve always done things this way”!