The CI/CD and DevOps Blog

Avi Cavale

Avi Cavale
Find me on:

Recent Posts

Our journey to microservices: mono repo vs multiple repositories

Microservices are currently the hottest topic in software development. The concept is simple: Break down your application into smaller pieces that each perform a single business function and can be developed and deployed independently. These pieces, commonly called services, can then be assembled into an application using some flavor of service discovery like nginx or consul. The microservices approach is considered the architecture of choice for teams that want to build scalable platforms and efficiently and rapidly innovate on them. 

As infatuated as I am with this architecture, our journey to microservices was a long and winding road. It has finally led us to a version of the architecture that gives us the scalability and agility we require as a business. I want to share my thoughts, experiences, and lessons learned in a series of blogs around this topic so you may benefit from our experiences. Also, I would love to get your feedback or comments on our approach.

When you start moving to microservices, the first question before you write a single line of code is: How do you organize your codebase? Do you create a repository for each service, or do you create a single ‘mono repo’ for all services? The two approaches are illustrated below:

Moving Beyond CI with Automated Pipelines

This is an exciting time for Shippable as we release the next version of our pipeline. As a SaaS company we constantly release new features and functionality, but this release marks a major update to our platform and services based on customer feedback and the "state of the art" for developers. You can read about the new features and updates in this blog post. In this post I want to take some time and explain how we have arrived at this point, and how we move towards the future of modern application delivery.

Shippable service update


Over the last couple of days, our service has not been as stable as expected and I want to sincerely apologize for this. I understand that Shippable is very critical for your CI/CD workflow and any service interruption is extremely frustrating.


We have fixed the problem now, our service stability has improved tremendously, and we will take every precaution to make sure it does not happen again in future. 

In the interest of full transparency, here is what happened.

Since July 2014, we at Shippable made a decision to move toward a micro services based architecture. To live the world of continuous delivery, we made small incremental changes to almost all pieces of our architecture. 

Dear Ping-Pong, thanks a million (or two)! Love, Shippable

[The original post appeared as a guest post by Avi Cavale on Geekwire]

It all started at last year’s GeekWire ping pong and anniversary bash.

I had just founded my company, Qhode (now called Shippable). We were building a geeky product, a continuous integration and deployment service targeted at software developers. Even though we were solving a real problem, I had no idea how to market it.

I asked myself: How will people even find out about us?

We are the Yankees… If you want to bat, go join the Devil Rays

2010 was a fabulous year. We had just shipped a massively successful product called ‘Kinect’ and my team at Microsoft was busy celebrating with no thought to what the future might bring. 

I was celebrating with everyone else, but I had one more reason. In 2008, a CVP (corporate vice president) had told me – “Don’t dream too big. Microsoft is like the New York Yankees – the starting 9 have already been decided. You should be glad to just be a part of the team. If you want to bat, go join the Devil Rays.” I had proven him wrong by dreaming bigger and advancing my career quite nicely in the Kinect team.