As of the day I was dealing with Azure, the service had several bugs have not been not fixed for years. They instead released long documents for their clients to understand and to help properly workaround. Here is a quote from Azure's own cloud-services-allocation-failures page:

You may occasionally receive errors when performing these operations even before you reach the Azure subscription limits. This article explains the causes of some of the common allocation failures and suggests possible remediation. The information may also be useful when you plan the deployment of your services.

This one is simply telling me that trying to create a VM sometimes starts returning a non-temporary error, effectively means that you can't use the offering very main feature, create a new VM, unless you work around the pretty well documented bug. This error is non-deterministic unless you know about Azure internals, which is only documented in the troubleshoot document I linked above.

One of my old colleagues said this after seeing the same pattern several times: "Is this the Azure way? Write a very detailed document for a well known bug to let users to deal with it, instead of fixing the product."

Here let me tell you about what I experienced differently from AWS.

Unnecessarily complex API design and flows.
As an example, just to be able to attach a disk to a VM, one have to deal with lots of confusing terms and their Azure specific meanings: Blob (Block Blob, Page Blob), AFS, VM disk (a special kind of blob), VHD, LUN number (why do I have to care about LUN numbers?)...
Or lets take creating a VM, you first have to understand what Cloud Services and deployments are then you can create VMs, even if there are some cli tools that can create these for you, as soon as you start implementing some automation, you immediately find yourself in a position that you have to understand all these. I also remember my first time trying to deal with AWS, it felt like massive but I did't felt that desperate when I was trying to understand any AWS service for the first time. I was really frustrated when I tried to understand Azure terminology for the first time, mainly because duplicate/redundant API versions and portals I mentioned below.

API was not stable enough (it was already a 5+ year old API, since 2010), for example when I deleted a VM, even after the delete VM event reported as completed, which was taking a couple of minutes to be reported as success or failure. I can't delete the related disks for the next extra 10 minutes. This was not the only case of it's own, we hit similar problems like this one repeatedly. These cases were not documented clearly and after hitting several issues like this, our infrastructure automation was started to be polluted by this unnecessary but unavoidable checks and sleep&retry logic in many placed. This was also making debugging and troubleshooting harder in a fast paced infra environment, especially if you have many VMs being created and destroyed on the fly for different batch jobs.

Non deterministic API return codes. Some Azure API calls randomly returns 500, which is also a case for most AWS services, so not a big deal. But AWS explicitly documents these cases and covers these along with necessary retry, back-off and throttle handling mechanisms in the provided SDKs/libraries, and this is also why they always suggest to use the provided SDKs instead of implementing API clients yourself. I didn't see similar mechanism applied many places in Azure's Python SDKs (which was the one we were able to find for our automation). Our infrastructure automation code ended up being a spaghetti full of back-off and retry, logic everywhere after some stage. Since we were expecting these problems to be addressed in the provided libraries, we implemented such logic here and there, after some stage we found ourselves with a depth to be paid by us in our source code. This also could be our mistake not to study the provided libraries.

I feel like Azure API was not designed with overall architectural needs in mind. We were trying to mount external block volumes and were not able to find a proper storage driver like flocker or REX-Ray. Both were/are just running on AWS without issues, but not able to find any similar upstream tools provide similar functionality, thinking about I'm doing something wrong. I spent some time trying to find and then understand if we can implement it ourselves for our use only as a quick solution. It turned out to be buggy implementation of Azure platform, that you have to explicitly manage the order of mounted/unmounted devices. The API asks for LUN number, which effectively force one to unmount the devices in the same order they are mounted. There were some other issues in the API flow prevents this mount-the-related-blockdevice-to-a-vm-when-needed pattern to be implemented which I can't remember now on top of my head. I don't know if this is still the case, but it was around 8 moths ago.

Other one is that you can't start several machines in the same deployment. This may be a bug in the client library implementation we use (which was also provided by Azure) but we were forced to start nodes one by one in our automation. This can still be worked around but one have to design the whole automation layer with this Azure specific not-so-clearly-documented integration limits in mind. This may be my mistake to start implementing some automation without fully understanding the underlying systems but finding this kind of limits in the middle of implementation is not fun.

Other example problem was some nodes got missing suddenly(!), they never came back. We were explained by Azure support team that it "could" happen if we create more than 40 volumes in a same volume set (blob). But each nodes root directories are also blobs?!?!?!?! This effectively forced us to manually create/manage many blobs per fixed amount of nodes.

Hard to understand API(s). 2 versions, Azure Classic vs. Resource Manager. There are also 2 different portal web interfaces, Classic and New Azure portal. Both portals were not feature complete for both API versions, some features can be found on one portal cannot be found on the other, forces users to use both. This also makes understanding examples, related blog posts and documentation too hard to understand. For each resource you find you have to try to understand which version of the API is the writer is using. This is usually a time consuming guesswork since this is not obvious, you have to scan the document try to find clues to identify which one is that for.

Microsoft only tools!!! Most functionality are implemented only in powershell cli (I guess in some .NET specific technologies). We also found Python and nodejs clients, but for most functionality in their API, neither has many functionality we needed. This lack of implementation is not only in cli implementation, they are also missing in the corresponding libraries. You'll "have to" use powershell and to automate advanced stuff if you are not willing to add new functionality to the provided libraries and their cli tools and start maintaining your fork. I feel like most stuff not in the marketing materials or getting started tutorials, you'll likely forced to use Microsoft specific tools to automate.

Another example problem I experinced was on network layer. We started to migrate our infrastructure by setting up a site-to-site VPN connection between Azure and AWS. After realizing that we can't use custom routing to point a node, so this blocked us to use solutions like openswan/strongswan on a local node in a subnet. We were limited to integrations Azure provides. The documentation about VPN integrations were not clear, we decided to try our chance. It also turned out to be that after doing some network definitions, we have to download an XML modify it and upload to be able to do what we need. And this can't be automated without powershell, not from any non-powershell. This functionality was also missing in both Portals, so we can't manually do that, and also missing in Azure provided python SDK or nodejs azure cli tools. We thought that we can add this functionality to python libraries we use, we ended up not doing so because we were not able to find a sufficient documentation for corresponding API calls. A simple one-week task turned out to be a months-long hard to maintain solution, gave us headaches for each modification.

