Jekyll2018-03-30T04:27:26+00:00http://fullstackjourney.com/The Full Stack JourneyThe Full Stack Journey podcast is about the ongoing journey to becoming a full stack engineer, an IT pro who can move among multiple silos and work across multiple layers of the modern data center stack. Listen to others talk about their journey, the choices they've made along the way, and tips and tricks to help you on your journey.Scott Lowescott@fullstackjourney.comWe’ve Moved2017-04-27T00:00:00+00:002017-04-27T00:00:00+00:00http://fullstackjourney.com/2017/04/27/weve-moved<p>That’s right, the Full Stack Journey podcast has moved! We’re now part of the Packet Pushers network of podcasts. You can read more about the move over <a href="http://packetpushers.net/full-stack-journey-joins-packet-pushers/">here at the Packet Pushers site</a>.</p>
<p>Moving forward, all new episodes will be published via Packet Pushers. The landing page for the Full Stack Journey podcast is <a href="http://packetpushers.net/full-stack-journey">here</a>, so check there for new episodes. Right now, we’re in the process of publishing old episodes so that the feed doesn’t get overloaded.</p>
<p>We’ll continue to maintain the <a href="https://twitter.com/fsjpodcast">Full Stack Journey Twitter account</a>, so follow that account if you want to stay up-to-date on the transition to the Packet Pushers or news about new episodes.</p>
<p>Thanks for listening!</p>sloweThat’s right, the Full Stack Journey podcast has moved! We’re now part of the Packet Pushers network of podcasts. You can read more about the move over here at the Packet Pushers site.Full Stack Journey Episode #010: Alex Galbraith2016-10-15T00:00:00+00:002016-10-15T00:00:00+00:00http://fullstackjourney.com/2016/10/15/full-stack-journey-ep010<p>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 <a href="https://twitter.com/alexgalbraith">@alexgalbraith on Twitter</a>, or visit his blog at <a href="http://tekhead.it">http://tekhead.it</a>.</p>
<p>The podcast episode is <a href="https://itunes.apple.com/us/podcast/the-full-stack-journey/id1073172158?mt=2">available via iTunes</a>, or you can listen directly in your browser (assuming your browser supports HTML5 audio):</p>
<audio controls="">
<source src="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-010.mp3" type="audio/mpeg" />
If you're seeing this message, your browser does not support HTML5 audio elements.</audio>
<h2 id="show-notes">Show Notes</h2>
<ul>
<li>Alex has been writing quite a bit of AWS-related stuff on his site; see <a href="http://tekhead.it/blog/2016/07/index-of-tekhead-it-blog-posts-on-amazon-aws/">this page</a> for an index to the AWS-related posts.</li>
<li>You have to invest in yourself; you can’t just expect your employer to invest in you without some effort on your part.</li>
<li>What is Alex’s view of a “full stack engineer”?
<ul>
<li>It’s a goal, an aspiration, something to help drive you forward.</li>
<li>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.</li>
<li>There’s an element of “jack of all trades,” but you’ll have a couple really deep anchors of skill and expertise.</li>
<li>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.</li>
<li>The “Input” strength from <a href="http://strengths.gallup.com/default.aspx">Gallup Strengths</a> may also apply to full stack engineers (or the journey to being a full stack engineer).</li>
</ul>
</li>
<li>Public cloud services are rapidly becoming a “bread-and-butter” category for IT professionals (along with automation and orchestration).</li>
<li>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.</li>
<li>Also, align your public cloud learning efforts with what your peers are doing (leverage the power of your community).</li>
<li>AWS has a <em>lot</em> of services! Where should folks start?
<ul>
<li>55 primary services on the front page of the AWS services (with multiple sub-services and configurations for each).</li>
<li>You don’t need to know <em>every</em> single service.</li>
<li>The key services you really need, according to Alex, are these:
<ul>
<li>Networking (VPCs, Route 53)</li>
<li>Security (IAM [Identity and Access Management] permissions)</li>
<li>Compute (EC2)</li>
<li>Storage (EBS [Elastic Block Storage] and S3 [object storage])</li>
<li>Databases (RDS, including Microsoft SQL Server, MySQL, Oracle)</li>
<li>Monitoring/management (CloudWatch, CloudTrail)</li>
</ul>
</li>
<li>Most of these services target the 80% of the functionality users use the most</li>
</ul>
</li>
<li>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</li>
<li>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</li>
<li>Be aware of terminology (for example, a “dedicated VPC” means all EC2 instances launched in that VPC will be running on dedicated hardware)</li>
<li>Good training resources that Alex used:
<ul>
<li><a href="https://www.udemy.com/">Udemy</a></li>
<li><a href="https://acloud.guru/">A Cloud Guru</a> (a bit exam-focused)</li>
<li><a href="https://linuxacademy.com/">Linux Academy</a></li>
<li><a href="https://cloudacademy.com/">Cloud Academy</a></li>
<li><a href="https://aws.amazon.com/whitepapers/">AWS white papers</a></li>
<li><a href="https://aws.amazon.com/documentation/">AWS documentation site</a></li>
<li>Meetups via <a href="https://www.meetup.com/">meetup.com</a>
<ul>
<li>AWS meetups</li>
<li>Serverless meetups</li>
<li>“CloudCamp” (in the UK)</li>
</ul>
</li>
<li>Content from AWS re:Invent (<a href="https://www.youtube.com/user/AmazonWebServices">video recordings</a> or <a href="http://www.slideshare.net/AmazonWebServices/">slide presentations</a>)</li>
</ul>
</li>
<li>Hands-on experience is critical! Don’t be afraid to experiment—you can spin things up on demand and destroy them on demand.</li>
<li>Automation and orchestration are essential once you move past a few dozen instances
<ul>
<li>Use templates everywhere possible (AWS CloudFormation or <a href="https://www.terraform.io/">Terraform</a>; Alex recommends learning Terraform first)</li>
<li>With regards to automation, don’t try to boil the ocean—start small and build from there.</li>
</ul>
</li>
<li>Are there related technologies that Alex feels are a good “fit” for use with AWS?
<ul>
<li>Configuration management tools (<a href="https://www.ansible.com/">Ansible</a>, <a href="https://www.chef.io/">Chef</a>, <a href="https://puppet.com/">Puppet</a>, <a href="https://saltstack.com/">SaltStack</a>)—doesn’t matter which one, just pick one and go</li>
<li>Container technologies (<a href="https://www.docker.com/">Docker</a>)</li>
<li>Container orchestration (<a href="http://kubernetes.io/">Kubernetes</a>, Docker Swarm, <a href="https://mesosphere.com/">Mesosphere</a>)—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</li>
<li>DevOps (try not to get caught up in the hype around the name)</li>
<li><a href="https://git-scm.com/">Git</a>—a strong “bread and butter” technology moving forward</li>
<li>CI (<a href="https://jenkins.io/index.html">Jenkins</a>)</li>
</ul>
</li>
<li><a href="https://openhomelab.org/index.php?title=Main_Page">Open Home Lab</a> and <a href="http://www.opentechcast.com/">Open Tech Cast</a> are focused on home lab discussions—not just vSphere, but also Hyper-V and public cloud resources</li>
</ul>sloweIn episode 10, I'm joined by Alex Galbraith to talk about how to wrap your mind and your skill set around the extensive set of services offered by Amazon Web Services (AWS).Full Stack Journey Episode #009: Jake Robinson2016-10-06T00:00:00+00:002016-10-06T00:00:00+00:00http://fullstackjourney.com/2016/10/06/full-stack-journey-ep009<p>This episode is a very special episode of the Full Stack Journey podcast, recorded live at the Dallas-Ft. Worth VMUG UserCon on Thursday, September 29, 2016. This special episode continues our series of looking at individual technologies that are necessary steps along the “full-stack journey.” Joining Scott on this episode is Jake Robinson (@jakerobinson <a href="https://twitter.com/jakerobinson">on Twitter</a> as well as <a href="https://github.com/jakerobinson/">on GitHub</a>), an automation specialist at VMware, Inc. Naturally, the conversation centers on automation, why automation is important, and getting started with automation.</p>
<p>The podcast episode is <a href="https://itunes.apple.com/us/podcast/the-full-stack-journey/id1073172158?mt=2">available via iTunes</a>, or you can listen directly in your browser (assuming your browser supports HTML5 audio):</p>
<audio controls="">
<source src="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-009.mp3" type="audio/mpeg" />
If you're seeing this message, your browser does not support HTML5 audio elements.</audio>
<p>Enough introductions, let’s jump right in!</p>
<h2 id="show-notes">Show Notes</h2>
<ul>
<li>Jake is a development manager for Project Zombie, an orchestration framework that drives a lot of the automation behind VMware’s vCloud Air service.</li>
<li>Having automation is important, but scale of one’s learning ability is also important.</li>
<li>The rise of the software-defined data center has also given rise to a new archetype, the “data center developer,” who leverages automation tools, APIs, scripting languages, etc., to programmatically define and orchestrate resources within a software-defined data center.</li>
<li>Automation is driven by business needs—to move more quickly, to stay ahead of the competition. The business needs demand that we (IT professionals) are able to deliver software and/or infrastructure more quickly and more consistently.</li>
<li>Jake finds that learning happens best when centered around a “problem,” a key thing you’re trying to solve. This is especially true for automation and/or learning programming/scripting languages.</li>
<li><a href="https://developercenter.vmware.com/web/dp/tool/vsphere_powercli/6.3">PowerCLI</a> is an outstanding interface to vSphere, and offers a really easy learning curve for folks getting started in automation.</li>
<li>Running reports–like listing all the VMs in your environment, or something similar—is a useful way to get started with PowerCLI.</li>
<li>So how does one help build “programmatic thinking” skills?
<ul>
<li><a href="https://www.codecademy.com/">CodeAcademy</a> is a good tool you can use to interactively play with various languages, and allows you to build your “programmatic thinking” skills.</li>
<li><a href="https://scratch.mit.edu/">Scratch</a> is another tool, oriented a bit more towards children, that can be used to help build “programmatic thinking” skills. The <a href="http://www.robotturtles.com/">board game Robot Turtles</a> is another tool (again oriented toward children).</li>
<li>Using these kid-centric tools offers a secondary purpose as well: it helps encourage your kids to be involved in developing these sorts of skills in a way that also helps promote work-life balance.</li>
</ul>
</li>
<li>It’s OK to admit you don’t know something, and ask the “dumb question.” You just have to be brave enough to ask the question.</li>
<li><a href="https://ifttt.com/">IFTTT.com</a> is another, easy-to-use way to build programmatic thinking and incorporating automation into your regular workflows.</li>
<li>Learning automation doesn’t necessarily have to be data center-focused.</li>
<li>Along the lines of “low-hanging fruit” that listeners can tackle as an easy first project, reports (as mentioned earlier) are a great way to get started.
<ul>
<li>Start with simple reports on your VMs.</li>
<li>Then add more information.</li>
<li>Next, add some formatting of the output.</li>
<li>You can then have the report delivered to you via e-mail on a regular basis.</li>
<li>As you can see, you can start small and build upon your success as you go.</li>
</ul>
</li>
<li>Digging into other peoples’ code can be helpful in your own learning journey.</li>
<li>While your early code doesn’t have to be perfect, you do have to balance the accrual of <a href="https://en.wikipedia.org/wiki/Technical_debt">technical debt</a>.
<ul>
<li>Don’t have expectations that are too high for your early code projects. Every task you automate is a learning process, and your code will get better over time.</li>
<li>Set reasonable goals for yourself.</li>
<li>It can be helpful to break a larger problem down into a number of smaller problems. This goes back to “programmatic thinking” (being able to break a problem down into the steps required to fix a problem).</li>
</ul>
</li>
<li>DRY = Don’t Repeat Yourself</li>
<li>Don’t expect to write perfectly DRY code in the beginning—give yourself room to learn and get better over time.</li>
<li>For Jake, learning the language was the easy part, and those skills tend to apply themselves to other programming languages. The hard part was the associated “tooling” that accompanies a language.</li>
<li>Practice, practice, practice—it’s the only way to get better. There’s no easy road. It will take effort in order to improve.</li>
<li>Other tools that might be helpful:
<ul>
<li>Online communities (don’t be afraid to ask the “dumb” questions!) are a good resource.</li>
<li>When it comes to communities, you’ll get out of it what you put into it.</li>
<li>In-person meetups can also be helpful.</li>
</ul>
</li>
<li>Keep in mind that automation takes many forms—not just scripting.</li>
<li>Determine the right tool to use, and then you can find resources to help learn/use that tool.</li>
<li>What is the best tool to use/learn? “It depends.” Of course! A few resources that Jake likes:
<ul>
<li><a href="https://puppet.com/">Puppet</a> is a good tool for managing desired state of a node.</li>
<li>Maybe combine a tool like <a href="https://www.ansible.com/">Ansible</a> (for orchestrating multiple tasks) and Puppet for managing node state.</li>
<li>Of course, there’s also PowerCLI, as mentioned earlier.</li>
</ul>
</li>
<li>If you’re new to “programmatic thinking,” use some of the tools described earlier to help build those skills.</li>
<li>If you’re familiar with a scripting language, push yourself to learn a new language, new tool, or new framework.</li>
</ul>sloweEpisode 9 is a special episode of the Full Stack Journey, recorded on-site at the Dallas-Ft. Worth VMUG UserCon. This episode's special guest is Jake Robinson, who talks about automation, its importance, and getting started with automation.RSS Feeds and HTML5 Audio2016-09-20T00:00:00+00:002016-09-20T00:00:00+00:00http://fullstackjourney.com/2016/09/20/rss-feeds-updated<p>In response to some listener feedback, I’ve updated the RSS feeds here on the Full Stack Journey web site, and added HTML5 audio support. The RSS feed changes are intended to help address problems subscribing to the podcast feed using a podcast application; if you run into any issues getting access to the podcast episodes, please let me know so that I can make additional adjustments/changes as needed.</p>
<ul>
<li>The RSS feed for the podcast episodes is <a href="http://fullstackjourney.com/podcast.xml">here</a>. You can use this feed in your podcaster to get the podcast episodes. However, I recommend using <a href="https://pcr.apple.com/id1073172158">the iTunes mirror feed</a> instead, in the event that the direct podcast feed ever changes or needs to change.</li>
<li>To get only the articles from the web site (and not the podcast episodes themselves), use <a href="http://fullstackjourney.com/feed.xml">this RSS feed</a>. You can use this feed in your RSS reader (or equivalent).</li>
<li>On the web site itself, I’ve updated the visual representations to show that there is an RSS feed for articles and a separate RSS feed for episodes. You can see this new visual representation at the bottom of the site.</li>
</ul>
<p>Additionally, I’ve added HTML5 audio support to each podcast episode post, which will allow users with browsers that support HTML5 audio to listen to a podcast episode directly in their browser.</p>
<p>Hopefully these changes make it easier to find episodes, listen to episodes, and stay connected with the Full Stack Journey podcast. If you have any additional feedback, feel free to hit up <a href="https://twitter.com/fsjpodcast">the Full Stack Journey podcast on Twitter</a>. Thanks!</p>sloweIn response to some listener feedback, I’ve updated the RSS feeds here on the Full Stack Journey web site, and added HTML5 audio support. The RSS feed changes are intended to help address problems subscribing to the podcast feed using a podcast application; if you run into any issues getting access to the podcast episodes, please let me know so that I can make additional adjustments/changes as needed.Full Stack Journey Episode #008: Ivan Pepelnjak2016-09-09T00:00:00+00:002016-09-09T00:00:00+00:00http://fullstackjourney.com/2016/09/09/full-stack-journey-ep008<p>Continuing in our series of episodes focusing on particular technologies within the broader journey to being a full stack engineer, episode #8 features Ivan Pepelnjak, well-known author, <a href="http://blog.ipspace.net/">blogger</a>, <a href="http://www.ipspace.net/Podcast">podcaster</a>, and speaker. Ivan produces a phenomenal amount of content around networking and adjacent technologies (check it out <a href="http://content.ipspace.net/bin/start">here</a>), and is active <a href="https://twitter.com/ioshints/">on Twitter</a> as well.</p>
<p>As always, you can get the podcast <a href="https://itunes.apple.com/us/podcast/the-full-stack-journey/id1073172158?mt=2">via iTunes</a>, or you can <a href="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-008.mp3">download the MP3 file directly</a>. You can also listen to the podcast directly in your browser using the controls below (assuming your browser supports HTML5 audio):</p>
<audio controls="">
<source src="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-008.mp3" type="audio/mpeg" />
If you're seeing this message, your browser does not support HTML5 audio elements.</audio>
<p>Enjoy!</p>
<h2 id="show-notes">Show Notes</h2>
<ul>
<li>While there is value in talking about T-shaped skills, I-shaped skills, and Pi-shaped skills (see <a href="https://bizthoughts.mikelee.org/t-shaped-skills-i-shaped-skills-and-dash-shaped-skills.html">this article</a> for a brief explanation of some of these terms, which may be new to you; Pi-shaped skills are like T-shaped but with an additional “leg” or area of expertise), Ivan believes it’s really about being able to communicate with colleagues who are “right and left” of you (adjacent to your current role).
<ul>
<li>For networking professionals, this means you have to understand how servers and virtualization work, and how storage is different from TCP/IP (for example).</li>
<li>You can’t be an expert in these adjacent areas, but you have to know enough to understand to communicate effectively and grasp their problems/challenges.</li>
</ul>
</li>
<li>Ivan uses a story about learning economics to illustrate that it’s not about being an expert, but knowing enough to understand what others are saying.</li>
<li>As concrete examples:
<ul>
<li>If you’re a data center networking professional, you’d better understand how VMware’s virtual switch works (because you’ll see it in almost every enterprise data center).</li>
<li>If you’re a server admin, you need to know what <code class="highlighter-rouge">ping</code> is, how ARP works, and how to take traces with <code class="highlighter-rouge">tcpdump</code> or Wireshark, and how to test to make sure your connections are actually going through.</li>
</ul>
</li>
<li>You won’t learn anything unless you get out of your comfort zone. At the same time, find something reasonably close to what you’re already doing to streamline the learning process. It also has to be hard.</li>
<li>So where should today’s network engineers start when trying to expand their skills?
<ul>
<li>For data center networking engineers, Ivan recommends learning virtualization and virtual switching.</li>
<li>For WAN engineers, Ivan would suggest working with VPN technologies.</li>
<li>For a campus network engineer, Wi-Fi would be a great start to expanding your knowledge.</li>
<li>Everyone should try to understand how applications work and what’s going on behind a distributed application.</li>
</ul>
</li>
<li>“Mean time to innocence” - how long it takes to prove it’s not the network’s fault.</li>
<li>For data center network engineers, Ivan strongly recommends learning <a href="http://www.vmware.com/vsphere.html">VMware vSphere</a>; or, for a purely Microsoft-centric organizations, <a href="https://www.microsoft.com/en-us/cloud-platform/virtualization">Hyper-V</a>. Why? These products are mature, they work as expected, and the documentation is typically complete, comprehensive, and well-organized.</li>
<li>Open source projects may be more difficult for network engineers to learn because documentation may not be as complete or comprehensive, and it may not always work as expected.</li>
<li>Use what your peers are using (when it comes to learning either vSphere or Hyper-V or choosing an automation tool); this helps when you get stuck or need help in your learning efforts.</li>
<li>Should network engineers learn network automation first or virtualization first? Ivan believes network automation skills are <em>very</em> important, and this is something a lot of network engineers haven’t yet embraced.
<ul>
<li>To get started, choose some “low-hanging fruit”—things that are relatively easy to accomplish and will be low-impact (so you don’t accidentally blow up the core switch).</li>
<li>Low-hanging fruit that will help network engineers get started with network automation: generating configurations from a template, and using a configuration management tool to perform simple configuration changes (like configuring a VLAN).</li>
</ul>
</li>
<li>Many network engineers haven’t developed strong “computational thinking”—what exactly are the steps I have to take to get to the result? This can hinder efforts to embrace network automation tools.</li>
<li>According to Ivan, when you can explain your troubleshooting process to an absolute idiot, you’re ready for automation.</li>
<li>The concept of data models is another area many network engineers haven’t fully grasped—how to represent the data that is needed to perform a task in a series of steps.</li>
<li>There are some great books (found in the “Additional Resources” section below) that may be helpful for non-network engineers to get started in networking.</li>
<li>Always ask, “Why?” Ask yourself, “What is the problem this particular technology/feature/configuration is trying to solve?” This helps you understand the concepts and ideas behind a particular technology, feature, or configuration, and helps you understand when it is best used.</li>
<li>Always try to build a mental model of where things fit in and how they relate to other technologies. (In other words, keep your mind like a tidy, well-organized closet.)</li>
<li>Learning as many tools as possible so that you have the right tool for the job.</li>
<li>Ivan believes it would be <em>very</em> helpful for non-network engineers to understand the physical characteristics of networks: bandwidth, delay, latency, etc. See how those characteristics affect applications. Perform some packet captures to see how things are happening underneath.</li>
<li>It would also be very helpful for application developers to better understand how to build resilient applications that work better across a network (or are better behaved across a network).</li>
<li>Becoming a presenter is a great career move. It forces you to more fully learn the subject material, forces you to organize your mental model (how you think about something), and forces you to simplify things down (which in turns helps reinforce bigger picture thinking). Finally, it really helps you learn.</li>
<li>You can also gain some of the same benefits from blogging, creating videos, etc.</li>
<li>If you’re wondering how to get presentation opportunities, think about making presentations within your own organization—talk to other IT groups, other colleagues, etc. This also helps build relationships across teams and silos within your organization.</li>
<li>Take a presentation skills course.</li>
</ul>
<h2 id="additional-resources">Additional Resources</h2>
<p><em>Computer Networks (5th Edition)</em> by Andrew Tannenbaum<br />
<em>TCP/IP Illustrated, Vol 1: The Protocols</em> by Richard Stevens (available <a href="https://www.amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Professional/dp/0201633469">via Amazon</a>)<br />
The <em>Routing TCP/IP</em> books by Jeff Doyle (<a href="https://www.amazon.com/Routing-TCP-IP-1-2nd/dp/1587052024/">volume 1</a> and <a href="https://www.amazon.com/Routing-TCP-IP-Professional-Development/dp/1587054701/">volume 2</a>)<br />
<em>High Performance Browser Networking</em> by Ilya Grigorik (available online <a href="https://hpbn.co/">here</a>)<br />
<em>Scalability Rules</em> by Marty Abbott and Michael Fisher (see <a href="http://scalabilityrules.com/">here</a>)</p>sloweIn Episode 8, we dive into the world of networking with long-time expert Ivan Pepelnjak. Ivan shares some recommendations on expanding your skill sets for IT pros both within and outside the networking space.Full Stack Journey Episode #007: Ed Horley2016-08-17T00:00:00+00:002016-08-17T00:00:00+00:00http://fullstackjourney.com/2016/08/17/full-stack-journey-ep007<p>Episode #7 is the first in a series of episodes focusing more on specific areas within a broader journey to being a full stack engineer. The guest for this episode is Ed Horley (<a href="https://twitter.com/ehorley">@ehorley</a> on Twitter), who leads the cloud practice team for a VAR in the Silicon Valley/Bay area of California. Ed may better be known as the “crazy IPv6 dude” but today he’s on the podcast talking about business awareness and managerial aspects, and what that means for someone’s full stack journey. Ed has <a href="http://www.howfunky.com/">his own blog</a>, and also <a href="https://community.infoblox.com/t5/user/viewprofilepage/user-id/20824">blogs about IPv6 at the InfoBlox community site</a>.</p>
<p>You can get episode 7 <a href="https://itunes.apple.com/us/podcast/the-full-stack-journey/id1073172158?mt=2">via iTunes</a>, or you can <a href="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-007.mp3">download the MP3 file directly</a>. You can also listen to the podcast directly in your browser using the controls below (assuming your browser supports HTML5 audio):</p>
<audio controls="">
<source src="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-007.mp3" type="audio/mpeg" />
If you're seeing this message, your browser does not support HTML5 audio elements.</audio>
<p>There are some audio quality issues at around 41-42 minutes of the podcast recording that I couldn’t, unfortunately, edit out. I’m sorry about that, but I hope you enjoy the episode nevertheless.</p>
<h2 id="show-notes">Show Notes</h2>
<ul>
<li>Ed feels like the full stack journey is valuable because it’s about learning how to build better solutions to solve business problems
<ul>
<li>It’s helpful for folks at the top of the stack to move down and learn more</li>
<li>Helpful for infrastructure folks to move up the stack as well</li>
<li>Still need folks who understand the whole solution end-to-end</li>
</ul>
</li>
<li>The good thing about cloud computing (public or private cloud) provides exposure to a lot of different areas, which is helpful</li>
<li>New generations of IT pros, who come up on cloud computing concepts, don’t have preconceived notions about how infrastructure is built or what infrastructure is</li>
<li>There’s value in the questions asked by newcomers, it can force you to re-evaluate choices you’ve made</li>
<li>Importance to work and think strategically, not tactically
<ul>
<li>It’s not just about learning a new technology, how to implement it, and how to apply it to solve business problems</li>
<li>Ask questions like “Where do we want to go?” or “Why do we want to go there?” Ask about technologies that are emerging, why they’re emerging, and what it means for the industry and for your business.</li>
<li>Thinking strategically not only benefits the business but also benefits you personally—it helps you understand where the industry may be headed or how it may affect your business.</li>
<li>Adding new tools to your toolbelt is almost always beneficial, and thinking strategically adds tools to your toolbelt</li>
<li>Tactical is how to get from A to B, strategic is about understanding why you need to get from A to B and what that means for your career, your business, and your industry</li>
</ul>
</li>
<li>Talk to your management team—they may be able to help with your technical journey in a way that also benefits the business and the rest of your organization</li>
<li>As a manager, it’s important to manage your team’s career development and technical skills</li>
<li>It’s important to understand what your business does and how it fits into the overall industry. You can’t be aligned with the business if you don’t know anything about the business, what it’s trying to do, or the challenges it’s facing.</li>
<li>Need to regularly step back and re-assess the alignment with the business. It’s difficult for an individual contributor, but it’s still really important.</li>
<li>How does one better understand his or her business?
<ul>
<li>Read your company’s website!</li>
<li>Talk to your company’s sales and marketing teams—they have a deep understanding of why customers are choosing your company’s products or solutions over those of a competitor.</li>
<li>Meet and greet colleagues in your organization in other business units when opportunities arise.</li>
<li>Ask other business units about their strategic goals.</li>
</ul>
</li>
<li>You don’t get promoted if you don’t get recognized, either by your peers or your management. Talk to your management!</li>
<li>Moving into a management role means sacrificing some technical skills for managerial, career development, and leadership/teamwork skills.</li>
<li>Face-to-face communications is <em>really</em> important for a manager. Looking back, Ed would have spent more time (2x to 3x) more time face-to-face with his team, building empathy and compassion, when he first transitioned from individual contributor to manager.</li>
<li>Blameless port-mortems can be really helpful and important in building effective teams—not only from an individual contributor perspective, but also from a management perspective as well.</li>
</ul>sloweIn Episode 7, I talk with Ed Horley about business awareness, business alignment, and managerial challenges that are so often overlooked by IT professionals.Full Stack Journey Episode #006: A Quick Review2016-08-01T00:00:00+00:002016-08-01T00:00:00+00:00http://fullstackjourney.com/2016/08/01/full-stack-journey-ep006<p>Episode 6 is a bit different than the previous 5 episodes. There’s no guest on this episode; it’s just me (Scott, the host) talking about what was shared in the first five episodes, and reflecting on what this means. What was the conclusion? Sorry, no spoilers here—you’ll have to listen to the episode (available <a href="https://itunes.apple.com/us/podcast/the-full-stack-journey/id1073172158?mt=2">via iTunes</a> or <a href="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-006.mp3">downloadable directly from S3</a>) for all the details. If your browser support HTML5 audio, you can also listen to the podcast directly in your browser:</p>
<audio controls="">
<source src="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-006.mp3" type="audio/mpeg" />
If you're seeing this message, your browser does not support HTML5 audio elements.</audio>
<p>Thanks for listening!</p>sloweEpisode 6 is a review episode, where I take a look back at the first five episodes, talk about what's been shared, and then share what this means for the full stack journey and for the podcast.Podcast News2016-05-28T00:00:00+00:002016-05-28T00:00:00+00:00http://fullstackjourney.com/2016/05/28/podcast-news<p>Welcome to the new web site for the Full Stack Journey Podcast! If you’re not familiar with the Full Stack Journey Podcast, it’s a monthly podcast featuring guests who are pursuing the goal of being a “full stack engineer”—that is, someone who is able to work across silos and move among different layers of the modern data center stack. The goal of the podcast is to provide <em>practical</em>, <em>actionable</em>, and <em>useful</em> information to help listeners get started or continue with their own journey.</p>
<p>You can subscribe to the Full Stack Journey Podcast <a href="https://itunes.apple.com/us/podcast/full-stack-journey/id1073172158?mt=2">via iTunes</a>.</p>
<p>In concert with the launch of the new web site, a number of other things are happening as well:</p>
<ul>
<li>The podcast is migrating away from SoundCloud. If you’ve subscribed to the podcast using SoundCloud, I recommend switching to <a href="http://fullstackjourney.com/podcast.xml">the direct podcast feed</a> or to <a href="https://pcr.apple.com/id1073172158">the iTunes mirror feed</a>. (The iTunes mirror feed is generally recommended, in the event the URL for the direct feed changes at some point in the future.)</li>
<li>In addition to the podcast feed, there’s also <a href="http://fullstackjourney.com/feed.xml">an RSS feed for the web site itself</a>. The site’s RSS feed contains the show notes for each episode as well as general information (like this post).</li>
<li>The Full Stack Journey Podcast also has <a href="https://twitter.com/fsjpodcast">a new Twitter account</a>, where information about the podcast and/or podcast episodes will be posted.</li>
</ul>
<p>Finally, the show is looking for potential guests! If you feel you have information that would help listeners in their “full stack journey,” then feel free to drop me an e-mail (scott at fullstackjourney dot com).</p>sloweWelcome to the new web site for the Full Stack Journey Podcast! If you’re not familiar with the Full Stack Journey Podcast, it’s a monthly podcast featuring guests who are pursuing the goal of being a “full stack engineer”—that is, someone who is able to work across silos and move among different layers of the modern data center stack. The goal of the podcast is to provide practical, actionable, and useful information to help listeners get started or continue with their own journey.Full Stack Journey Episode #005: Patrick Kelso2016-05-19T00:00:00+00:002016-05-19T00:00:00+00:00http://fullstackjourney.com/2016/05/19/full-stack-journey-ep005<p>Episode #5 of the Full Stack Journey Podcast features Patrick Kelso, an independent consultant based in Australia. (Patrick is <a href="https://github.com/patrickkelso/">patrickkelso on GitHub</a> and <a href="https://twitter.com/patrickkelso">on Twitter</a>.) He works predominantly in the UNIX/virtualization/cloud space. He spent quite a number of years at EMC, then branched out and made the move to <a href="https://puppet.com/">Puppet</a>. Since then, he’s started working on his own. Patrick is based on Sydney, Australia.</p>
<p>This episode of the podcast is available <a href="https://itunes.apple.com/us/podcast/the-full-stack-journey/id1073172158?mt=2">from iTunes</a>, or you can <a href="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-005.mp3">download the MP3 file directly</a>. If your browser supports HTML5 audio, you can also listen to the podcast directly in your browser:</p>
<audio controls="">
<source src="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-005.mp3" type="audio/mpeg" />
If you're seeing this message, your browser does not support HTML5 audio elements.</audio>
<h2 id="show-notes">Show Notes</h2>
<ul>
<li>Patrick’s view of a full stack engineer is similar to my own—an engineer who’s comfortable working across multiple technology domains. A full stack engineer doesn’t restrict himself or herself to one silo; instead, they understand multiple silos: networking, APIs, automation, etc.</li>
<li>This broader view of the various silos and layers of the data center stack gives a full stack engineer the ability to communicate more effectively with other IT teams.</li>
<li>As opposed to a generalist, a full stack engineer typically has one technology domain where he or she is strongest and deep technical expertise. For Patrick, he’s currently focusing on automation.</li>
<li>Patrick references a presentation by John Mark Troyer (recording <a href="https://www.youtube.com/watch?v=iNmeXOKH05M">here on YouTube</a>) talking about a “pie-shaped” skill set. In a pie-shaped skill set, you have deep knowledge on one thing with more general knowledge on other things, but you’re already cultivating/building the deep skill set on “the next thing.”</li>
<li>Patrick was pulled into using Puppet through a job he was doing for a client, where the use of Puppet made compliance audits incredibly simple and easy.</li>
<li>Other things he’s spending time with now: other configuration management tools, cloud providers (<a href="https://aws.amazon.com/">AWS</a>, <a href="https://azure.microsoft.com/en-us/">Azure</a>), and even some “non-sexy” technologies like Oracle Solaris and HP OpenView.</li>
<li>However, even when using “older” technologies he always asks about how that tool or technology can be automated. It’s an “automation first” approach.</li>
<li>In making the transition from storage-focused person to “infrastructure as code”-focused person, one big challenge Patrick faced was sticking with something long enough to build expertise. He had to battle the “ooh look something shiny” mentality that is common among IT professionals.</li>
<li><a href="https://www.docker.com/">Docker</a> has been very helpful to Patrick—it helps him get to the point where he can evaluate the value of a technology instead of getting stuck in the minutiae of installing or configuring the product.
<ul>
<li>You still need to go back and understand the minutiae, but that can be done <em>after</em> you’ve figured out whether it’s worth the time and effort (instead of being forced to invest that time and effort up front when you don’t even know if this technology will be useful).</li>
<li>Setting up ELK (ElasticSearch, LogStash, and Kibana) using Docker is one example of being able to evaluate the tool before having to invest time in getting it running.</li>
<li>It’s faster to “getting business value” out of a particular technology.</li>
<li><a href="https://www.vagrantup.com/">Vagrant</a> also does this, but in some cases Docker does it faster.</li>
<li>Don’t skip out on going back to understand the details of how these things work!</li>
</ul>
</li>
<li><a href="https://www.pluralsight.com/">Pluralsight</a> is a great resource for keeping up with technologies.</li>
<li>Patrick’s also found <a href="https://linuxacademy.com/">Linux Academy</a> to be helpful. Being able to watch informational/instructional videos while offline has worked well for him.</li>
<li>Patrick is a fan of David Allen’s GTD, specifically the simplified “WSD” variant (“Write Stuff Down”)—he finds it very helpful jot down notes of technologies to investigate, things to research or look up, products or projects that might deserve more attention. Don’t forget to go back and review the notes!</li>
<li>He uses <a href="https://evernote.com/">Evernote</a> to track all these notes he captures, but pen and paper is highly recommended.</li>
<li>Podcasts are also a great source of information; he finds it useful to listen to podcasts while out running.</li>
<li>RSS feeds from various blogs are a fabulous source of <em>practical</em> information (this helps balance the onslaught of vendor information).</li>
<li>You’ve got to do some hands-on learning; Patrick really highly recommends the use of a home lab to help cement your learning. Consuming lots of content won’t do any good if you don’t try to put that knowledge to work in a lab.</li>
<li>Most of Patrick’s research/investigation centers around problems that he’s trying to solve at work.</li>
<li>When allocating time for your own self-development, you have to balance the need for the immediate (where you are now) versus where you want to be.</li>
<li>Stay interested in “what’s next”.</li>
<li>When you attend an industry conference, attend sessions that are “outside your comfort zone.” This is how you grow and avoid irrelevance.</li>
<li>If you are limited in which conferences you can attend, pick the conference that’s going to give you value and help you learn something entirely new.</li>
<li>What would Patrick have done differently?
<ul>
<li>He wouldn’t have gone to ten straight EMC conferences in a row.</li>
<li>He would have taken more interest in how a career progresses, especially when he was younger. He would have paid a bit more attention to the future with a more forward-looking forward.</li>
<li>He would have spent more time trying other technologies to expand his horizons. Don’t get caught up in ideological absolutes—choose the right tool for the job.</li>
<li>He would have looked for mentors—career and technical—much earlier in his career.</li>
<li>Sometimes this “mentorship” is entirely virtual, and consists of folks you’re watching/listening to/reading in their own careers.</li>
</ul>
</li>
<li>What tips or advice can Patrick provide to folks?
<ul>
<li>Pick your battles. Making a new technology relevant to your day job—in a way that solves a real problem—can eliminate a lot of hassle.</li>
<li>Pay attention to business value. Show the value of what you’re doing or trying or learning.</li>
<li>Use technologies regularly. This is especially helpful with coding, whether that be coding in Python, building Ansible playbooks, or writing regular expressions. (Patrick likes RegEx Golf.)</li>
<li>Always Be Coding. Create something every day.</li>
</ul>
</li>
<li>Big Data is really on Patrick’s mind right now; he thinks this will be really important moving forward.</li>
<li>Security is finally becoming a first-class citizen, and it’s finally becoming something into which more companies are going to invest more money and more resources.</li>
</ul>
<h2 id="additional-resources">Additional Resources</h2>
<p>John Mark Troyer’s presentation at Melbourne VMUG UserCon 2015: <a href="https://www.youtube.com/watch?v=iNmeXOKH05M">https://www.youtube.com/watch?v=iNmeXOKH05M</a></p>
<p>Useful tool for learning regular expressions: <a href="http://regex.alf.nu/">http://regex.alf.nu/</a></p>
<p><a href="https://www.amazon.com/Little-Book-Talent-Improving-Skills/dp/034553025X/ref=sr_1_1?ie=UTF8&qid=1465597027&sr=8-1&keywords=little+book+of+talent+daniel+coyle"><em>The Little Book of Talent: 52 Tips for Improving Your Skills</em> by Daniel Coyle</a></p>
<p>Patrick’s <a href="https://github.com/patrickkelso/devops-workflows">“DevOps Workflows” repository</a></p>sloweEpisode 5 features Patrick Kelso, a former storage/NAS guy who embraced "infrastructure as code" and similar technologies and methods during a couple transitions in his career.Full Stack Journey Episode #004: Brent Salisbury2016-04-14T00:00:00+00:002016-04-14T00:00:00+00:00http://fullstackjourney.com/2016/04/14/full-stack-journey-ep004<p>This month’s guest on Episode #4 of the Full Stack Journey Podcast is none other than Brent Salisbury, aka <a href="https://twitter.com/networkstatic">@networkstatic on Twitter</a>. Brent is a long-time <a href="http://networkstatic.net">blogger</a>, and is active <a href="https://github.com/nerdalert">on GitHub</a> as well. Of course, his activity on GitHub should not be surprising, since Brent works for Docker, Inc., on the networking side of the open source Docker project (libnetwork). As someone who made the transition from full-time network administrator/network engineer to software developer, Brent is ideally suited to share some knowledge with listeners of the podcast.</p>
<p>You can <a href="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-004.mp3">download</a> the MP3 recording of the podcast, or simply <a href="https://itunes.apple.com/us/podcast/full-stack-journey/id1073172158?mt=2">subscribe via iTunes</a>. If your browser supports HTML5 audio, you can also listen the podcast here:</p>
<audio controls="">
<source src="http://fullstackjourney.s3.amazonaws.com/full-stack-journey-episode-004.mp3" type="audio/mpeg" />
If you're seeing this message, your browser does not support HTML5 audio elements.</audio>
<h2 id="show-notes">Show Notes</h2>
<ul>
<li>Brent is a long-time network professional who feels he’s “on the journey” toward becoming a full stack engineer.</li>
<li>Brent went from networking, to coding at Red Hat, then helped start Socketplane, and is now at Docker.</li>
<li>Brent feels that networking skills are incredibly important, and networking professionals may be in a great position as IT evolves.</li>
<li>The journey to being a full stack engineer isn’t a replacement for existing skills people have learned; it’s a supplement as part of ongoing growth</li>
<li>The trigger for Brent to evolve from networking professional to where he is now was hearing Martin Casado talk on some networking podcasts about software-defined networking (SDN)</li>
<li>Brent believes that “giving everything away” is a powerful tool; sharing information just encourages others to share, which benefits everyone.</li>
<li>Take the risk; admit you don’t know everything, and look to learn from everyone around you. Everyone has something to teach you.</li>
<li><a href="https://www.docker.com/">Docker</a> takes complexity and makes it easier; it’s one reason Brent is excited about Docker. Complexity is the killer, the barrier to adoption, and now that barriers are lower it’s easier to become a full stack engineer.</li>
<li>Simplicity is the “X-factor.”</li>
<li>Anyone who is worth their weight in salt in this field is curious—you need to broaden your horizons enough to know what to be curious about. Otherwise, how will you know what’s happening, or what to do?</li>
<li>Take a “macro-level” look at technology and how things are evolving.</li>
<li>There are lots of components, many of them open source, that you can use to build solutions that will change the world (or just your career).</li>
<li>Brent believes it’s possible to self-teach yourself just about anything</li>
<li><a href="https://golang.org/">Go</a> (the programming language) is one that Brent really likes—it’s readable, but compiles down into machine language.</li>
<li>For people just getting started, start with your organization’s pain points. The technology decision comes later.</li>
<li>Some places you can start:
<ul>
<li>Automate configuration changes</li>
<li>Understanding how networking works in a server (the session at DevOps Networking Forum on Linux networking was helpful)</li>
<li>Gaining some experience as a systems administrator</li>
</ul>
</li>
<li>Networking (and storage to some extent) trails a bit behind some of the other technology areas, and you can learn from other areas (pay attention to the lessons of DevOps, for example).</li>
<li>MACVLAN and IPVLAN are really going to re-shape networking.</li>
<li>What would Brent have done differently in his journey?
<ul>
<li>Discovering (and using) community sooner/earlier in his career</li>
<li>Don’t second-guess your gut; your experience is valuable! Use your experience and knowledge as a basis for learning from others and adapting their approach.</li>
<li>Don’t let your ego get in the way. Your experience is valuable, but be open to learning from others.</li>
</ul>
</li>
<li>Use the <a href="http://www.ipspace.net/Main_Page">“Ivan Pepelnjak”</a> test—if Ivan asks, “What are you thinking?”, there’s probably a good reason he’s asking that. Question the approach, iterate on it, but stay rational.</li>
<li>The barrier to entry for new technologies is lower now—get into the lab, try out some of these technologies. There’s nothing stopping you.</li>
<li>Brent’s learning style is one of “diving right in”: jump in, find code snippets, break it, fix it (repeatedly). Brent calls it “test-driven learning,” though he admits he’s not good at writing tests.</li>
<li>Snippets were a huge tool for Brent, and <a href="https://github.com/">GitHub</a> is a great source for finding code snippets.</li>
<li>When working with a modular language, code snippets enable Brent to take smaller chunks of code and assemble them into something larger and more complex.</li>
<li>Reading code snippets also helps you determine common coding patterns, syntax, code structure, etc. The first programming language is the hardest.</li>
<li><a href="https://www.python.org/">Python</a> is also a good language for starting out. When you start needing performance, Brent prefers Go.</li>
<li>Brent’s keen on “cherry picking” the best parts of SDN—automation, integration with orchestration, provisioning—and applying those parts in a safe manner, at massive scale, in a way lots of people can benefit.</li>
<li>IPVLAN drivers are available (if you’d like to test them) in the experimental builds for Docker Engine.</li>
</ul>
<h2 id="additional-resources">Additional Resources</h2>
<p><a href="https://www.youtube.com/playlist?list=PLGeM09tlguZRmQIO-K2tseTDCMcVxy17Y">DevOps Networking Forum 2016</a></p>sloweEpisode 4 of the Full Stack Journey Podcast brings Brent Salisbury to the show, sharing lessons learned during his transitions from network engineer to Java developer and then on to Docker networking contributor.