Blog Image

DevOps Vision Blog

AWS DevOps Engineer Pro Exam – Experiences

Cloud, DevOps Posted 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 you really can’t live without the global search feature to find code among your code repositories. – Come on CodeCommit team!


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 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”!

Autonomous teams Supporting Microservices 24/7

DevOps Posted on Tue, April 24, 2018 06:47PM

For agile software teams, moving to fully take responsibility not only for Development and Test, but also for Operations is a challenge. On top of that, supporting their services 24/7 may seem more than one can demand.

This post hopefully gives you some useful thoughts to consider when deciding how to effectively deal with support of your software applications/services 24/7.

First. Many have seen the value of a clear ownership of the code that builds your application. With code means: application code, tests, database scripts, configurations. Not only that but also the delivery pipeline definition and infrastructure code. It is important that one application or service has one (and only one) team owner.

At the very start, the team that chooses to create a repository (e.g. Git-repo in GitLab) and store some code in it is the owner of the lifecycle of the code. From the first day code hits production, the team that owns the code must then also take care of the 24/7 operational support of the code. If the team do not, the team is not (at least by my definition) autonomous. A team is usually between 3-8 persons.

Consider below aspects before taking a decision if you want to involve an external team/partner to take care of supporting operations of your code in production:

– What team do you think handle support better than your own team? Your team knows their code best. Agree?

– Do you believe you can write solution templates for an external person to follow when things start to fail at night? And if you do write “disaster instructions”, will the external person who follow those do more good than harm? For all types of things that can go wrong?

– What about offload the heavyweight lifting of for example a database server to a cloud provider. Using for example AWS RDS service your team don’t need to patch servers or care about high availability. The cloud provider manages that for you. Of course, you need to invest in understanding what the cloud provider does and does not do for you. With Serverless services your team does probably not need any capacity planning at all.

Zero Downtime deployments: When your services can be updated without end user impact your team members will do it on office hours. QA mindset will significant increase when the engineers who writes the code also the same day push the change to production. And when the change is pushed, they are awake ready to deal with good or bad end-user impact.

– If your services are very business critical, consider introducing a pager system. That is an on-call schedule for all team members. If the system goes down at night, the engineer(s) who have the pager will be notified. But for that to work you really need to have a reliable monitoring of your apps. False alarms during night is not that very popular. This is unusual in Europe but more common in US.

Finally. If you seriously consider external support, are you doing that to increase customer satisfaction? Or just to have someone else to blame when your services are not available?

2016 State of DevOps Report

DevOps Posted on Mon, June 27, 2016 10:36PM

We hope the findings, analysis and guidance in this report help you better understand the potential impact of DevOps on your organization.

As always (5th year in a row) exciting when the State of DevOps Report from Puppet comes out. Above quote is the last words from the report and I can’t say anything else than the guys behind the report accomplished yet another success. I hope people from my company will read and adopt the practices and findings from this report.

Below are my favorite quotes and key takeaways from the report:

Our analysis shows that high performers are deploying 200 times more frequently that low performers, with 2555 times faster lead times. They also have the fastest recovery time and the lowest change failure rate.

The integration of security objectives is just as important as the integration of other business objectives, and security must be integrated into the daily work of delivery teams.

Always try to minimize the amount to test data you require in order to rum your automated tests, and avoid large database dumps wherever possible.

The idea that developers should work in small batches off master or trunk rather than on long-lived feature branches is still one of the most controversial ideas in the Agile canon, despite the fact that it is the norm in high-performing organizations such as Google.

Teams that don’t have code freeze periods also achieve higher performance.

Agile has more or less won the methodology wars, but in larger companies it’s still common to see months spent on budgeting, analysis and requirements-gathering before work stars.

Leaders can change culture. In today’s fast-moving and competitive world, the best thing you can do for your products, your company and your people is institute a culture of experimentation and learning, and invest in the technical and management capabilities that enable it“.

DevOps is no longer a mere fad or buzzword, but an understood set of practices and cultural patterns.

– Yes, I made the survey for the report and will do so next year. Thanks to Puppet, Inc!

My very first blog post

DevOps Posted on Sun, June 12, 2016 10:14PM

Finally. Could not wait no longer than until today to create my very first blog post in my brand new DevOps blog.