Choosing the Right Software Architecture for Start-Ups (Past VS Present)

Choosing the Right Software Architecture for Start-Ups (Past VS Present)

Choosing the Right Software Architecture for Start-Ups (Past VS Present) September 3, 2020 Software system design plays a critical role in the evolution of a start-up. In the present day, the abundance of technologies and frameworks offers a lot more options in choosing the right stack and a clean architecture that benefits the team and business. In my 10 years of working in tech start-ups, I have experienced and witnessed how the use of technology to actualize ideas have evolved over time. I have worked on projects of diverse nature, some with ideal tech but average product-market fit, and others with subpar tech but strong product-market fit. Yet, till this day, I seldom see the powerful combination of solid technology with excellent product-market fit in young start-ups. Nothing unexpected, given the ever-changing nature of early age start-up projects. As we all know, start-ups are notorious for being fast-paced with deadlines and priorities often changing. In this article, we will take a look at the typical software architecture that tech start-ups use in the past, and compare it with the set-up that modern start-ups (including us at Omniaz) can now adopt. Past: The Problem With Monolithic Tech Architecture Traditionally, tech start-ups start with a monolithic tech architecture (i.e. one application performing all functions). The goal is to create a minimum viable prototype (MVP), get feedback, and then potentially make a new, clean start afterwards. But more often than not, this “clean start” never happens due to timeline pressures, costs, and situational urgency. Instead, teams end up building upon what is already available (although initially meant to be a “throwaway” prototype). Eventually, the product evolves with new features and requirements until they become difficult to work on with few key people actually understanding what is going on. This leads to high team turnover rate, slowdown in development of the product, bugs and performance issues, a lack of scalability and inherent security loopholes that are difficult to track. Left: Ideal monolithic system architecture. Right: Reality of a continuously evolving monolithic architecture. New functionalities are not accounted for in the beginning and difficult to add as the project grows. A monolithic system limits the movement of and within a business because radical changes, expansion plans, migrations and other events depend on the elasticity of both the team and the technology. Not to mention, regulations on data protection and cyberthreats are more inescapable now than they were a decade ago, piling on to the complexity of developing any kind of software. As a result, the start-up may have to pass up certain opportunities due to missed deadlines and ballooning costs in trying to mitigate unforeseen issues arising from working off a monolithic system. Present: Modular Systems & Cohesive Stacks to the Rescue So, what is the tech architecture that hits the sweet spot between satisfying business needs, regulatory compliance and user expectations? For us at Omniaz, our project started at a favourable time when certain emerging technologies facilitated the curation of our tech architecture. Distributed and modular system architecture enables better team dynamics and the ability to use the best technology to solve each problem. Addition of new features can be done seamlessly with clear separation of concerns, business logic and code ownership. Modular Systems When talking about modular systems from a server side perspective, we refer to distributed application frameworks (gRPC) which make it easy to encapsulate the business logic as microservices. Coupled with high performance programming languages (Golang) as well as machine learning (ML) specific languages (Python), this approach makes the codebase easier to maintain. Also, since gRPC relies on language-agnostic interfaces for the RPC definition, it makes documentation of the interfaces a breeze and allows teams working on different stacks to collaborate easily. On the client side, we leverage the power of React Native that makes it easy to maintain one codebase for both Android and iOS platforms. It also supports integration of native Android and iOS codes which in turn allows us to integrate lower level components written in C++. This is crucial for our products since we are able to package our AR/AI powered SDK for integration in third-party applications. With a modular approach in mind from the very beginning, it is possible to use multiple programming languages and libraries that are best suited for solving specific problems. This is very useful especially when combining technologies such as AI/ML, AR, data collection and processing. For the team, it means that they can scale flexibly both in the diversity of technologies used and in the number of people working with one technology due to the clean separation of business logic into small code bases. Cohesive Stacks Another aspect is the emergence of cross-platform technologies (React Web, React Native) and modern API frameworks (GraphQL) which allows for synergy within the stack. Cohesive stacks enable cross-functional teams particularly in the area of web or mobile development by making use of technologies such as React Web/Mobile. Since a similar stack and framework is used for all client applications, the engineering team has the ability to communicate more efficiently since they speak the same “language”, and contribute to multiple code bases. This allows a small team to work more effectively, share knowledge and complement each other's skills. GraphQL is powerful in reducing the API maintenance overhead by empowering the client applications to perform queries on available schemas. This is a big advantage over REST architecture not only in terms of change requests but also in the ability to query only the required data points. At the same time, it has implementations in multiple languages which makes it easy to adopt within the stack. It is also an excellent choice as an abstraction layer in front of the microservices cloud (gRPC interfaces again proved useful here) as it can expose a common easy-to-use interface for the client applications. Cloud-Native Infrastructure When talking about the modularity and cohesive stacks coming together, there can be no better example than a distributed system architecture (microservices) running on Docker and Kuberneters. We see maturation of containerization and orchestration technologies that are adopted by big cloud providers, offloading a lot of infrastructure work on the long term while maintaining good system metrics (availability and performance) and visibility (through monitoring and alerting). These trends and supporting technologies allowed us to build a system that is robust, scalable, and combined with the use of open-source technologies cloud-agnostic. In a Nutshell Still, there is no “one size fits all” approach for every start-up or business. There are drawbacks to this method, such as: stack diversity which increases the number of skills required within the team; initial speed to market is slower due to additional complexities in the system setup; and distributed systems come with specific design patterns and challenges. If you are developing an innovative technology for products and/or businesses that need to evolve rapidly with market needs and scale across different regions, it is worth exploring the ideas in this article. On the other hand, if you are building something more traditional such as an e-commerce platform, it is better to work with established technologies and frameworks that encapsulate years of tried and trusted know-how in the respective fields.
Choosing the Right Software Architecture for Start-Ups (Past VS Present) September 3, 2020 Software system design plays a critical role in the evolution of a start-up. In the present day, the abundance of technologies and frameworks offers a lot more options in choosing the right stack and a clean architecture that benefits the team and business. In my 10 years of working in tech start-ups, I have experienced and witnessed how the use of technology to actualize ideas have evolved over time. I have worked on projects of diverse nature, some with ideal tech but average product-market fit, and others with subpar tech but strong product-market fit. Yet, till this day, I seldom see the powerful combination of solid technology with excellent product-market fit in young start-ups. Nothing unexpected, given the ever-changing nature of early age start-up projects. As we all know, start-ups are notorious for being fast-paced with deadlines and priorities often changing. In this article, we will take a look at the typical software architecture that tech start-ups use in the past, and compare it with the set-up that modern start-ups (including us at Omniaz) can now adopt. Past: The Problem With Monolithic Tech Architecture Traditionally, tech start-ups start with a monolithic tech architecture (i.e. one application performing all functions). The goal is to create a minimum viable prototype (MVP), get feedback, and then potentially make a new, clean start afterwards. But more often than not, this “clean start” never happens due to timeline pressures, costs, and situational urgency. Instead, teams end up building upon what is already available (although initially meant to be a “throwaway” prototype). Eventually, the product evolves with new features and requirements until they become difficult to work on with few key people actually understanding what is going on. This leads to high team turnover rate, slowdown in development of the product, bugs and performance issues, a lack of scalability and inherent security loopholes that are difficult to track. Left: Ideal monolithic system architecture. Right: Reality of a continuously evolving monolithic architecture. New functionalities are not accounted for in the beginning and difficult to add as the project grows. A monolithic system limits the movement of and within a business because radical changes, expansion plans, migrations and other events depend on the elasticity of both the team and the technology. Not to mention, regulations on data protection and cyberthreats are more inescapable now than they were a decade ago, piling on to the complexity of developing any kind of software. As a result, the start-up may have to pass up certain opportunities due to missed deadlines and ballooning costs in trying to mitigate unforeseen issues arising from working off a monolithic system. Present: Modular Systems & Cohesive Stacks to the Rescue So, what is the tech architecture that hits the sweet spot between satisfying business needs, regulatory compliance and user expectations? For us at Omniaz, our project started at a favourable time when certain emerging technologies facilitated the curation of our tech architecture. Distributed and modular system architecture enables better team dynamics and the ability to use the best technology to solve each problem. Addition of new features can be done seamlessly with clear separation of concerns, business logic and code ownership. Modular Systems When talking about modular systems from a server side perspective, we refer to distributed application frameworks (gRPC) which make it easy to encapsulate the business logic as microservices. Coupled with high performance programming languages (Golang) as well as machine learning (ML) specific languages (Python), this approach makes the codebase easier to maintain. Also, since gRPC relies on language-agnostic interfaces for the RPC definition, it makes documentation of the interfaces a breeze and allows teams working on different stacks to collaborate easily. On the client side, we leverage the power of React Native that makes it easy to maintain one codebase for both Android and iOS platforms. It also supports integration of native Android and iOS codes which in turn allows us to integrate lower level components written in C++. This is crucial for our products since we are able to package our AR/AI powered SDK for integration in third-party applications. With a modular approach in mind from the very beginning, it is possible to use multiple programming languages and libraries that are best suited for solving specific problems. This is very useful especially when combining technologies such as AI/ML, AR, data collection and processing. For the team, it means that they can scale flexibly both in the diversity of technologies used and in the number of people working with one technology due to the clean separation of business logic into small code bases. Cohesive Stacks Another aspect is the emergence of cross-platform technologies (React Web, React Native) and modern API frameworks (GraphQL) which allows for synergy within the stack. Cohesive stacks enable cross-functional teams particularly in the area of web or mobile development by making use of technologies such as React Web/Mobile. Since a similar stack and framework is used for all client applications, the engineering team has the ability to communicate more efficiently since they speak the same “language”, and contribute to multiple code bases. This allows a small team to work more effectively, share knowledge and complement each other's skills. GraphQL is powerful in reducing the API maintenance overhead by empowering the client applications to perform queries on available schemas. This is a big advantage over REST architecture not only in terms of change requests but also in the ability to query only the required data points. At the same time, it has implementations in multiple languages which makes it easy to adopt within the stack. It is also an excellent choice as an abstraction layer in front of the microservices cloud (gRPC interfaces again proved useful here) as it can expose a common easy-to-use interface for the client applications. Cloud-Native Infrastructure When talking about the modularity and cohesive stacks coming together, there can be no better example than a distributed system architecture (microservices) running on Docker and Kuberneters. We see maturation of containerization and orchestration technologies that are adopted by big cloud providers, offloading a lot of infrastructure work on the long term while maintaining good system metrics (availability and performance) and visibility (through monitoring and alerting). These trends and supporting technologies allowed us to build a system that is robust, scalable, and combined with the use of open-source technologies cloud-agnostic. In a Nutshell Still, there is no “one size fits all” approach for every start-up or business. There are drawbacks to this method, such as: stack diversity which increases the number of skills required within the team; initial speed to market is slower due to additional complexities in the system setup; and distributed systems come with specific design patterns and challenges. If you are developing an innovative technology for products and/or businesses that need to evolve rapidly with market needs and scale across different regions, it is worth exploring the ideas in this article. On the other hand, if you are building something more traditional such as an e-commerce platform, it is better to work with established technologies and frameworks that encapsulate years of tried and trusted know-how in the respective fields.
EN

Choosing the Right Software Architecture for Start-Ups (Past VS Present)

September 3, 2020
Software system design plays a critical role in the evolution of a start-up. In the present day, the abundance of technologies and frameworks offers a lot more options in choosing the right stack and a clean architecture that benefits the team and business.
In my 10 years of working in tech start-ups, I have experienced and witnessed how the use of technology to actualize ideas have evolved over time. I have worked on projects of diverse nature, some with ideal tech but average product-market fit, and others with subpar tech but strong product-market fit.
Yet, till this day, I seldom see the powerful combination of solid technology with excellent product-market fit in young start-ups. Nothing unexpected, given the ever-changing nature of early age start-up projects. As we all know, start-ups are notorious for being fast-paced with deadlines and priorities often changing.
In this article, we will take a look at the typical software architecture that tech start-ups use in the past, and compare it with the set-up that modern start-ups (including us at Omniaz) can now adopt.

Past: The Problem With Monolithic Tech Architecture

Traditionally, tech start-ups start with a monolithic tech architecture (i.e. one application performing all functions). The goal is to create a minimum viable prototype (MVP), get feedback, and then potentially make a new, clean start afterwards. But more often than not, this “clean start” never happens due to timeline pressures, costs, and situational urgency.
Instead, teams end up building upon what is already available (although initially meant to be a “throwaway” prototype). Eventually, the product evolves with new features and requirements until they become difficult to work on with few key people actually understanding what is going on. This leads to high team turnover rate, slowdown in development of the product, bugs and performance issues, a lack of scalability and inherent security loopholes that are difficult to track.
Left: Ideal monolithic system architecture. Right: Reality of a continuously evolving monolithic architecture. New functionalities are not accounted for in the beginning and difficult to add as the project grows.
A monolithic system limits the movement of and within a business because radical changes, expansion plans, migrations and other events depend on the elasticity of both the team and the technology. Not to mention, regulations on data protection and cyberthreats are more inescapable now than they were a decade ago, piling on to the complexity of developing any kind of software. As a result, the start-up may have to pass up certain opportunities due to missed deadlines and ballooning costs in trying to mitigate unforeseen issues arising from working off a monolithic system.

