Full Stack Journey Episode #010: Alex Galbraith

Public clouds and public cloud services have been a recurring theme in almost every episode of the Full Stack Journey podcast. To help listeners address that need in their portfolio of skills, this episode focuses on expanding your knowledge of and skill with Amazon Web Services (AWS). Our special guest to help drive that discussion is Alex Galbraith. Alex is a solutions architect working for a global service provider. You can find him online as @alexgalbraith on Twitter, or visit his blog at http://tekhead.it.

The podcast episode is available via iTunes, or you can listen directly in your browser (assuming your browser supports HTML5 audio):

Show Notes

  • Alex has been writing quite a bit of AWS-related stuff on his site; see this page for an index to the AWS-related posts.
  • You have to invest in yourself; you can’t just expect your employer to invest in you without some effort on your part.
  • What is Alex’s view of a “full stack engineer”?
    • It’s a goal, an aspiration, something to help drive you forward.
    • Is a full stack engineer like an architect? Alex thinks there’s a lot of similarity between the idea of a full stack engineer and a well-versed architect.
    • There’s an element of “jack of all trades,” but you’ll have a couple really deep anchors of skill and expertise.
    • Another aspect of being a full stack engineer is learning to step back from the technology and be a bit more technology-agnostic. Instead, the technology should be selected based on the problem.
    • The “Input” strength from Gallup Strengths may also apply to full stack engineers (or the journey to being a full stack engineer).
  • Public cloud services are rapidly becoming a “bread-and-butter” category for IT professionals (along with automation and orchestration).
  • If you have a strong Microsoft background, Azure may be the right place for you to start. If you have more of a UNIX/Linux background, AWS or GCP might be better.
  • Also, align your public cloud learning efforts with what your peers are doing (leverage the power of your community).
  • AWS has a lot of services! Where should folks start?
    • 55 primary services on the front page of the AWS services (with multiple sub-services and configurations for each).
    • You don’t need to know every single service.
    • The key services you really need, according to Alex, are these:
      • Networking (VPCs, Route 53)
      • Security (IAM [Identity and Access Management] permissions)
      • Compute (EC2)
      • Storage (EBS [Elastic Block Storage] and S3 [object storage])
      • Databases (RDS, including Microsoft SQL Server, MySQL, Oracle)
      • Monitoring/management (CloudWatch, CloudTrail)
    • Most of these services target the 80% of the functionality users use the most
  • Many of the challenges Alex ran into while learning AWS were rooted in the differences between how on-premises infrastructure works versus how AWS works
  • When designing for the cloud, you need to design for ephemeral infrastructure that scales out—instead of applying design principles rooted in on-premises concepts and ideas
  • Be aware of terminology (for example, a “dedicated VPC” means all EC2 instances launched in that VPC will be running on dedicated hardware)
  • Good training resources that Alex used:
  • Hands-on experience is critical! Don’t be afraid to experiment—you can spin things up on demand and destroy them on demand.
  • Automation and orchestration are essential once you move past a few dozen instances
    • Use templates everywhere possible (AWS CloudFormation or Terraform; Alex recommends learning Terraform first)
    • With regards to automation, don’t try to boil the ocean—start small and build from there.
  • Are there related technologies that Alex feels are a good “fit” for use with AWS?
    • Configuration management tools (Ansible, Chef, Puppet, SaltStack)—doesn’t matter which one, just pick one and go
    • Container technologies (Docker)
    • Container orchestration (Kubernetes, Docker Swarm, Mesosphere)—doesn’t matter which one, pick the one that “shouts” at you the most and for which you can find the most resources in your circle of friends/colleagues
    • DevOps (try not to get caught up in the hype around the name)
    • Git—a strong “bread and butter” technology moving forward
    • CI (Jenkins)
  • Open Home Lab and Open Tech Cast are focused on home lab discussions—not just vSphere, but also Hyper-V and public cloud resources