Using Microservices to Make Costly Deployments Less Frequent

This article on costly deployments is part of a series on How to Choose Your First Microservices.

Switching to a new software architecture style is costly. I advocate choosing where to employ microservices first by using them to solve existing problems in the team. This helps the organisation extract value from the new architecture with each step towards the new world. This series is working through a set of problems that your org may have, and how microservices might help solve them.

Tricky Deployments

A fighter jet on an aircraft carrier being signalled to launch by two ground staff. Launching a fighter jet is a costly deployment, just as deploying a monolith may be.

Some components of your system will be tricker to deploy than others. This is true regardless of whether you’ve already got microservices or you’re deploying a monolith. Some components might be in use by 1000s of customers 24×7, while others might only be used once a month. Upgrading a component might require other components to be placed into a certain state, while others can be upgraded independently of the rest of the system. Coordination may be required between multiple teams in order to effect a trouble-free deploy of some components, whereas others might be actioned by a single person.

Continue reading

Using Microservices to Solve Developers Stepping on Each Other’s Toes

This article on reducing merge conflicts is part of a series on How to Choose Your First Microservices.

Switching to a new software architecture style is costly. I advocate choosing where to employ microservices first by using them to solve existing problems in the team. This helps the organisation extract value from the new architecture with each step towards the new world. This series is working through a set of problems that your org may have, and how microservices might help solve them.

Is your team wasting a lot of time working around each other?

A side-collision car crash at an intersection, surrounded by emergency personnel. Like this, merge conflicts can be messy and dangerous.

If you have a large team of developers working in a single code base, it’s inevitable that the work of some team members will interfere with the work of others. Many of us are now using tools (like git) and processes (like continuous integration) that can lessen the impact of interference. (Although other modern practices like feature branching can make conflicts worse.)

Continue reading