Joyent CoPilot: Bringing Application Awareness to Cloud Infrastructure. Part III.

In the previous episodes

In Part I you were quickly introduced to the goal of the project as well as some of the technological concepts necessary to understand CoPilot. Part II covered major conceptual and structural changes. Up next: the signup process, creation of a deployment group and the first-time deployment of services. Ready? 3..2..1..go!

Sign up

The sign up and sign in processes for CoPilot are fairly conventional. Two important features that required improvement were configuration of account’s security (including SSH keys and two-factor authentication) as well as billing setup.

You might be thinking: “Sign up, really? Is it the most important thing to start the showcase of your work with?”. Yes, yes it is. I will take you through the same steps any new user would have to take. This will help you build an understanding of the product’s structure and ease you in into more complex technical bits.

A little snippet of the sign up process ( ow, Medium, your image compression is such a treat. Bliss).

On a side note, designing the signup flow was a good opportunity to explore different approaches to embedding a highly technical product with a bit of human touch through illustrations.

Have a look at the walk-through video:

Navigation

One of the most immediate and crucial targets for us was designing a navigational system that would bring together existing and new abstractions.

Effective navigation had to meet several criterias:

• provide users with a clear understanding and means to switch between their personal projects and organisations that they are a part of
• Support service-centric approach to application management, without imposing any specific workflow and retaining functionalities for infrastructure management
• Provide a clear understanding what level a user is operating on at any given moment in time — whether it would be a deployment group, a service or an instance of a service

To meet all of these goals, the new navigational system consists of 3 components:

• Organisations’ bar, that allows users to immediately switch between different organisations and manage them
• Abstraction breadcrumb that informs users at what level of abstraction they are working: organisation, project (aka deployment group), a specific service or an instance of a service
• Abstraction subsections — a component dedicated to navigation between separate tools of each abstraction.

An example of organisations’ bar and abstraction breadcrumb.

No matter what level of abstraction you are on, the structure and behaviour of these component remain the same, resulting in a consistent and memorable navigational system. It is worth pointing out, that it has been tested an improved continuously over the course of 10 months and proved to be one of the most successful pieces of design.

And here is how all 3 navigational components look in a specific scenario:

As was mentioned before, being able to easily access resources that belong to different owners was one of the desired improvements and the concept of organisations was introduced specifically for that. Here’s a video of how organisations can be created and navigated:

Deploying an application

So, you’ve signed up to the product and now are ready to deploy an application. For the time being, we will be talking about deployment with the bare minimum of tools and discuss other options (such as potentially integrating CoPilot with GitHub and grabbing a docker-compose file from a repo) in the future articles.

To deploy an application on Triton you need to fulfil several conditions:

• Specify what data centre services should be deployed to (or in other words, what geographical region you want for the physical hardware to live)
• Provide a docker-compose file (known in Joyent universe as manifest) describing services and their configuration
• Define environment variables. Having a separate environment file, instead of defining environment variables within the manifest, enables you to reuse the same manifest for different environments ( for example, development and testing).
• Specify amount of resources dedicated to each service (CPU, RAM and storage) and reflecting on their performance and billing.
• Specify number of instances of each service (in the alpha version fist-time deployment involves deploying only one instance of each service by default).

With the new abstracts in place, we’ve designed a flow that would accommodate the process of deploying an application by including following additional actions:

• Creating an ‘empty’ deployment group prior to deploying services. Being able to create an ‘empty project’ enables users to start out by setting up the infrastructure, managing collaborators’ roles, configuring security and billing. It also provides an opportunity for the first-time users to explore what CoPilot has to offer and get to know it’s capabilities prior to deploying anything at all and spending money on infrastructure resources
• Analysing manifest’s code for possible errors,i.e. linting
• Reviewing the deployment. We’ve provided users with a summary that combines services, resources allocated to them and billing, thus introducing a level of comfort more common to consumer products

Now, most of these improvements might sound pretty straightforward (and will be illustrated in a walk through video just in a bit), with the exception of reviewing and editing services. First of all, service configuration can be quite complex. Our intention was to keep the option of changing service configuration outside the manifest as simple as possible, meaning that whatever actions we enable users to take, the behaviour of the user interface would need to be relatively simple. Of all the configurable properties, package was the simplest one to represent and edit.

In the Joyent universe, a package is a preset of memory, CPU and storage resources allocated to a container, that determines containers performance capacity and its cost. Packages are optimised for different purposes. Users specify packages within the manifest. By providing users with an ability to change service’s package and cost outside the manifest, we were aiming to make the relation between service configuration and billing more explicit and it’s editing more immediate.

Check out the video walkthrough of the prototype:

“Ok, I’ve deployed some services— now what?”.

See, I knew you’re going to ask me that. We think the same, we’re like these mystical cosmic siblings, like alpha and omega. Well, since you’ve asked, now we will magically transport to Part IV, where we’ll break down CoPilot into some of its major components.

“All aboard the night train!” — James Brown and the Famous Flames