Present: Modular Systems & Cohesive Stacks to the Rescue

So, what is the tech architecture that hits the sweet spot between satisfying business needs, regulatory compliance and user expectations?
For us at Omniaz, our project started at a favourable time when certain emerging technologies facilitated the curation of our tech architecture.
Distributed and modular system architecture enables better team dynamics and the ability to use the best technology to solve each problem. Addition of new features can be done seamlessly with clear separation of concerns, business logic and code ownership.
Modular Systems
When talking about modular systems from a server side perspective, we refer to distributed application frameworks (gRPC) which make it easy to encapsulate the business logic as microservices. Coupled with high performance programming languages (Golang) as well as machine learning (ML) specific languages (Python), this approach makes the codebase easier to maintain. Also, since gRPC relies on language-agnostic interfaces for the RPC definition, it makes documentation of the interfaces a breeze and allows teams working on different stacks to collaborate easily.
On the client side, we leverage the power of React Native that makes it easy to maintain one codebase for both Android and iOS platforms. It also supports integration of native Android and iOS codes which in turn allows us to integrate lower level components written in C++. This is crucial for our products since we are able to package our AR/AI powered SDK for integration in third-party applications.
With a modular approach in mind from the very beginning, it is possible to use multiple programming languages and libraries that are best suited for solving specific problems. This is very useful especially when combining technologies such as AI/ML, AR, data collection and processing.
For the team, it means that they can scale flexibly both in the diversity of technologies used and in the number of people working with one technology due to the clean separation of business logic into small code bases.
Cohesive Stacks
Another aspect is the emergence of cross-platform technologies (React Web, React Native) and modern API frameworks (GraphQL) which allows for synergy within the stack.
Cohesive stacks enable cross-functional teams particularly in the area of web or mobile development by making use of technologies such as React Web/Mobile. Since a similar stack and framework is used for all client applications, the engineering team has the ability to communicate more efficiently since they speak the same “language”, and contribute to multiple code bases. This allows a small team to work more effectively, share knowledge and complement each other's skills.
GraphQL is powerful in reducing the API maintenance overhead by empowering the client applications to perform queries on available schemas. This is a big advantage over REST architecture not only in terms of change requests but also in the ability to query only the required data points. At the same time, it has implementations in multiple languages which makes it easy to adopt within the stack. It is also an excellent choice as an abstraction layer in front of the microservices cloud (gRPC interfaces again proved useful here) as it can expose a common easy-to-use interface for the client applications.
Cloud-Native Infrastructure
When talking about the modularity and cohesive stacks coming together, there can be no better example than a distributed system architecture (microservices) running on Docker and Kuberneters. We see maturation of containerization and orchestration technologies that are adopted by big cloud providers, offloading a lot of infrastructure work on the long term while maintaining good system metrics (availability and performance) and visibility (through monitoring and alerting). These trends and supporting technologies allowed us to build a system that is robust, scalable, and combined with the use of open-source technologies cloud-agnostic.

In a Nutshell

Still, there is no “one size fits all” approach for every start-up or business. There are drawbacks to this method, such as:

• stack diversity which increases the number of skills required within the team;
• initial speed to market is slower due to additional complexities in the system setup; and
• distributed systems come with specific design patterns and challenges.

If you are developing an innovative technology for products and/or businesses that need to evolve rapidly with market needs and scale across different regions, it is worth exploring the ideas in this article. On the other hand, if you are building something more traditional such as an e-commerce platform, it is better to work with established technologies and frameworks that encapsulate years of tried and trusted know-how in the respective fields.