I had an interesting conversation yesterday with someone looking for advice on how to add ‘Cloud’ to their career path. They have more than ten years experience architecting and delivering projects in enterprise IT along with a couple of ‘simple’ migrations to AWS.
They started off with a couple of questions:
- Should I try to go the ‘Solutions Architect’ or ‘DevOps Architect/Engineer’ route?
- What Clouds or areas should I specialize in?
What follows are the essentials of the advice I gave, updated upon a little bit of reflection:
Should I try to go the ‘Solutions Architect’ or ‘DevOps Architect/Engineer’ route?
First, I view adoption of Cloud and every other technology as a means to improving business outcomes. The way to do that is by helping teams delivery changes quickly, and safely because that’s how the tech organization ties into the organization’s value stream. To deliver changes quickly and safely you’ll need to know the technology stack details well, regardless of your organization’s current role definitions. Architects need to DevOps, too.
You can get pretty far with training courses, books, and blogs, but you’ll need material experience with real world projects to be effective in any role with Engineer or Architect in the title. One does not only study to become a Software or Systems Architect, it takes practice and experience as an Engineer.
So if you want to get “into” Cloud, start with a position as an Engineer responsible for delivering important aspects of a real Cloud migration or greenfield project.
Migrations are usually a bit more challenging because you’ve got to help discover all the hidden assumptions of the application’s current environment, operational practices, and data. If you want to be a Cloud Architect, this is the experience you need, because you need to build the knowledge and mindset to create environments that will support several applications and teams with a technology stack you’re not familiar with yet.
What Clouds or areas should I specialize in?
Second, I recommend focusing on a single Cloud and complementing it with basic knowledge of the other Clouds. The functionality of the hyper-scale Cloud providers is too rich and nuanced to be an expert in more than one or even “all” of one. In general, I think Kubernetes abstracts so much that it nearly counts as its own Cloud. I recommend learning Kubernetes after you’ve learned the Cloud/platform you’re going to host it on, particularly the Cloud’s networking and load balancing services. Don’t be a Jack/Jill of all Clouds and master of none.
The core AWS service set you’ll likely need as an Engineer in AWS includes: IAM, VPC, EC2, ELB, and S3. The following should get you started on Cloud and Cloud Networking:
- AWS Certified Solutions Architect 2022 – Udemy (Maarek)
- Cloud Design Patterns
- Mastering Identity at Every Layer of the Cake (AWS re:Invent 2018)
- AWS Security Fundamentals – AWS
- VPC Basics Explained
- Amazon VPC for On-premises Network Engineers
That’s quite a lot to start with, keeping in mind that I haven’t mentioned delivery tools, secret management, containers orchestrators, or ‘serverless’ tech that the application may need.
Don’t worry, you will probably spend plenty of time learning ‘unexpected’ things like details of autoscaling groups, network security, and application security — especially if you’re migrating an application out of the static climes of a classic datacenter deployment.
Cost efficient and secure Cloud deployments demand using (IMHO) the Cloud’s native autoscaling and security services and this might be the biggest change for most organizations. This change often makes Network and Security Engineers uneasy and details matter a lot.
Network and Security are where you can and should “get into” Cloud architecture because:
- there’s a big knowledge and skill gap with lots of demand (c.f. Building Security Skills for an AWS Cloud Migration)
- it’s very difficult to fix later, especially network architecture (one does not ‘simply’ move applications between networks)
Check again if you think you’ll be able to ‘just’ deploy and use your existing Enterprise Security tool in the Cloud. These tools need to keep up with your application’s rate of instance change, increased throughput, scale of your Cloud networks, and do so with high availability. If you’re not quite sure you’ve got the right answer, feel free to ping me.
By now, you should have a good foundation of training and experience that you can broaden to other Clouds or develop a specialty like Security.
The basic knowledge a Cloud Architect should have across all Clouds your organization uses is a high-level understanding of the management, fault, and security properties of each Cloud’s:
- Enterprise-level account and project organization (c.f. How should I organize my AWS accounts?)
- Identity and Access Management
- Networking
This cross-Cloud knowledge will help you determine when integration proposals will have trouble, surface the need for more investigation, or eliminate options. And if you can explain your thought process and potential solutions to others, I’m sure you can wear the mantle of Cloud Solutions Architect confidently.
Feel free to reach out to me with questions or for my full Cloud Skills Matrix.
Stephen
#NoDrama
