We've all been there, given access to an AWS account at your new job or project, and now you're expected to deliver results.
Yeah, it's always overwhelming and can trigger an imposter syndrome even for the most experienced DevOps, especially if the account is particularly messy.
Oh, and they're always messy.
How do you make sense and grasp what is happening in this AWS account? How can you step into your new role with confidence and not waste time fumbling because you don't know how things work?
I've compiled a list of steps to help you find that confidence, and reduce your orientation period. Who knows, you may even become that go-to person for all the AWS account questions.
Follow the money
An excellent trick I found to see which services the company uses, or which projects they abandoned, is to look at the billing dashboard.
The billing dashboard shows you how the organization is spending its money and is an easy way to see which regions and services they are using.
It can save you the leg work of going service by service, dashboard by dashboard to figure out what is going on.
A glance at the dashboard can even give you a hint if the company favors using managed services or tend to run their own.
Who knows, something may immediately jump out and tell you they are overspending on resources. Use it later to suggest improvements (Make sure you know what you are doing before rushing headfirst).
The user story
Eventually, every system is there to serve a user, and you can use that to understand both what the company does and how they use their AWS account.
Try to sit down and follow the user story. Ask yourself how they interact with the system and then how the data flows through the system.
For example, if most of the clients interact with a website, follow the http request, think about authentication, load balancers, the backend servers, message queues, and anything else you encounter.
Every step reveals another system in the underlying architecture.
Do you remember those "choose your own adventure" books? You had to keep a small map on the side, and updated it every turn. (I'd pick a monster any day over finding that misconfigured Kafka cluster lurking behind the corner).
The lay of the land - VPC Networking
It may be my networking background, but one of the first things I do on new environments, before I get confident enough to do any actual work, is getting a clear picture of the network topology.
It's something you can start doing straight away by taking small steps, which I find helpful when overwhelmed, especially when I don't know where to start. It's like therapy.
Ask your new peers if they already have a network topology diagram to get you started, and I promise that even if they do have something, it's outdated and filled with gaps.
You can use pen and paper, a whiteboard, or one of the network diagram tools out there.
As you go along, keep asking questions:
- Why did they decide on doing things a certain way?
- Is this resource still being used?
- How are things connected?
- Which security layers are present?
Every question closes another gap in your understanding.
Existing documentation
This one is a bit obvious, but try to see if the company has any documentation of the architecture.
Most companies will, at the least, have a confluence account, or a similar solution for documentation.
You may have to dig in a little deeper or use what they have as a reference while researching, but you may find some answers in there.
Remember that documentation doesn't have to be in the form of written documents. Configuration as code is more common today, and you may find Terraform or another provisioning tool configuration. Even if the code is messy, you pretty much just struck gold. However, don't solely rely on it. Keep building your mental map of the architecture.
Bonus points if you publish your own documents and make the next person's onboarding an easier.
Just talk to people
Another obvious step, but there are a few things you should keep in mind when interviewing colleagues :
- Be friendly and not be judgmental. Sometimes we look at a system and think, what the? Why did they do things the way they did? Well, you are new to the project and don't know the full story. Maybe they did things in a certain way because newer solutions didn't exist when they started. They could have had problems that you never encountered. Just keep an open mind.
Remember that everyone has an agenda. When you start asking people about the system, each person tells a different story, emphasizing different things, blaming others, and telling you about the radical changes they want to introduce. Try to stay objective and don't get sucked into their politics and worldview. They may be right, but make sure you have the full picture before making up your mind.
-
If you are replacing someone that is leaving soon, and it happens quite often, where you are brought in just a day before that person, who knows the system like the back of his hand, is leaving for another job. You may be expected to sit down and cover everything in one day, and then, you're on your own. Even if they care dearly about this project and fully cooperate, the time you have is not enough. So instead of trying to cover everything, try to learn the following:
- Passed on knowledge - Undocumented information that people "remember" - That "Cron job" that updates the whole system every night. A renegade server, which halts every once in a while, and requires a good old fashion reboot every other week.
- How they overcome common issues.
- What are the pressing matters, and what should your next steps be.
- A list of people you should contact regarding different areas of expertise.
Try to be respectful of their time, and remember that you may need to keep this relationship going for the next few years.
Tools
You may be tempted to dive headfirst to using tools that do the work automatically with the push of a button. There are benefits to using tools, but remember that no tool is perfect, and you may be missing valuable data points that are conserved in memory and not the API.
- Cloud Mapper - Will help you create network diagrams and inventory reports for your AWS account.
- TerraCognita - Tries to do the same, but outputs Terraform configuration files.
- Terraforming - Another tool to export your configuration to Terraform.
- And of course, CloudCraft that creates beautiful diagrams by connecting to your AWS account. Again, I think you should use these tools as they are, tools, to help you paint the picture, but don't blindly rely on them.
Where to start?
Grab a notebook and a pen, log in to your AWS console and start taking notes.
I find that the billing dashboard and flowing the user story are good starting points, and will help you come more prepared for meeting with different stakeholders. Just figure out what works best for you and try to enjoy the process.
Want to learn more?
Head over to Push Build Test Deploy and continue reading.
Top comments (0)