The Problem

A result of migrating our monolithic system towards microservices in the last couple of years is 20+ internal services (so far). Many of these services lacked great API documentation, the kind where our developers could easily grasp all endpoints, behaviours, and error codes. We needed three things for our API documentation: a common and easy way to document each endpoint of every service, a centralized location to access all this documentation, and a way to automatically update after changes to an endpoint. Swagger to the rescue.



Swagger is a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services. It also comes with Swagger UI, a great documentation viewer for endpoints. It lists endpoints and details of each one, and also provides a UI that can actually run test queries against test servers. Another bonus is that Swagger documentation is done with annotations in source code and so reduces overhead of managing multiple document sources. Sounds good!

  • Swagger documentation library for Play framework? Check.
  • Swagger documentation library for arbitrary Java web apps? Check.
  • Swagger documentation for for endpoints in general for Scala? Nope.

No Swagger for Scala endpoints? OK, let’s help. We made sbt-swagger Scala Library as an SBT plugin. Our sbt-swagger sbt plugin generates swagger-ui compatible JSON data based on the Swagger & JAX-RS (jsr311) annotations in your code. Any Scala applications that provide APIs can benefit from this plugin.

Today, we released it as open source. We have been using sbt-swagger in our products for documenting, exclusively for our internal Scala microservice component that provides our internal protocol over ZeroMQ.

Using sbt-swagger

Three steps:

  1. Add sbt-swagger config/dependency in your SBT build file
  2. Add docs in your Scala code with JAX-RS (jsr311) annotations
  3. run sbt swagger
Read More →

Hootsuite is no stranger to tearing down monoliths. In fact, over the past year we’ve built fifteen microservices to go along with the deconstruction of our monolith. The extraction of each microservice came with its own complications, but they have all generally followed one development blueprint.

A monolith is the result of legacy code becoming fossilized after years of coding with ongoing contributions from multiple people. This makes the code incredibly hard to refactor as it is always in use, and always depended on. In this case, microservices are used as a tool to tear apart the monolith to address the problem of unreliability. However, a microservice in general is not limited in its purpose or functionality.

Hootsuite's Microservices

Hootsuite’s Microservices

Scoping & Prioritization

The first major decision when tearing down your monolith is which part to break off first. Do you want to slice it horizontally or vertically, julienne it or dice it? At Hootsuite, before writing any code, all business objects and use cases were outlined to determine what might make a good microservice. Models that frequently interact with each other were carefully grouped so that a tangled web of distributed services would not be created.


It is clear that business objects like a Team and a Member of a Team should be migrated together. However, if each Team must belong to a single Organization, then it would make sense to also pull out the Organization object instead of leaving it inside the monolith. Read More →

Working at Hootsuite has helped enforce one ideal: security matters. In Hootsuite’s continuous implementation and deployment environment, our developers take security to heart and this is reflected in our code base. Working hand-in-hand with our developers, the security team strives to improve by staying updated and evolving with latest practices. As part of our commitment to staying relevant, we continuously look for tools that may simplify or remove our pain points. One of these pain points is the management of the large amounts of code flowing through the pipeline, and ensuring that they reach our security standards: with thousands of lines of code coming through every day, how do we guarantee those standards are met?

Read More →

Hootsuite Co-ops

The Story of Ira Needles

When Ira G. Needles arrived in the Waterloo region in 1925 to take a job as assistant sales manager at B.F. Goodrich, he hid the fact that he was university educated. At the time, the business world considered it “snooty” to have a higher education.

His education didn’t hurt him, however, and Needles gradually rose within the ranks of the tire giant, and by 1951 he was appointed president of B.F. Goodrich Canada.

However, in the summer of 1956, Needles’ two separate worlds – industry and academia – would finally come together in a radical speech he made to the Rotary Club of Kitchener-Waterloo. Needles’ speech would ultimately transform the nature of education in Canada.

During the talk, entitled “WANTED: 150,000 Engineers – The Waterloo Plan,” Needles presented a new kind of education that would involve studies in the classroom as well as training in industry.

Courtesy of the University of Waterloo public library file on Ira Needles

Thank Goodness for Ira

Needles and two others would then go on to found the future University of Waterloo (first known as the Waterloo College Associate Faculties) in 1957 and admit the first 75 students, all of whom were also co-ops. Sixty years later, roughly 80,000 students in Canada enroll in co-operative education each year.

A co-op program has, in my mind, no downside for students, employers, or the institutions that support it. Students apply their learning, test-drive life in industry, fund their education, and return to their studies to challenge some of the theoretical principles based on this experience. Employees, like us, get an opportunity to cement our own knowledge by teaching students and at the same time build a pipeline of young, bright talent. Lastly, demand for an academic institution’s programs grow as the demand for their graduating students grows.

How Do You Measure the Success of a Co-op Program? Read More →

Love technology? Are you a high school student in grade 11 or 12, or home schooled? Do you live in BC? 

Hootsuite’s technologists would love to help you develop your technical skills and to provide you with experience around people, process, and technology by working with you over the summer. You’ll pair with a mentor and work at our Vancouver office side-by-side with a passionate, egoless team having fun building something bigger than themselves. Experience what it’s like to make a difference in people’s lives by building the products our customers use to turn messages into meaningful relationships.

There are opportunities at Hootsuite in all aspects of technology including software (both mobile and web), operations, security, and IT.

This is a paid position with a competitive salary.

Application instructions are at the end of this post.

This is the second summer of this program. You can meet the High School students who worked with us last year and read about their stories and accomplishments.

