Waterbear Cloud Newsletter, December 2019

By Kevin Teague
Published on Dec 31, 2019

Wow, we are writing this in the last days of the “tens” decade. Likely if you’re reading this, it’s in the twenties. Happy New Year and we hope your next decade is a great one!

Waterbear Cloud gets a new logo

Waterbear Cloud was launched at the start of 2019 with a very quick logo. In the fall we began the process of trying to come up with our “forever logo”. We had been brainstorming over logos during the summer, but we still hadn’t had any ah-ha moments. We decided to try CrowdSpring, a design service where you can host a logo competition. This lets any CrowdSpring designer see your logo description and submit a design based on their interpretation — at the end of the time period you choose a winner and they get paid.

Since we didn’t start out with any concrete idea of what we wanted, different designers submissions helped us visualize what our logo would look like if we took it in different directions. Did we want a bear? A tardigrade (waterbear)? Or just a cloud?

We were initially resistant to the idea of a cloud in our logo. It’s hard to do a cloud logo that doesn’t look terribly generic. However, we know that one of the guiding principles of a logo design and the branding it conveys is when people are shown different logos and ask to supply the first two or three words that they associate with that logo.

We wanted our logo to bring to mind the words: speed, simplicity, modularity, innovation and cloud. Well, we couldn’t target all of those words with one logo. We looked at some cool tardigrade logos — but they didn’t look like they were for a technology company. We then asked for more “modular” looking designs— but they either failed to looked aesthetically pleasing or they didn’t evoke the word cloud. And by now we had decided that we wanted people who saw our logo to think “cloud”. After all, we are a cloud company, it’s the core of our business. We asked for more “modular cloud” designs.

Time was almost up for our design competition and we’d looked at hundreds of different submissions. We’d picked out ones we liked, discussed what we did and didn’t like about each one — but at the end of the day none of them were really that great. We started thinking we’d pick a “good enough for now” logo and have another crack at logo design in the future. Then with just a few days left, we had a designer submit the logo design you see above … as soon as we saw it, we liked it.

It was a cloud, but it was in motion — it evoked speed. We had been trending towards clouds in motion, as Waterbear Cloud’s starting goal was to be able to bring people to the cloud faster. And the symmetrical curves suggested modularity. Aesthetically it worked — the motion lines trailing from the three clouds end in a curve that itself fit into the shape of a cloud.

We went through some final iterations choosing colours and a typeface and then this month we started using our new logo!

AIM gets renamed to Paco

AIM (Application Infrastructure Manager) was the original name for our open source Infrastructure as Code tool. It’s the tool we wrote to enable us to build and manage cloud solutions faster than using traditional Infrastructure as Code tooling. However, we had a naming problem. There are a lot of other things named AIM — so we weren’t so confident about future copyright confrontations — and worse, when you Googled for “aim aws”, Google would correct you with “Showing results for iam aws”. It would be a seriously big uphill battle to get AIM to the point where the tool would get a good search ranking.

Our tool was complete though — we were using it in production and we were polishing it. It was time to get other people excited about it. But before we did that we had to give it a proper name.

We had been using the phrase “prescribed automation” internally at Waterbear Cloud. We’d designed our tool to be a complete ready-to-go solution — unlike other Infrastructure as Code tools that leave it up to you to decide how to connect resources, keep DRY environment configuration, mount filesystems, tag resources consistently, deploy code and so many other details, we wanted to provide prescribed automation — all that is needed to create a working Infrastructure as Code project was declarative configuration. The tool fit into “cloud orchestration” as a software category, so the phrase Prescribed Automation for Cloud Orchestration described what the tool was about. We put that into an acronym and the name Paco was born.

We started 2019 with only some ideas on how to improve Infrastructure as Code and an MVP tool. We are ending this year with a tool being used to manage production environments and more importantly, one that we are ecstatically happy with the overall design and that we find a joy to use.

Check out Paco at https://paco-cloud.io