Cloud Management

TODO: Get job as Dev

This is an article for those of you who are self-taught or coming out of an accelerator/bootcamp program for software development, who are wondering what’s left to do before you land that first software development job.

This is based on my experience of hiring people in this situation for several companies.

First things first; yep, you’re at a slight disadvantage vs. “classically trained” software developers or engineers from University programs.

No, that disadvantage is not insurmountable. If you combine your dev education with other attributes (like your great non-software experience), and apply it in the right role selection, you’re golden. It’s a great time to be getting into software.

Full-Stack Roles

Unlike the specialized roles that sometimes require Master’s level education in specific areas, full-stack roles are constantly available.

The reason being: small software teams need excited generalists, who can demonstrate competency throughout the tech spectrum (from updating WordPress websites to building out new infrastructure in the cloud).

You’ll find many unfilled full-stack roles in the IT / tech organizations of non-technology organizations (ex. mortgage providers, agrifood manufactures, automotive parts suppliers).

Google, Facebook, Amazon, Shopify, Square etc. are key destinations for excellent talent, and pay appropriately. Non-SaaS organizations that are doing meaningful technology work struggle in that hiring landscape and are willing to hire from bootcamp programs and develop non-degree talent in house.


Front-end refers to the part of the software that users can interact with. While it includes mobile apps and web sites, it also includes documentation, email, and social systems that accompany software solutions.

From a new-grad, employers expect:

  • Demonstrable skills in one or two modern UI technologies. In 2022 that means React + Redux, Swift, Dart/Flutter, Kotlin, etc.
    • Focusing on JavaScript + HTML + CSS + jQuery + PHP is considered an anti-pattern, despite the fact that’s required for developing and improving older websites. Not great, agreed!
  • Object-oriented design principles and design patterns: Factories, Singletons, Decorators, Observers are common-place.
    • Understanding views, models, controllers, and related patterns (MVVM and MVC).
  • Concern for user experience and design. You should have an opinion if the interface is mixing serif and non-serif fonts, image alignment is inconsistent, or the affordance of a key action is low.
  • Constructive relationships with people testing, critiquing, or evaluating your work. Testers, QA, managers, stakeholders, and clients need to have positive, creative relationships with you.
  • Examples of accurate, and well-edited technical written communication.
    • Hate to say it, but knowing how to administer a WordPress instance is a friendly docs bonus.


Most students of software start their journey on writing back-end code. Back end code is rewarding to author, testable, structured, and ripe with technology options. It’s the good stuff other devs like to look at and discuss.

Though unless your job specifically concerns DX, it tends to be far from the value your team creates. So the key skill is knowing enough to know what’s fit for purpose.

New grads are assumed to have:

  • Working knowledge of RESTful API design and protocols of the web request/response pattern (ex. Content-Type, CORS, headers, cookies) .. as REST and HTTP are the protocols of choice for modern tech.
  • Though, the future of APIs is event-driven. Academic understanding of events, buses, cloud functions is helpful.
  • Comprehensive understanding of relational databases; how to query with SQL, table design, relationships between models.
    • The technology of the DB rarely matters (Postgres, Microsoft, Oracle, MySQL, etc.) as the principles are universal.
  • Understanding how documentation stores (ex. NoSQL) and key-value caches (ex. Redis) differ from relational databases, and when to use which, is important when developing new features or products.
  • Performance monitoring and profiling in general, using tools like Firebase, Crashlytics, Microsoft Insights, Papertrail, etc. is key for keeping back-end services up and running. Practical experience in keeping your work up and running under load is great.


While often part of the “back-end”, infra is becoming a field on its own, as it can be represented as code and configuration.

This is where self-taught and bootcamp developers often have an advantage over University programs — few degree programs have infra in the curriculum.

Employers love to see:

  • Experience with a few “clouds”: Azure, AWS, or Google Cloud being the most important.
  • Understanding of the role Docker + containerization play in software deployment. Kubernetes configuration is a next-level skill, and likely not worth the attention it gets in the computing community.
  • Experience working in a work management tool (Jira, Azure DevOps, Trello etc.) with a pipeline that does integration and deployment.
  • Once again, cloud functions and storage buckets are more often the right ways to build back-end services.


Sometimes people feel that their experience in Bootcamp was great, but not enough to land them software development work. A couple of practical next-steps:

  • If you have a Bachelor’s degree in another field, and a bootcamp credential, you may qualify for a post-grad program in software development at your community college. These programs are often awesome: an intense year of programming up-skilling, sometimes coupled with a co-op program. In Kitchener-Waterloo, Conestoga College offers a program like this that I’ve hired out of several times.
  • There are many Business Analyst roles at technology companies that require expert understanding of a field, coupled with project management and technical software skills. BA roles often have career paths into QA and Solutions Engineering, and they are sometimes attached to a software team. The role may seem junior, but it puts you at the intersection of valuable business work and technology. BA also has career paths into management, sales, and other orgs. It’s a very flexible role in technology companies.
  • Software companies need application support, and support engineers who learn the deep technical aspects how software works for clients. Application Support Engineer is a fast growing field, replacing the old “customer support” + “Tier 3 developer” model into a shared role. The role generally has a well-defined career path into software development for those who stand out.

Hope you find this helpful, and good luck getting into the field!


Migrating Clouds Quickly

In August 2020, ShipperBee migrated the bulk of their business from Google Cloud Platform (GCP) to Microsoft Azure. It took us under 3 months start-to-finish, with about 4 days of panic. We managed to finish the year with a 99.5% uptime on our core services (not amazing, but really good!).

I think this was well-executed, especially for a business with a few hundred daily clients, several hundred delivery drivers, and a team of about 70 people using and operating in the platform 6 days per week.

ShipperBee’s landscape included: 2 x REST API services, 4 x web portals, an IoT/hardware support stack, Apple + Android notifications system, PostGres databases, Redis caches, and a Shopify app already running in Azure.

Here is what we did, and what I learned.

Hire + Trust the Experts

Our dev team had the will, but not quite the internal experience with Azure, to execute on a migration like this. We determined that hired-guns on a short engagement would be cheaper than hiring a full-time Azure infrastructure expert (or two) … and it definitely was.

Via our Microsoft CSP Arrow, we hired their subsidiary company, eInfoChips from India, to help with the lift. It went OK! eIC were knowledgeable about what Microsoft has to offer in Azure, about proven configurations, and which products/settings to avoid.

The most controversial example of following expert advice was using VM Scale Sets rather than Docker containers for core APIs. On the advice of their system architects, we avoided the Docker ecosystem in Microsoft since it wasn’t as well tooled for scaling, repair, price reservations, etc.

Do DevOps Yourself

I wish we had avoided leveraging our experts in setting up our DevOps / build / CI / CD pipelines. Ultimately that should be owned and managed by the people closest to the product code.

Nuances like naming convention and owners for service accounts matter in future upkeep. A contractor won’t be as concerned with those details as your team might be.

We migrated our deployment process to Azure Pipelines, rather than staying with existing Bitbucket pipelines that had been hardened over the years. There was no real need to move our deployment pipeline with our Cloud provider; it ended up being extra scope that ultimately caused a bunch of confusion and problems.

Skip the Great Inventory

Whenever you decide to move Clouds, inevitably someone will suggest you do a complete inventory of your software system, and how it interacts with every other piece (including your IT and DevOps stack).

I believed we had a thorough inventory of every GCP component that we used, and moving it would involve checking things off a list. Unless you’ve turned off the Console/Portal and everything you’ve ever put in the cloud was done explicitly via Terraform, you’ll learn more than you’ve ever wanted about vnet’s, service accounts, storage keys, and deleted users. And you’ll miss things.

Do enough of an inventory to understand the big pieces of the lift, but each instance of each service will have to be migrated independently, with care for all the small stuff around it (ex. resource groups, networking, IAM)

Aggressive Timelines are Key

Our COO decided that we had to be done the migration by September 25th for some business reason. That gave us under 3 months to complete the project. Frankly, without that arbitrary target, we’d still be “multi-cloud” and struggling to get pieces over the line many quarters later.

Having an aggressive target date helped us identify two critical “all hands on deck” weekends, which became our key milestones. One milestone involved a working Demo environment. Two weekends after that, we’d move the Production environment.

Those weekends were predictably terrible; 18 hour days, non-stop War Rooms and unexpected emergencies. Since we had the next stage scheduled for the following weekend and business resuming Monday, we just kept “failing forward” instead of responsibly reverting.

As long as things were 90% working by start of business on Monday, we explained the problems away with the COO and resolved the remaining 10% quietly during the week.

Reset your IAM and Subscriptions

My favourite part of the transition to Azure was updating our access control lists and permissions (we went to a group-based permission model after years of adding trusted dev’s as Editors or Owners to pieces), and taking advantage of the Subscription level segregation in Azure.

Subscriptions are one level higher than Projects in GCP. I created Subscriptions for Development, Production, and Integrations .. which made cost analysis for those budget items much easier. It was easy to lock down Production access since it didn’t impact the design of the Development and Integrations resources.

Hope that helps someone! I’m now a reluctant fan of Microsoft Azure. More than anything, moving clouds convinced me of the importance of good Infrastructure and DevOps talent in today’s modern software development setup.