• Always use the correct OpenShift documentation (3.4 is currently the latest released version) and you can also refer to Kubernetes documentation but Kubernetes documentation is not versioned,
• oc cli tool, is mostly a wrapper around kubectl, so you can refer to better documented kubectl documentation for managing Kubernetes resources,
• Always use the same oc cli version with your OpenShift cluster,or prepare to deal with broken cluster components like registry, router, etc.,
• Don’t use the documentation pages google find’s for you, google nearly always redirects you to old versions’ documentation, always check URL google takes you to, if you familiarize yourself with the different documentation URLs :(, you can do the trick yourself: ..shift.com/container-platform/3.4/…,
• Don't expect all Kubernetes features in corresponding OpenShift version, they selectively enable alpha features,
• Don't expect to find a list about how/where OpenShift differentiates from Kubernetes (y u do this RedHat !?!?!)

Some background and how we came here

So, as I can follow it, here is a summary about OpenShift's history's impact on their documentation and open source branches. This could also tell about the current state of their documentation.

Pre-Kubernetes era (OpenShift v2)

OpenShift started with their in-house PaaS implementation:

• This was OpenShift v2, so don’t consider any v2 documentation for Kubernetes related implementation, google searches could end you up on documentation for this old different product,
• “Origin” name was also used as project name for v2, don't assume it's OpenShift v3 only,
• If you see “rhc” tool, “gear”, “cartridge” or “broker” terms in any documentation it's likely OpenShift v2, not something you want,

Re-implementation with Kubernetes (OpenShift v3)

After some stage, OpenShift decided to switch to Kubernetes, this is when they start calling it OpenShift v3.

When the switch to Kubernetes happened, they had to bump the major version of the product, and start using 3 as major version, therefore we have OpenShift v3. But while doing the transition, they decided to keep the major number in sync with Kubernetes for the open source version(Origin).

This created diversion between major versions and here is a mapping between OpenSource and Enterprise versions:

• OpenShift Enterprise 3.1 == Origin 1.1 (based on Kubernetes 1.1, minor numbers doesn’t match)
• OpenShift Enterprise 3.2 == Origin 1.2 (based on Kubernetes 1.2, minor numbers doesn’t match)

Enterprise (old) == Container Platform (new)

Recently they decided to re-brand the “Enterprise” version as “Container Platform”, so we ended up with this new mapping, they also updated the doc URLs accordingly:

• OpenShift Container Platform 3.3 == Origin 1.3 (based on Kubernetes 1.3, minor numbers doesn’t match)
• OpenShift Container Platform 3.4 == Origin 1.4 (based on Kubernetes 1.4, minor numbers doesn’t match)

Open source version (Origin) documentation is not versioned, use enterprise documentation

Open source version’s documentation is never versioned as I know, and has always been pointing to the head of development tree hence always “latest” in the URL. OpenShift Origin Latest, be careful about this one because this points to latest branch in their repo (currently unreleased 1.5). Also don't expect it to be fully up-to-date for the upcoming release.

So for open source versions (Origin 1.2, 1.3, 1.4) since you don't have versioned documentation, you can use the corresponding Enterprise version's documentation. Some feature's may differ between enterprise and open source versions, mostly on installation steps and the load-balancer for cluster masters, but the enterprise version's documentation can still help a lot.

Similar to documentation when referring to source code and ansible scripts to maintain cluster always stick to the branches for your version:

• https://github.com/openshift/origin/tree/release-1.4, not https://github.com/openshift/origin
• https://github.com/openshift/openshift-ansible/tree/release-1.4 (if you followed advanced installation)

List of documentation URLs for different releases

The open source and enterprise documentation “domains” are as well different, it's important to get familiar with the URL templates they use if you want to start with open source version:

• https://docs.openshift.org/latest/welcome/index.html (points latest in development)
• https://docs.openshift.com/container-platform/3.4/welcome/index.html (current last release)
• https://docs.openshift.com/container-platform/3.3/welcome/index.html
• https://docs.openshift.com/enterprise/3.2/welcome/index.html
• https://docs.openshift.com/enterprise/3.1/welcome/index.html
• https://developers.openshift.com/ (OpenShift v2, DON'T USE ANYTHING UNDER THIS DOMAIN)

OpenShift v.s. Kubernetes, cli and docs

• OpenShift’s oc tool is based on the kubectl codebase (I guess but didn't check), more like a wrapper around the same source code with OpenShift awareness and some extended capabilities,
• OpenShift master nodes come with kubectlsoft-linked to oc, you can have an idea about compatibility,
• OpenShift has an additional cli tool, called “oadm”. This has been integrated into “oc” tool as “oc adm” sub-command, so you can use oc adm in your laptop instead of trying to use oadm in masters, but to be able to use “oc adm” you should be using it with a user with “cluster-admin” role,
• All “oc”, “oadm”, “kubectl” commands store the credentials and context in “~/.kube” directory, and commands like “{kubectl,oc} config” mutates that file to set/keep the context ,
  
• “kubectl” documentation can be found here and you an refer to it for most “oc” sub-commands, this kubectl cheatsheet helps a lot with getting familiar with “kubectl”.

Use correct “oc” version

If you wan't to manage the cluster components from your laptop, you “have to” use the same oc client with your OpenShift cluster version. So this is must: “oc.client.version == openshift.cluster.version”, you can check both versions with oc version command.

E.g. If you use a more recent version of “oc” than your cluster, and want to install a new router, it'll likely fail. This is mostly because the “oc” cli has the logic for how to deploy a router, “oc” tool creates some Kubernetes resources in the cluster but if the cli tool does not match the cluster version, it's likely that the resources generated by newer cli version won't match the configuration of a recent OpenShift version's requirements.

If you used oc cluster up it will up a cluster with the same version with your “oc” client, so if you have old “oc” version, you'll likely get an old OpenShift cluster.

Here is my take on how your CV should be prepared if you want to move to Ireland by finding a sponsor to your working Visa. I actually wrote this as a checklist for some of my friends after seeing some common very basic mistakes in a couple of CVs.

People won't read your CV, but they will scan

People looking to hire people are usually busy and they don't have time carefully read your CV. Nobody reads CVs in detail, they just scan your CV, and scan fast. You usually have ~30 seconds to influence them to call you for the interview.

People evaluating your CV, have a role in their mind and trying to find if you are a good match for it. And the most useful way for this is trying to match keywords. Keywords are relatively easy to scan. Keyword can be a particular technology name, a methodology followed or a popular buzzword. So spread them into your CV properly. Mentioning keywords under the experience section could do the job well. People will stop scanning and check around it when they see a matching keyword to see if that is a real match. This is when most people actually read your CV. You can help people to scan your CV by making some words bold to draw their attention.

You have to make your CV extremely easy to scan, they should see keywords or particular phrases immediately. Try putting emphasis on some keywords or challenges you faced by making some words bold. Or you can also put your own challenges as your own projects (e.g. Built CI/CD Pipeline, Implemented Continuous Deployment Automation, Created Monitoring And Logging Dashboards). This could also make the reviewers life a lot easier.

People will expect to see your most fresh knowledge or experience first

They will expect to see your recent experience and up-to-date status of knowledge first. So move your recent hot topics to the top as much as you can. They can be in any form,as a career summary, as your experiences, a keyword list or your areas of interest. I suggest to put a career summary since this is your chance to tell about your profession and experience in relation to your job target.

As people progress into the following pages, they think the content will start to get less relevant to your recent expertise. And whatever written after the second page could simply be ignored as your "archaic"experience. I'm not saying that your CV has to be a few pages, but be careful about what you put into first few pages.

Putting your full address, education, personal details like nationality, date of birth, languages you know into very top of your CV is not a good idea. Most details other than your name and contact info will just distract people from understanding your experience. If you really want to put that kind of less relevant information, move them to end of the CV.

First barrier: Passing HR review

Your CV must survive 2 main levels of review. First level is HR, and if not eliminated, then it can progress to next level, technical people. Unless you never apply without a referral, you have to understand how HR works. Here are some techniques I guess HR are using.

Since HR has lower level of understanding what you do, they more often depend on matching keywords and estimating your experience level based on written experience.

There is a significant importance about putting as many keywords as you can into your CV because
some companies and recruiters uses automatic CV scanning softwares which are highly depending on keyword matching. Or recruiters sometimes use queries like this one (try to paste it into linkedin search box):
docker AND (mesos OR marathon OR kubernetes OR k8s) AND (ansible OR chef OR puppet OR salt OR saltstack) AND (python OR ruby OR perl OR golang OR nodejs) AND bash AND (c OR c++ OR java OR scala) AND (nfs OR glusterfs OR ceph) AND (gitlab OR gocd OR rundeck OR bamboo OR jenkins)

Second barrier: Passing technical guy review

Put what "you" did, not what your team did. And use an achiever language rather then a doer language.

It is more relevant to put your achievements, contributions and the differences you made in a project; rather than tasks assigned to you, your daily duties or what your team delivered. So while writing your experiences try to impress the reader and try to create excitement while people are reading your CV. Try not to tell the project or it's importance, instead tell how exactly you contributed or which parts did you own and how did you make a success story out of it.

You should also mention the technologies and techniques you used in your projects. This gives hint about your expertise. E.g. HyperV, VMWare, XEN or KVM, all could be called as virtualization, but if you don't mention the technology, you can't know what will the reader understand.

Less relevant information last

If not so relevant to your recent career you should move your education below your experience section.If someone really want to see what you studied they'll likely look for it, but this could highly triggered by your experiences. What you studied is relatively less important if you are not a new grad.

In development and DevOps, people usually don't care about your nationality, which languages you know (and levels for each), your age, your interests. You can completely drop them or move to bottom of your CV.

Similar for the courses, seminars, certificates, references. Place them to bottom.

Your name is the title of the paper

And try to put your name big and clear on top. So if someone is searching for your CV in a pile, they can find your CV fast. This also makes people to remember your name. Don't write it in small fonts as a regular text. It's more like the title of the book, not a text with emphasis.