One wonderful day you came up with an innovative business idea, one that could seize the market while your competitors were asleep. You quickly found investors, hired a team of software professionals, set them to the task, and … for the third week the team has been working on some kind of architecture without getting anywhere near implementing the core features. Is this the right way to develop software?
When we hear the word “architecture,” what comes to mind is urban planning. There, of course, architecture is important, because buildings are built to last, sometimes for centuries. But should you invest that much effort in software architecture? After all, the application needs to be introduced to the market and capture an audience as quickly as possible. So why not start with some ready-made boilerplate and focus on the solution itself?
To answer this question, you need to better understand the strategy for capturing the market with your business idea. The wrong architecture can be a headache when adding new features to the software and you’re constantly spending more to keep the system running smoothly. For some products, speed to market is important, but you may sacrifice usability for the sake of timeliness; other software demands special attention to ensure error-free, trouble-proof functioning from the start. (We all expect this from Internet banking, for example.)
So what is architecture in software?
The most popular architectural approaches
Among the main architectural approaches today are these three major categories:
- Monolith (or monolithic architecture)
- Service-oriented architecture (SOA), including microservices architecture
- Serverless architecture
A monolith is usually an application deployed as a single package. It is easier to work on such software at the very beginning of the project: everything is assembled using a single script; it is easier to maintain data integrity and compatibility, and it is easier to test. This is all workable as long as the application is small.
Service-oriented architecture implies that independent application modules are separated into singly deployed services. On one hand, this allows for parallelizing the work on the system being developed, while on the other hand, it increases the performance and fault tolerance of the application, thanks to the flexible scaling of its individual blocks.
The strangest beast is serverless architecture. Despite its name, there is still a server present in the application. It’s just that responsibility for its support, deployment, data storage, and access control has been shifted to the cloud. Cloud providers present almost infinitely scalable “functions” — a kind of code that can be run to compute certain algorithms. You can use Lambda by Amazon, or Functions by Google, and Microsoft Azure. One could compare serverless architecture to microservices, with a big “but”: in choosing serverless architecture, we’re bound more tightly to the cloud vendor while needing to ensure increased control over resource consumption. What is an advantage on the one hand — almost unlimited scaling of your functions — is also a disadvantage because it means paying more for those extra resources.
To figure out which architecture is best to implement for your project, let’s take a look at the pros and cons of these various approaches, depending on the stage of software development.
Development from scratch
So, the idea is outlined, you have a specification, and you’re ready to start developing a great product. At this stage, for most software, the main objective is to get to market quickly and win the hearts of users. But with limited investment, you’ll want to direct the bulk of your resources to developing the core of your idea (those goodies that should attract users), and not to standard service functions. Well, who can you surprise with a login page, even if it is animated with the help of the X-Men from the Marvel Universe?
These requirements are best met by a monolith: application deployment is simplified as much as possible; developers can quickly add new features and be minimally distracted by architecture issues; you have a single data structure, which allows you to ensure data integrity; the whole team is aware of all changes in the system. An additional plus is the absence of restrictions when choosing a technology stack.
Serverless architecture comes second, especially when developing mobile apps: in this case, the team is focused on adding new features to the mobile part, while server functions (such as user management, data exchange, and perhaps even the computing of some algorithms) are outsourced to the cloud side. Serverless architecture does imply some dependence on the cloud vendor. And when using Amazon’s Lambda or Google Functions, we also get additional restrictions imposed on the technology stack.
As for SOA and microservices architecture, these approaches are significantly inferior in terms of infrastructure support, because each separate service requires a separate deployment, fault tolerance control, and access control. Plus, at the initial stage of the project, it is not always clear what actually should be allocated into a separate service, where the greatest load in the application will be, and which of the services is the most important for the entire system’s functioning.
Stage of active product development
So it’s happened — you’re being noticed around the world! Your product is successful, you’re getting a return on your investment — and now it turns out that the system can’t bear the load of so many users. You add resources, but users keep arriving, the servers can’t cope, you get more and more feedback, the processing of which requires an ever-faster response, resources are becoming more and more expensive, users begin to grumble.
You expand the development team, break it down into subteams, parallelize processes, and face the fact that the developers are preventing each other from making changes. Deployments have become more frequent to ensure a quick response to user complaints, but the testing team is unable to re-check the entire system in a short time.
The pros of the monolithic approach became the cons.
And here the chief architect comes to you and says: “Let’s look towards SOA.”
The benefits of service architecture, in this case, are undeniable: you only make changes to the service that is required. The rest of the system continues to work stably. Fewer changes, less testing, less labor to deploy new functionality. Moreover, scaling can also be applied only to individual services (or even microservices), and therefore the process requires fewer resources and costs less.
Dividing the system into services allows you to divide your teams up according to responsibility for certain parts of the software and thereby minimize conflicts between developers. Of course, when global changes are necessary, integration of all parts of the application becomes more complicated. The disadvantage is also that this is a more complex infrastructure, consisting of a large number of system nodes that need to be orchestrated.
It’s worth mentioning that one of the advantages of SOA is that it offers a more flexible model for differentiating access to data and the ability to use data engines that are more suitable for your purposes. For example, if your service is responsible for calculating relations between users in the system, then these relations are most likely best stored in a graph database. At the same time, the service responsible for billing can work with the relational database.
Also, at the stage of active product development, you can easily expand your system by implementing some serverless parts. For instance, to invoke Amazon Lambda from your application, only minor architecture changes might be needed.
Maintenance phase
Sooner or later, all systems come to the maintenance phase. This may be support for the entire application or some of its blocks that do not look promising in the future. For the most part, the development of the product is complete, but it is still in demand and generates income. During this phase, modifications may also be made to the codebase — a bugfix, implementing small enhancements, or adapting the application to changes in the runtime environment (for example, the product needs improvements because the operating system or web browser has been updated).
At this stage, it’s important to reduce infrastructure costs and keep the system in working condition, to retain users as long as possible. The Continuous Integration & Deployment process is more in demand than ever. If properly configured, this guarantees stable delivery of the necessary changes.
For this phase, a well-balanced SOA looks ideal. When changes need to be made, fewer system components are affected, outdated services are easier to decommission, and resource allocation is more granular. When using modern approaches to orchestrate complex systems (such as Kubernetes) in combination with cloud services, it minimizes the costs of operation and administration.
Of course, if you come to this stage with a monolith, it doesn’t make sense to invest in migrating it to SOA.
What have we come to?
Let’s summarize all the considered pros and cons in the table below:
| Criterion | Monolith | SOA / Microservices | Serverless |
|---|---|---|---|
| Development speed from scratch (speed to market) | ✔ | – |
?
If your team is familiar with serverless functions provided by this or that cloud, the development will be rather fast. |
| Dependency on the technology stack | – | ✔ | ?
Cloud-based code can be written in a limited set of programming languages. For example, Amazon Lambda natively supports Java, Go, PowerShell, Node.js, C #, Python, and Ruby. |
| Easy to deploy at the beginning of the project | ✔ | – | ?
Depends on how many serverless features you are using. The more cloud services you use, the harder it is to deploy in the beginning. |
| Difficulty to support different test environments | ✔ | – | ✔ |
| Ease of delivery of changes through continuous integration and deployment. | – | ✔ | ✔ |
| Ease and low cost of maintenance (bugfix, adaptation and improvements) | – | ✔ | ?
Cloud services can add some limitations to the system under maintenance. At some point, you may be faced with the need to find a workaround to implement a particular solution. |
| Scaling (cost, flexible resource allocation scheme) | – | ✔ | ?
You need to be very careful here. Serverless functionality can scale with virtually no limits and you can devote too many resources to it, which gets expensive. |
| Cybersecurity and Data Access Differentiation | ?
You can develop fairly good security and differentiate access to data in the monolith too, but you will have to put more effort into this compared to the modular approach in SOA. |
✔ | ✔ |
| Fault tolerance and disaster recovery of the system, operational monitoring | – | ✔ | ✔ |
| Data integrity, transparent data model, everything in a single database | ✔ | – | – |
| Using more appropriate data engines, differentiation of access to caches | – | ✔ | ✔ |
| Service provider independence | ?
A monolith can be entirely transferred to another team for maintenance, while SOA provides the ability to transfer separate modules to different teams for support and development. |
✔ | – |
Conclusion
Unlike urban planning, architecture in software is a flexible concept, and at each stage of the project, a different approach may be needed. To be sure that the transition from monolithic to service-oriented architecture or the implementation of serverless parts doesn’t become a headache, you need to audit the system regularly for its compliance with business requirements. The professionals on our team will help you with both a technical assessment of your existing system and the architectural design of a new project.
