The Shippable Blog

Build, test and deploy applications independently from a monorepo

In our previous blog posts, Our journey to microservices: mono repo vs multiple repositories, we shared our thoughts and experiences on our approach with monorepo. We received a few questions after that blog on how CI and deploys go with the monorepo.

In this article we will learn how to run CI, build and deploy applications independently from a monorepo. On each PR/commit we will run tests on the service which has changed build a docker image from it and push it to a registry. This image can then be deployed to to a cluster on any supported Container ServiceWe will use Shippable for this scenario.

7 things to consider while moving to a microservices architecture

In part I of my four part blog series on Microservices, I explained what microservices are and the benefits you will see by adopting this architecture.

However, life is all about tradeoffs. In part II of this series, I will go over the things you need to consider while moving to microservices, as well as some challenges that crop up even when you do everything right.

Microservices for greenfield projects

Anytime your team develops a new application from scratch, it feels great not to inherit technical debt and be locked into outdated decisions made years ago.  Most teams developing new apps today would probably choose to containerize them using Docker and adopt microservices architecture for speed and agility.

Why you should adopt a microservices architecture

Microservices are the new cool kids in tech town and everyone's trying to join the party. After all, microservices are considered the panacea that brings speed, agility, and innovation to software powered businesses.

For the most part, this is true. In Part I of my four blog series, we will take a look at how software architecture has evolved over the years and why you should consider adopting microservices.

What is Modern Application Delivery?

Development practices have come a long way since the time of Waterfall. Development shops have progressed through Agile methodologies and have built a culture of continuously delivering value to their customers, both internally and externally. Many shops have also since implemented Scrum and are experimenting with containerization technologies.

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: