Building applications at scale and that scale..

‘Building application at Scale’ was a topic of discussion in one of the group I am part of. Following is my take.

I got a bit confused – is focus on ‘buildings applications at scale‘ or ‘building applications that scale’. Both are slightly different. Let’s distinguish.

By ‘building applications at scale‘ I mean –

1. You have a large application to be built and with a large team as fast as possible.

2. You have a lot of applications to be built with a large team, and you are churning out applications at scale. 

By ‘building applications that scale‘ I mean the application is built for horizontal scaling. In other words, a ‘cloud native application‘.

May take on ‘building applications at scale‘.

1. Divide a large application into micro applications. Such that each micro application should not need a team of more than 20 odd developers. 

2. Obviously, micro applications got to interact, so interfaces must be defined clearly. Adopt API first approach. Define interfaces and interactions between the applications using API (You may want to use api blueprint to define the interfaces and use the likes of apiary to host API mocks). This reduces friction between teams and requirements of inter-application communication are well documented and testable. Inter-application seams become more seamless.

3. Needless to say, this kind of development essentially indicates a microservice-based architecture.  Each application is developed as a microservice with a definite set of requirements. Development of such microservices can happen fast and concurrently.  Advantage with microservices is also that deployment time reduces drastically. 

4. Microservices for back-end is well-understood design pattern, however how about front-end. If it is one big application, it’s difficult to divide UI development like microservices and still achieve a coherent user interface. It’s a challenge. ‘Micro Frontend’ could be of some help here. Worth trying it. 

5. I am not a great fan of reusable components. If the requirement of the component in itself is reusable, then the component automatically becomes reusable. For instance, a component which establishes a connection to cache service. This is naturally reusable component and does not change service to service. Generally, when we try to build a re-usable component, we spend a lot of time in generalizing it so that it fits in various situation. Analysis becomes paralysis. Eventually, the component becomes heavy and buggy. And ultimately, it dies a death by generalization.

6. Heroku team had come out with 12 Factor application concept. Kevin Hoffman adds a few more to it in ‘Beyond the Twelve-Factor App‘ for building applications that scale on the cloud. Excellent suggestions.

I think 12 Factor++ (points including that added Kevin) is not just the way to ‘build applications that scale‘ but also to ‘build applications at scale‘.