Cloud visualization that helps developers easily configure, maintain and communicate their infrastructure within large teams.
Development Operations was a field that previously involved engineers with substantial background in operational management. Projects were also lengthy, with sufficient time allocated for Ops tasks. Companies are now expecting most engineers to participate in continuous design and planning of the cloud environment, while projects are becoming more agile. This shift has created some critical issues:
- Difficult to communicate cloud setup to a lot of engineers and project leads, especially in virtual meetings
- Internal docs becoming quickly outdated due to constant changes
- High barrier to entry for a new engineer to quickly setup a cloud environment due to complicated setup and limited knowledge sharing
While working at Microsoft in 2012, I worked on a large enterprise project that required involvement of the DevOps team to setup our cloud environment. Interested in their process, I shadowed the engineers and discovered some of their pains. During this time, my friends Ali Fathalian (DevOps Engineer) and Farzad Fincher (Software Engineer) validated experiencing the same issues on their teams. A month later, we were spending our free time trying to solve these problems before quitting our jobs to cofound pdestal in 2014.
Our goal was to make configuration, maintenance and communication of traditional cloud infrastructure a simple task. In turn, engineers could spend more of their time working on value-add projects that were critical to the business.
As someone with no Operations experience, I needed to learn about their process and pain points. So over the course of a month, I conducted more than 30 user interviews with software and system engineers from companies of different sizes.
DevOps is a term, rather than an explicit role, for tasks that intersect software engineering, IT operations and quality assurance. More and more, a smaller number of engineers are being expected to take on a wider set of engineering tasks without proper experience and knowledge sharing.
A major pain point raised by all three user types was the difficulty in communicating cloud architecture setup in meetings. Generally, a senior systems engineer would draw out the setup on a whiteboard, which was difficult for remote attendees to see and would have to be properly documented post-meetings. Even if the setup was documented, it didn't capture all the discussed details and would quickly become outdated due to a platform change or a customization request.
Experiencing the pain
Before even starting the design process, my team and I setup our development environment and cloud service. We wanted to experience the pain-points raised by those we interviewed and to further validate our own assumptions. Doing so involved:
- reading through the AWS documentation, which we selected over Azure due to its widespread use
- creating our own cloudformation templates, normally in JSON or YAML
- making frequent changes and updating our internal docs
- communicating a new setup while being on a remote call
The key challenge was to simplify and abstract away the complexity for new users while also accommodating workflows of power users so they could be more productive. We were able to best address both user types through iterations of working closely with users and measuring everything we built.
- easy-to-use interface that allows users to create and configure their infrastructure
- automatically generate the cloudformation templates to quickly setup the infrastructure
- connect to user's cloud computing service, like AWS, to maintain an up-to-date record of the current setup
- enable engineering teams that are working on different environments to effectively communicate the setup with each other
- making customizations without costly errors
With the goals and research at hand, I had a very strong intuition about the user experience, which I mapped out in a flow diagram.
In the flow, users create their infrastructure through visual diagraming, which then produces the cloudformation templates in real-time. If users want to visualize or edit an existing cloud during a meeting, they could import their cloudformation template into the code editor. The main value is that a cloud setup is always in sync with what's been documented, enabling teams to knowledge share, communicate and reduce costly errors.
Release, test & iterate
Being a strong believer in 'fail fast, learn fast', the team and I used the user flows to developed the first version of pdestal within a week. We recorded a demo of pdestal and tweeted out the link to engineers during the 2014 AWS conference the following week.
During the conference and for months afterwards, we iterated based on our learnings from analytics and user studies with engineers.
pdestal is a tool we built for setting up, visualizing, configuring, and communicating cloud infrastructure. As the lead designer and one of the frontend developers on the team, I designed the UI and user experience, and developed most of the HTML/CSS.
Effortless cloud setup
Reducing the unnecessary steps
Visualizing based on existing setup
Developer Documentation contextualized
The devil is in the details
Often times, what a user said did not translate to what they actually did. For example, while they expressed a need for preset configurations, they opted to create their cloud setup from scratch because the cost of editing outweighed its benefits. As a result, I learned to use testing and analytics to tell me what users are actually doing, and user interviews & studies to understand why they are doing it.
Good product doesn't mean good business
Working on pdestal taught me how to build, or rather how not to build an Enterprise product. Through mistakes and failures, we learned how to balance the needs of our users with that of the business and customer, properly filter customization requests from enterprises, and allocate resources for customer support and building partnerships. However, we discovered that the varying needs of enterprises required a high-touch development process that we couldn't financially support for long-term growth. Building a product that solves user problems is one thing, but building a viable business is another problem altogether.