bitmonkey

Brent Simmons asked some questions recently about Web App Architecture.

At Papertrail I’ve been living a lot of this stuff on a daily basis for some years now and wanted talk about it from the perspective of being on a small team.

In thinking about the questions, I realized that a lot of these architectural questions are much more to do with business decisions than people realize. Cliff Moon recently had a great post about microservices that is worth reading for a very grounded perspective on why microservices can be great.

There is a sentence in particular that I think is very valuable to think about:

An important corollary of Conway’s law, in my experience, has been that teams will tend to scale about as well as the software that they create.

One of the big benefits of a distributed architecture is providing a structure for communication and collaboration with large numbers of people. The fundamental problem that everyone is trying to solve is reducing friction. The funny thing about friction is that it is caused by different things depending on the size and makeup of the organization.

So, stepping back for a moment, one of the prerequisites of making these decisions is understanding what sort of service and what sort of company you’re trying to build.

What sort of growth do you expect, in terms of users and traffic, but more importantly in terms of your engineering team?

Are you on a rocket ship where you’re going to be going crazy from the very beginning and never stop with 100 developers before you know it?

Are you going to be growing organically and plan on keeping your team small for a few years?

These different paths will give you very different requirements. If you are planning on staying a small team (say, less than 3-5 engineers) for a few years, the friction you feel is going to be coming from some place different than communication and coordination between engineers.

When you’re starting out, and when you’re small, the speed at which you can make changes and improvements makes all the difference in the world. Having a bunch of separate services with interfaces and contracts just means that you have to make the same change in more places and have to do busywork to share code.

What can you do to reduce the friction required to push out that new feature or fix that bug? How can you reduce the number of steps that it takes to get a change into the hands of your users? Having code in a single repository, using an established web framework like Rails or Django can help a lot in reducing those steps. Don’t be scared of monolithic web apps when you’re small. Being small can be an advantage. Use it.

Predictions of the future are seldom accurate. Be mentally prepared for your architecture and your needs to be very different a year from now.

Never stop reevaluating your past decisions. It’s likely you’ll reach a point where you need to start breaking out your codebase into smaller components. Don’t consider that a failure of your past self.

A fundamental part of scaling a growing service is that you’re never done. If you are continuing to grow, there will always be more and different bottlenecks that crop up. There will never be a piece of technology or a style of development or architecture that will mitigate that.

Don’t try to be too clever. Assume you’ll have to change everything at some point in ways you never expected and don’t let that scare you. It’s a lot of fun.

Brent Simmons asked some questions recently about Web App Architecture.

At Papertrail I’ve been living a lot of this stuff on a daily basis for some years now and wanted talk about it from the perspective of being on a small team.

In thinking about the questions, I realized that a lot of these architectural questions are much more to do with business decisions than people realize. Cliff Moon recently had a great post about microservices that is worth reading for a very grounded perspective on why microservices can be great.

There is a sentence in particular that I think is very valuable to think about:

An important corollary of Conway’s law, in my experience, has been that teams will tend to scale about as well as the software that they create.

One of the big benefits of a distributed architecture is providing a structure for communication and collaboration with large numbers of people. The fundamental problem that everyone is trying to solve is reducing friction. The funny thing about friction is that it is caused by different things depending on the size and makeup of the organization.

So, stepping back for a moment, one of the prerequisites of making these decisions is understanding what sort of service and what sort of company you’re trying to build.

What sort of growth do you expect, in terms of users and traffic, but more importantly in terms of your engineering team?

Are you on a rocket ship where you’re going to be going crazy from the very beginning and never stop with 100 developers before you know it?

Are you going to be growing organically and plan on keeping your team small for a few years?

These different paths will give you very different requirements. If you are planning on staying a small team (say, less than 3-5 engineers) for a few years, the friction you feel is going to be coming from some place different than communication and coordination between engineers.

When you’re starting out, and when you’re small, the speed at which you can make changes and improvements makes all the difference in the world. Having a bunch of separate services with interfaces and contracts just means that you have to make the same change in more places and have to do busywork to share code.

What can you do to reduce the friction required to push out that new feature or fix that bug? How can you reduce the number of steps that it takes to get a change into the hands of your users? Having code in a single repository, using an established web framework like Rails or Django can help a lot in reducing those steps. Don’t be scared of monolithic web apps when you’re small. Being small can be an advantage. Use it.

Predictions of the future are seldom accurate. Be mentally prepared for your architecture and your needs to be very different a year from now.

Never stop reevaluating your past decisions. It’s likely you’ll reach a point where you need to start breaking out your codebase into smaller components. Don’t consider that a failure of your past self.

A fundamental part of scaling a growing service is that you’re never done. If you are continuing to grow, there will always be more and different bottlenecks that crop up. There will never be a piece of technology or a style of development or architecture that will mitigate that.

Don’t try to be too clever. Assume you’ll have to change everything at some point in ways you never expected and don’t let that scare you. It’s a lot of fun.

Brent Simmons asked some questions recently about Web App Architecture.

At Papertrail I’ve been living a lot of this stuff on a daily basis for some years now and wanted talk about it from the perspective of being on a small team.

In thinking about the questions, I realized that a lot of these architectural questions are much more to do with business decisions than people realize. Cliff Moon recently had a great post about microservices that is worth reading for a very grounded perspective on why microservices can be great.

There is a sentence in particular that I think is very valuable to think about:

An important corollary of Conway’s law, in my experience, has been that teams will tend to scale about as well as the software that they create.

One of the big benefits of a distributed architecture is providing a structure for communication and collaboration with large numbers of people. The fundamental problem that everyone is trying to solve is reducing friction. The funny thing about friction is that it is caused by different things depending on the size and makeup of the organization.

So, stepping back for a moment, one of the prerequisites of making these decisions is understanding what sort of service and what sort of company you’re trying to build.

What sort of growth do you expect, in terms of users and traffic, but more importantly in terms of your engineering team?

Are you on a rocket ship where you’re going to be going crazy from the very beginning and never stop with 100 developers before you know it?

Are you going to be growing organically and plan on keeping your team small for a few years?

These different paths will give you very different requirements. If you are planning on staying a small team (say, less than 3-5 engineers) for a few years, the friction you feel is going to be coming from some place different than communication and coordination between engineers.

When you’re starting out, and when you’re small, the speed at which you can make changes and improvements makes all the difference in the world. Having a bunch of separate services with interfaces and contracts just means that you have to make the same change in more places and have to do busywork to share code.

What can you do to reduce the friction required to push out that new feature or fix that bug? How can you reduce the number of steps that it takes to get a change into the hands of your users? Having code in a single repository, using an established web framework like Rails or Django can help a lot in reducing those steps. Don’t be scared of monolithic web apps when you’re small. Being small can be an advantage. Use it.

Predictions of the future are seldom accurate. Be mentally prepared for your architecture and your needs to be very different a year from now.

Never stop reevaluating your past decisions. It’s likely you’ll reach a point where you need to start breaking out your codebase into smaller components. Don’t consider that a failure of your past self.

A fundamental part of scaling a growing service is that you’re never done. If you are continuing to grow, there will always be more and different bottlenecks that crop up. There will never be a piece of technology or a style of development or architecture that will mitigate that.

Don’t try to be too clever. Assume you’ll have to change everything at some point in ways you never expected and don’t let that scare you. It’s a lot of fun.