Designing Application Stack for an Early Startup
Before your application stack grows into behemoth size it is better to cut this monstrous creature into eatable pieces. Even if this declaration could sound strong and mysterious I have to admit I saw such huge application environments in several firms. It was almost impossible to recreate it for failover purpose. If anything failed there was still some man on 24/7 duty who watched analytic data and was ready to fix broken part. The success of application was on their shoulders. To be absolutely honest I was also the guy on beginning of my career who designed a few such applications.
As time flies there was always some stakeholder or sponsor who decided to improve the hopeless situation. But this is always long run cutting on phases, a lot of discussions between involved parties, many compromises and unflagging effort of few dreamers. But if you are visionary you will always be fed by ideas and energized by hope of better future.
I appeal on you who are CTOs or architects in an young companies and startups you have a great chance to prepare better future for your successors. If you will smart plan your application(s) you will get competitive advantage with a small effort at the start.
In this article I will design application stack of fake SaaS application. I will discuss each its part and impact on development and test. I will broadly use microservices but no because they are modish, instead I will focus on its testability benefit.
Application stack use cases
You have to think about your little startup as developing of product as well as selling it to users. To win the battle it is important to concentrate at both with same effort. And you will probably use and implement several tools to accomplish your goals. Your application stack could look like:
- The main SaaS application is running in browsers as web application and on mobile platforms as native apps.
- All these user applications call application public REST API backend service.
- Users needs to be login if they want to work with application.
- There are several subscriptions – Free, Standard and Premium enabled different features of application.
- To help managing user base startup has 3rd party CRM system.
- The CRM is used by sales and customer service as well as SaaS application to obtain subscription level.
- For subscription model startup uses 3rd party e-commerce system as their pay portal.
- Marketing department uses several 3rd party marketing tools that produces leads and evaluates their ready-to-buy status.
- Leads are stored in CRM.
- Startup has its own web site, that presents their product and pricing.
- There is lending page section, support different marketing campaigns.
- As part of site there is a blog section, supports content marketing.
- Senior management has reporting and analytic tools that measure efficiency of startup and help them make decisions.
I could introduce much more systems, but for early-staged startup it could be enough. For many CTOs this could be a nightmare, but do not panic and stay cool. Take a deep breath and start to plan you application stack.
Decomposing the complexity
The first rule in application stack design is to stay 3rd party tools as are. The next rule is do not fear of mirroring the data into your storage, you will do it sooner or later. And the last not least is layering, layering and layering.
Let’s move on these components and start from bottom:
- 3rd party e-commerce, marketing and sales tools – each of them is an independent component and the hook ups will be solving in middle ware.
- For each connected tool we implement own proxy service for communication with toll and one reverse service when tool will communicate to our application stack. Each service is a component or sub-component with own lifecycle. Here is very important the abstraction of API so we will not introduce tool specific types into system.
Note: remember startup is nothing but change. They tend to exchange tools as often as they discover new better shiny one. If you will have these little proxy and reverse services, you will probably have easier job.
- On other side we have our SaaS user applications and their backend services. Web application and its backend is also another system component.
Note: it is obvious that the UI frontend applications both SaaS and web will communicate only with their backend layer. And those could communicate with the rest of system.
- And in the center is sitting middle ware often implemented as service tier. Service tier could be set of microservices and messaging queues for synchronous and asynchronous workflow and dataflow.
Note: This is most difficult part of design. There are many aspects that have impact on decisions (and I do speak mainly in terms of decomposition and separation of concern). I will suggest to create as many services as they make sense and merge similar functionality together. (but not everything related to customer musts be in the same CustomerService!)
- And probably last 4th type of components is data stores. It could be databases, data warehouses or content files.
Note: I suggest to implement a proxy service(s) for communication with data store. This could also simplify the future changes.
It could seem I propose to mix SaaS product with business application, but it is not exactly true. I just said there are more or less data which are shared and synchronized between SaaS and usually CRM and data synchronization is responsibility of middle ware.
From the chapter above is obvious our application stack will contain 3rd party tools, some databases, or data stores, several REST services for middle ware layer, web site, public API for our SaaS application and finally several applications submitted in various marketplaces.
The built infrastructure will depend on preferring component organization and deployment model. There is almost no debate on how to build web site, or databases. But the microservices could be deployed in several ways, as set of web apps on a few servers, as independent service each on own server, or as a Docker containers. There are pros and cons of each and final choice will be more on experience, used technology and the given budget.
If you will build your infrastructure using VMs on Azure the interesting thing is organizing VMs in Virtual Networks, Network Security Groups and so forth. This could help you to create a boundaries between components and for instance separate public web site from all other internally used components.
This article was mainly discussion on how to design application stack from early stage of your startup. There is not one best solution but technical founder or CTO has to think in terms of all software future IT and development team will support. There will be many tools which will be sooner or later integrated into company business application system. You need to think of this from beginning when designing architecture.
In some future article I will show hot to architect and build application stack on Azure and prepare the environment for development, test and production. I will automate as much as possible, so the whole or part of environment could be recreate many times.