Tag: agile

The microservice architecture is a means to an end: enabling continuous delivery/deployment

A while ago we wrote that Successful software development = organization + process + architecture and described how the microservice architecture has a key role to play when developing large, complex applications. It is important to remember, however, that the microservice architecture is merely a means to an end. The ultimate goal is to deliver better software faster. Today, that invariably means continuous delivery – for an installed product – or continuous deployment for an -aaS product.

To clarify the goal of the microservice architecture, we decided to redraw the triangle with continuous delivery/deployment at the apex. The two corners at the base of the triangle are small, agile, autonomous, cross functional teams, and the microservice architecture.

successtriangle

The microservice architecture enables teams to be agile and autonomous. Together, the team of teams and the microservice architecture  enable continuous delivery/deployment.

Successful software development = organization + process + architecture #gluecon

Successful software development requires the right organizational structure, development processes, and software architecture.

SuccessfulDevelopment.001

Fred Brooks in his book the Mythical Man Month describes how the communication overhead for a team of size n is n(n – 1)/2. Consequently, a software development organization should either be a small team, or  a collection of small, autonomous teams. Amazon, for example,  famously organize around two pizza teams. Pizzas are an ambiguous unit of measurement but probably each team should be 6-10 people.

Despite rumors of the death of agile,  it almost always makes sense to use an agile development process.  Teams should do continuous delivery or, ideally, continuous deployment. Small, agile and autonomous teams can move fast (without breaking things) and keep up with the needs of the business. But what about the software architecture?

For small, simple applications the monolithic architecture often the best choice.  Development is simple, testing is easier and the application is easier to deploy and manage. However, successful application have a habit of growing and your monolithic application will become  large and complex. It will become extremely difficult to develop and deploy in an agile fashion. Teams are no longer autonomous. Delivering software will require lengthy merges and excessive amounts of communication and coordination. You will likely end up in monolithic hell.

Once your application becomes large you will need to adopt the microservices architecture. You functionally decompose what would otherwise be a monolith into a set of small applications or services. Each team owns one or more services. Each service has its own private data in order to ensure loose coupling. This architecture enables the teams to be agile and autonomous.

To learn more about microservices

Take a look at our founder, Chris Richardson’s recent talk at Gluecon on a microservices pattern language.

Learn more about Eventuate

To find out more about Eventuate: