../ General guidance when working as a cloud engineer

From the depths of the IT world, there are things that you only learn through experience.

Here's a list to save you time, get better results and have an overall healthier relationship with your work.

Keep in mind that the following list depicts what I have faced through my journey as a cloud engineer. The order has no particular meaning.

Tech-related

• Do not make production changes on Fridays, you will gain enemies if you do so.
• Git should be your only source of truth. Discard any local files or changes, what's not pushed into the repository, does not exist.
• Understanding how your operating system works will grant you a wider view when errors occur. Handy netflix case.
• Write good bash scripts using this guide.
• If you are migrating DNS records using comma-separated files, beware of truncated records. You should also check if the extra dot is added at the end of the DNS records. Generally, the client will not double-check the exported file causing an awful time rechecking the records from your side.
• Before jumping straight into a new technology, read and understand their docs. Eventually, it will save you time and lots of headaches. E.g: If you want to learn a new language, you should first understand the basic blocks of that technology such as (data types, interpolations, variables, assignments, etc.)
• When developing a solution which integrates microservices, keep in mind a simple rule-of-thumb: Microservices should only perform a single task. If you are not able to achieve that isolation, maybe you should switch back to a monolithic architecture. Do not get fooled by the current trends, microservices are not meant for everything.
• Learn and adopt Docker Multi-stage builds into your new Dockerfiles.
• Certify yourself with official courses.
• Naming nomenclature is as important as rotating your user credentials. If you do not name and tag resources accordingly, few years later, you will be pulling your hair out.
• You cannot deliver a secure, compact and well-fitted project if your biggest priority is delivering it as fast as possible.
• Build yourself a good quality profile on tech-related sites, partners and business ideas can come up from nowhere.
• If you are solving an error and there is no apparent solution. Switch your mind into another topic, context switching is also needed for our heads. Every so often, the only thing that we need is some space in between.
• A good monitoring system, well-organized repository, fault-tolerance workloads and automation mechanisms are the basis of any architecture.
• Have a development environment in order to try things. This environment should mimic your production one.
• If you need to build an architecture which involves microservices, I am sure that your cloud provider has a solution that fits better than Kubernetes. E.g: ECS for AWS. Kubernetes is a fantastic toolkit, but only shines when all that it has to offer, gets used.

Human-related

• Let the client know that you are the one who is in control, assert your technological expertise. This does not mean to stop listening to them, but for the majority of cases, the client which bought your services does not have any clue.
• When bad things happen, remember that a wider view is your best ally.
• Learn to say: I do not know about this/that. You cannot know everything that gets presented to you. The bad habit comes when the same technological asset appears for a second time and you still do not know how it works or what it does.
• The client does not understand all of the intricate things that you have developed or need to integrate to have his code working. That is why asserting your technological expertise is crucial.
• Client trust comes within: production-down fixes, long-running workloads without downtime and adapting their needs into reality.
• Asking for help and saying please, sometimes resolves much faster an incident. Forget about your ego, this is a teamwork game.
• An RCA report will always assert your technological expertise and make your client happier when something went bad.
• Instead of designing a very complex and full of everything diagram, try to segment it.

date: 2022-12-25
lastModified: 2022-12-26 (Typos corrected)
author: "[g5o] at [lockedinspace] dot [com] "
comments: https://news.ycombinator.com/item?id=34131337