Passive learning creates knowledge. Active practice creates skill.James Clear

Photo courtesy of @alexrousse_ (instagram)

Read More →

The Platform team at Hootsuite creates and manages microservices and is always obsessive over response times. We write all of our code with that as a guideline, so users can get the best experience. To achieve this, we rely on many cool open source projects like Scala and Akka, and do our best to give back to the communities whenever we can. In keeping with that, we are happy to announce we are open sourcing our Scala circuit breaker.

Circuit Breakers, Responsiveness, and Complexity

So, what is a circuit breaker? A circuit breaker in the context of a service helps deal with situations in which a service’s dependency (can be a DB, another service, a web site, a toaster, etc) stops working as expected and causes slow interactions with end users. The circuit breaker helps mitigate the problem by detecting slow or failed dependencies, and stops the sending of further requests. This fail-fast behaviour informs the users that there is a problem quickly, as well as lowering the resources allocated to communicating with the broken dependency. After being tripped, the circuit breaker should not remain tripped, or the dependency would be quarantined forever. To mitigate this situation, the circuit breaker can periodically retry the dependency and/or wait for predefined amount of time to see if the dependency is available again. Without the circuit breaker, the server would continue to try to use the unavailable dependency, and users would see pages timing out or returning an error after many seconds.

Scala circuit breaker

Read More →

How do we share our libraries internally?

In 2015, our Android team released v3 of Hootsuite’s app with a new UI following Material Design guidelines. We also gave users the Publisher feature, Instagram integration and enhanced Twitter Search. The development of these features relied on many popular open source libraries and tools, such as RxAndroid, Retrofit, Google Design, Robolectric, and many more. With the success of these libraries, our Android development team was inspired to build our own libraries to allow other teams to consume. A great idea, with a surprising complication: How do we share our library internally?

Publishing libraries to Maven Central using Gradle has been covered before by Chris Banes and others. His solution is visualized in the following diagram.

Chris Banes Maven Gradle

Our need was to be able to publish libraries to a private Maven repository like Artifcatory. We tweaked @chrisbanes‘s solution and made it available to our developers to enable them to write libraries independently and share them between teams.

Hootsuite Maven Gradle

In this post, I’m going to guide you in setting up your library to share your own Maven repository.

The Template Library Project

Most Android library projects share a similar directory structure, so we prepared a Library Template that will act as the reference for this guide. We encourage you to fork this project if you’re starting fresh.

Read More →

Hootsuite Developer Brandon Okert has authored the first in a 2-part series about Docker from a scaling perspective. To give a better understanding of how Docker can be used, Brandon provides a direct comparison between Docker and Virtual Machines, goes over the various components and tools available, and gives insight in managing Docker in the real world. Brandon also discusses prevailing Docker Ideologies and practices (as well as common exceptions), all in preparation for Part 2 of the series which will cover building scalable services with Docker. Check out his blog post, and join the discussion!


Before becoming a QA Tester, I never fully appreciated software testing. While coding, I wrote my unit tests, made sure they passed, and continued on with my life. When I got the job offer to become a QA at Hootsuite, I took it as an opportunity to learn a piece of the giant world of software testing, and now, knowing how valuable QA testing is, I think any software company without a QA team is missing out.

At Hootsuite, most teams have a dedicated QA person. They do a wide variety of things, from testing tickets, to automating the features, to creating tools for the other QA’s to use to do these things, and so much more. The QA’s here fit into the teams just like developers do. We have tickets that are created specifically for us to automate important features, and we participate in estimating how much effort is required for tickets.

You Mean to Tell Me You Can LEARN Things as a QA?

On the iOS team, we test every JIRA ticket that goes through every sprint at least once. Testing a ticket involves coming up with test cases, testing the cases on devices, and eventually automating them. Most of the time we automate a feature before it is released, but sometimes we only automate after being released. Once a feature is completely done, we go through and test each case again to ensure everything runs smoothly.

Test Cases, Test Cases Everywhere

At the bare minimum, a test case needs to cover a common or critical use path. More test cases are required to also cover edge cases and integration. Edge cases are less common use paths while integration tests are to make sure the feature interacts correctly with other features in the app. These are all important to test because we want to ensure a user can’t get our product into an unusable state. Key testing in these areas could be overlooked if we didn’t know our product inside and out. Missing any one of these cases could cause large bugs to reach users, which is never good for anyone. Repeatedly testing key features increases our knowledge of the app, which allows us to do risk analyses to figure out which features could be at risk with any new changes. Being able to pick out these features saves us from having to run a full run through of the app, usually referred to as regression, for every ticket, which is where automation comes in.

Most of our test cases are automated, but those that can't are tested manually.

Most of our test cases are automated, but those that can’t are tested manually.

Read More →

At Hootsuite, we perform penetration tests to ensure that our software and services are secure and compliant. Penetration testing (or “pen testing” for short) is a security process in which the tester attempts to exploit software using security vulnerabilities. The goal of our pen testing is preventative: to find as many security vulnerabilities in our products so that our development team can fix them.

In the field of security, there is more than one type of hacker. A hacker is categorized based on their motivation: Black hat hackers are those who seek to exploit software security vulnerabilities for malicious intent, White hat hackers are those who hack in an ethical way and try to to avoid causing damage the systems they attempt to penetrate. Pen Testers are White Hat hackers. By understanding the mindset of black hat hackers, white hat hackers can give organizations insight on how to further harden and secure the organization’s infrastructure to reduce security threats.

A Bird’s Eye View of Pen Testing

A Bird’s Eye View of Pen Testing

Read More →