Microservices vs Monoliths: A Guide for Startups
The process of startups taking software from concept to rollout is far from straightforward. Coming up with a dynamite idea for a product is one thing. Agreeing on how to build, maintain and scale it is quite another, and can often devolve into a development team at loggerheads with each other and the CTO.
Constructing the architecture of an application traditionally draws people into one of two camps, which is often where these disagreements stem from. For some, the more traditional concept of a unified, centralised software framework is the ideal situation, such as those utilised by tech companies like Uber in their early stages. This is approach is known as ‘monolithic’.
However, in recent years, a new modular approach has become increasingly prevalent in startups’ product development. Dubbed ‘microservices’, this new approach to application architecture is far more decentralised. It offers developers the ability to work on individual parts of a larger software framework separately, yet still have it as part of a larger unified structure.
Below, we’ll take a closer look at microservices, and weigh up their pros and cons against the traditional monolithic structure for software development teams.
What are Microservices?
An application being developed by a tech startup may appear to be simple, but even the most outwardly simple products require a great number of complementing systems and data sources working in tandem.
It is this modular nature of software products that have given rise to microservices. The basic idea is to allow developers to divide an overall application into a collection of smaller, independent services, each of which has its own data store and communicate with one another through an API. The ‘plug and play’ nature of microservices allows them to be developed, altered and replaced with ease, with no impact on the functioning of the overall application they are part of.
These microservices, while making up a larger unified system, do not have to share the same coding architecture as one another. Developers can build one service using MongoDB and Java, while using Ruby for another.
The Rise of Microservices for Startups
The centralised monolith architecture was the undisputed norm for years. We even saw the biggest tech startups such as Netflix and Uber initially building their applications this way. However, as their businesses have scaled and diversified, both have branched out into microservice development with Uber, for example, sharing how they achieved this in a blog post on their service-oriented architecture.
Why have microservices been adopted by so many startups in recent years? A large contributing factor is the reduction in technical limitations, aided by the proliferation of cloud services such as AWS. Now, the lower price points and ease of access to cloud services aids the development of distributed applications, especially for startups, who can adjust their resource load geographically. In addition, startups can now take advantage of lower costs for RAM, multicore machines, and faster, more reliable network connections.
Scope for Blockchain Integration
For microservices to be utilised to their full potential, the handling of developing and integrating smaller applications into the larger architecture must be agile, with a key focus on the fast distribution of work.
Developers are sharing solutions using open source code, but the logistics of having a huge collection of microservices communicating across a crowded API landscape is posing security questions, especially considering the large number of participants in the larger microservices ecosystem.
Blockchain is presenting itself as a possible solution for the API security issue. Microservices rely on digital coordination as part of a distributed ecosystem, especially in relation to their own respective coding architectures and data sources. Therefore, the integration of blockchain as the key coordination mechanism could allow enterprises to realise the benefits of trustless and agile data coordination, also adding in a level of control over the ways microservices interact with their data.
With all this taken into account, we’ve drawn up a list of pros and cons that startups should consider before committing to building their application architecture around the microservices model.
Pros
Independent Deployment
Microservices are a boon for developers looking to roll out updates and upgrades to application architectures, thanks to their modularity. Microservices can be swapped out individually, without the need to take the entire application offline, as can be necessary when using the more traditional centralised monolithic structure.
Developer Independence and Specialisation
Smaller dev teams can be formed to focus on specific microservices, which can speed up internal processes, and allow for easier hiring of specialised skill sets. Faster development cycles can also become possible.
Scalability and Performance
Microservices allow for easy scalability because of their independence from one another. As operational demands increase on one of these services, it is easier to detect these hot services and bottlenecks within the larger framework of the application and respond accordingly.
Avoiding Technological Lock-in
Developers have the option of building microservices using different languages and technology stacks, which avoids the over-reliance on and long-term commitment to any particular vendors.
Cons
Complexity
Each microservice is its own application, which requires its own testing, release and ongoing monitoring. For delivery workflow to be efficient, it often has to be automated, which requires additional work and infrastructure to accommodate.
Business Organisational Changes
For each microservice dev team to have the independence required to adequately manage their own products, there needs to be a clear and defined shaping of the overreaching business structure to allow for proper delegation of responsibilities for technical decisions and new builds. This can cause friction in more traditional management structures.
Unreliable Communications
As microservices run on their own separate processes and communicate over APIs, there is the risk of communication failure between different points of the application. Multiple databases need to be updated, so developers are faced with challenges to ensure that each of these points is functioning correctly.
Operational Overheads and Performance
Because microservices are frequently deployed on their own virtual machines, this can require more dedicated VM work for developers. Also, communication over a network is invariably slower than in memory. Companies need to ensure that their network speeds are maintained over the course of a product’s development.
Microservices offer a lot of benefits for startups if they choose to properly invest in the organisational adaptations that they require over the more traditional monolith infrastructure. As stated previously, hugely successful startups such as Uber have seen great success in adapting their monolithic structures into microservices, but their success should not be taken as a ‘one size fits all’ rule. Instead, it is essential for startups to consider their intended company growth projections, and whether they can seriously foresee an infrastructure change as viable.
