Azure Container Registries/Docker Extension Project
Esteban, Jackson, Julia- thank you for teaching me countless technical skills, bouncing ideas off of one another, filling up our drawers with snacks, and having my back every step of the way. Microsoft, you rock and see you next summer!
Project Brief
- Summary — This past summer of 2018, I completed Microsoft’s Explore Internship in Redmond, Washington. The program places college freshmen and sophomores in Microsoft’s most active teams and gave us the opportunity to work on impactful projects.
My pod and I were grouped in the Azure Container Registry team and we completed an open-source project. We added features to the Docker Extension on Visual Studio Code to better manage and utilize Azure Container Registries. The user count increased by 104% from 2.7 to 5.5 million in our 3 month timespan. Find the code and our contributions here. - Role — 4 week Program Manager, 8 week Software Engineer
- Dates — June 18, 2018 - September 7, 2018
- Team Members — Rutu Samai- Cal Poly SLO, Esteban Rey- Stanford University, Jackson Stokes- University of Washington, Julia Lieberman- Santa Clara University
- Microsoft Mentors — Sajay Antony- Engineering Manager, Bin Du- Principal Software Engineer, Steve Lasker- Program Manager, Kaitlin Wilkinson- UX Designer
- User — Developers currently using Docker, Azure Container Registries, and Visual Studio Code with an emphasis on existing Docker extension users.
- Technologies Used — Azure Cloud, Docker, Containers, TypeScript, Node.js, VS Code Webview API, Python, JavaScript, HTML, CSS, InVision, Figma, Inkscape
Channel 9 Azure Friday Interview
Open-Source Codebase
Cal Poly Feature
Technology Overview
- Visual Studio Code — a popular source code editor by Microsoft for Windows Linux, and macOS. It includes support for debugging, embedded Git control, syntax highlighting, intelligent code completion, snippets, and code refactoring
- Containerization — a lightweight (simpler, faster, takes less space) alternative to full machine virtualization that involves encapsulating (adding a layer of abstraction) your application with its own operating environment to ensure efficient, portable, customizable products
- Image — a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings
- Container — a standard unit of software that packages up code and all its dependencies so the application runs quickly and easily on various computing environments
- Docker — a service to package the application you’re working on with the binaries (data) and libraries that are required to run that application
- Registry — a highly scalable server side application that stores Docker images, similar to a folder
- Azure — a cloud computing service created by Microsoft for building, testing, deploying, and managing applications/services through the cloud
- Azure Container Registries (ACR) — private Docker registries with extra functionality to work in Azure
- Build Task — holds instructions for your ACRs’ functionality such as how to publish a Docker image after commiting, updating base images automatically, and other scripts you might add
- Build Task Log — record of what was executed by your Build Task
Problem
Learning how to deploy images and manage registries in Docker is an over-complicated process with a steep learning curve. This prevents users from continuing their subscription to Azure Container Registries, since the need to memorize commands, variety of service and management applications, such as the Azure Portal, Command Line Interface, and DevOps, is a frustrating and inefficient experience overall.
Additionally, Visual Studio Code, a popular code editor, lacks ample support, tools, tips, and integration for users trying to build Azure Cloud powered Docker applications.
Goal: Provide the needed bridge and user-friendly solutions to increase user retention and adoption of Azure Container Registries and the Docker Extension.
User Research
Target User
Developers (Small businesses, cloud native devs, researchers) currently using Docker, Azure Container Registries, and Visual Studio Code, with an emphasis on existing Docker extension users.
- Users looking to run/contain containerized applications in the cloud regardless of exposure to this process
- Users with decent exposure to Docker (already have a Dockerfile) or Azure seeking to use containers with Azure seamlessly
- Users seeking alternative development pipeline with containers to Azure DevOps
Current Approach to Deploy to Azure
1. Azure Web Portal provides basic functionality for monitoring and managing Azure Container Registries. The user exits the code workflow, goes to the Azure Web Portal, launches the cloud shell, navigates to the source context they want to build and must type the command to build an image.
Cons: It’s disconnected from the code itself, has limited capabilities, and slower speed.
2. Azure Command Line Interface (CLI)is currently the primary way for users to interact with Azure Container Registries. In the command prompt, the user navigates to the source context they want to build and must type the command to build an image.
Cons: It has no direct integration with your development environment, requires installation and high initial commitment (documentation and learning commands).
3. Azure DevOps (previously Visual Studio Team Services) is used for application lifecycle development.
Cons: It’s heavyweight and takes many resources to build.
User Interviews
In addition to reading user feedback from previously collected surveys, telemetry data, and the Docker extension blogs/forums/issues on GitHub and Stack Overflow, I conducted 1 hour interviews with 7 users to receive a better understanding of how our users interact with a combination of the current approaches to deploy to Azure. These users included a Kubernetes Extension developer, .NET PMs, Chief Architect of Bitnami, a Cloud Developer Advocate/Pluralsight Instructor, and our ACR team of PMs, architects, and developers.
After reviewing the interview results, it was clear that our users were extremely diverse- their end user, goals, use cases, dependencies, and more. It felt incredible being given the chance to empower such a wide range of developers.
MVP and Mockups
I analyzed similarities in frustrations and needs and prioritized our MVP features list. The aim was for our new features to make our users’ worry less about digging to learn the basics, and accomplish more of their goals with ACR.
Goal: We wanted to eliminate the need to download the Azure CLI, spending weeks reading documentation, and switching back and forth with the Azure Portal by providing seamless integration of various ACR tools with a simple, user-friendly journey.
New Features List:
- Create Registry/Resource Group
- Build, run, deploy, tag, delete images
- Create Build Tasks
- Show/Run Build Tasks, open Build Task properties
- View Build Logs — UI to view, filter, create logs
- Image Pull from ACR
- Image Push to ACR
- Bugs/Simple Enhancements- Loading time optimization for Explorer (part of extension to view ACRs, images), Subscription filter in Explorer, Multi session caching of container registries
Mockups:
This was one of the most entertaining portions of the project- lots of mixed feelings and reactions from mentors and users!
“What is ACR Build? I have no idea where to click first.” — a candid user
At this time, I studied ACR Build more, whose name and concept were confusing to both the user and me, early on.
I transferred Mockup #1 with new changes to InVision, so we could track the exact user flow and clicks to compare with our intended user journey.
“Are you trying to blind me? Red on black is the devil!” — our beloved PM mentor
Needless to say, we decided to work with our UX designer to make a more sophisticated mockup.
Final Product
For 8 weeks, we jumped into the codebase, pinged our awesome Dev mentor a million times, and became expert debuggers.
“Rutu, for the 10th time, you’re coding in the corresponding JavaScript, not TypeScript file. You’re not supposed to touch that.” — Esteban
In my defense, the corresponding JavaScript file automatically popped up whenever I ran the program and looked 99% identical.
It was a lot of identifying patterns, hunting for documentation, trial and error, and when desperate- closing and reopening VS Code. To my pleasant surprise, this tactic actually worked several times.
Here’s what we built!
Obstacles I Overcame
New Technology
Problem: It was intimidating starting this project, having no exposure to Docker, Containers, TypeScript and a minimal understanding of Azure Cloud. I took copious notes, attempted the same tutorials 5x each, and even printed a 100 page documentation. During user interviews, I nervously thought about:
“How can I solve their problem if I can’t comprehend what their user journey is? How am I supposed to customize the follow-up questions when I can’t keep up with their answers to basic questions?”
Solution: With time, experience, patience, and repetition, I became more familiar and confident with the topics. For user interviews, one time, I just followed our script questions and tried to type every word I heard, then made sense of it the next week. Every day, I grasped more, slowly putting the pieces together each time I reread our “Useful Notes/Definitions/Links” document, participated in sync-up meetings, and asked questions. When my manger had us interns teach a new hire (5+ years of experience) the technologies, I realized that most people start in the same boat.
If you keep reading docs because you’re scared that you don’t know enough to code and use the technology, get over it and jump in. It’s the only way you’ll learn.
Abstraction
Problem: Many of our PR comments pointed out that we had repetitive and scattered code such as:
- Functions asking the user for information in the command palette.
- Rewriting long pieces of code, just to get the client object.
The ideal architecture wasn’t obvious at first, since we were still getting acquainted with the deliverables, codebase, and priorities. We didn’t realize our (4 interns’) work would intersect so much.
Solution: We drew UML and dependency diagrams to understand connections and the product architecture. TS Lint, a TypeScript conventions extension helped us keep our code uniformed and have similar styling and conventions.
- Made a quick-pick-Azure.ts file and imported this in various files to access methods like quickPickACRRepository().
- Created the AzureCredentialsManager class to get Azure account, client, and more information that we used often.
Image Pull Issues
Problem: When “docker login” is run in Image Pull, the following errors occur:
- If the user was previously logged into Docker with Azure credentials, those login credentials would be overridden. This often runs an uneccesary command, which is inefficient.
- “WARNING! Using — password via the CLI is insecure. Use — password-stdin.” The password token was showing on the terminal, which is unsafe.
- “Error saving credentials: error storing credentials — err: exit status 1, out: `Das Stub erhielt falsche Daten.`" I identified that when the login token exceeds 4 KB, regardless of being logged in or not, the “docker login” command produces this error. This problem was discussed in a 20 email chain over a couple days and ultimately, a more intricate, elegant solution was implemented after my internship.
Solution:
- Created isDockerLoggedIn() function which parsed .docker/config.json to check if the user is logged in.
- I exec’d the command, got a ChildProcess object, and wrote to its stdin, hiding the password on the display console.
- I investigated the Azure CLI Code in Python and found a temporary workaround. I removed “credstore”:”wincred” from the file, then ran “az acr login” and passed the credentials to “docker login” again. This allowed the token to be any size and removed the error message, but information isn’t secure anymore and an alert notification is sent to the user.
Learnings
GitHub Pull Requests
This was my first exposure to personally forking a large-scaled project, creating multiple branches, crafting PRs for coworkers to review, squashing commits, and rebasing with master. My biggest takeaway was that Git can honestly only be learned through practice- spending an hour rebasing- approving/rejecting changes, fixing merge conflicts, creating/labeling issues with priorities, and after Googling and getting frightening messages- ask for help from your GitHub master friend!
Scrum
This was my first time in a scrum channel- our team of 17 had a #scrum channel in Microsoft Teams. Seeing what everyone was working/stuck on helped open my eyes to the wide array of technical challenges and features being tackled in the team. Writing down my goals for the day and seeing a record of the past week gave me perspective on my deliverables and pace.
Scrum Reflections:
Have I tried multiple fixes? Is it time to ask for help? I barely made progress on this task- how can I break this task down? Is a teammate stuck on an issue I can provide input on?
Accessibility
Microsoft puts the utmost emphasis on Accessibility and Inclusion in technology. As interns, we were exposed to the Xbox adaptive controller, Seeing AI, and more during events. My team was fortunate enough to account for this in a 3 month project. Thank you to our UX mentor who guided us on our UI’s colors to account for color-blindness or visual inclusivity standards, keyboard accessible tables, and more.
Some of the tools we used:
- Keros and 1ES, Microsoft In-house accessibility testing tool
- ARIA design patterns, mapping design patterns to common screen reader and keyboard interaction components
We were taught that when designing to account for accessibility, it makes the product better, overall. As builders, we have the power to enable everyone to use what we make.
I believe that’s a critical, unique duty we have, so much so that I made Accessiblity one of Camp PolyHacks’ (the social-entrepreneurship hackathon I lead) trails, or categories to hack on.
Team
My favorite part of the internship was hands down, the fabulous people I met. We were allowed to play the “intern card” or essentially grab coffee with the coolest people in the company. I sat down with 15+ full time employees through cold emailing, the Intern Networking Program that paired us up with a new person every week, Lunch and Learn- where 20 interns ate with Corporate and Executive Vice Presidents (including the Chief Product Officer, President, and Hololens CVP) and various other events the Cloud+AI Organization and Intern Program organized.
My manager, UX, PM, and Development mentors all pushed us to our limits. In the first 2 months, I felt very overwhelmed by everything I didn’t know, but my intern pod and I stepped through it together by Googling tutorials, filling whiteboards with basic definitions, watching videos, reading documentation, and most of all- asking millions of questions.
We were given an ambiguous problem and encouraged to break it down and learn the tools ourselves, just as full-time employees would. I cherish every brainstorming session, code-review, and field-trip across campus to find the best french fries.
This summer was truly the most unforgettable and growth-filled and I’m so grateful to have failed, picked ourselves back up, absorb knowledge, push our code out, and receive feedback.
