When developing software, you can choose between architectures, the most common of which are Monoliths and Microservices. Serverless Lambdas technology is a great complement of these two. What separates these solutions is much more than their creation date. Substantial differences exist in their operation schemes, level of complexity, speed of development, and the efficiency of their final applications. Each application is specific, and it would be a huge mistake to neglect their benefits. So do we really have to choose between monoliths, microservices and lambda functions?
Coexistence between software development architectures
Extensively experienced software houses know the architectures that are most beneficial for their customers. At Stepwise, we have frequently encountered situations where one particular architecture is perfectly suited to a given IT project. We were able to identify the project requirements early on, and the customer’s business needs were clear and possible to estimate at the end of the project.
Software development is an extremely dynamic and flexible matter. In the vast majority of IT projects, business needs change over the course of developing the application. Software needs to be adapted to the market environment and the needs of potential users and customers on a current basis. Software companies should establish practices that facilitate the adjustment of changes in projects. This is not only about purely technological issues, but also about the attitude to IT team management and project risk management.
Before responding to the question: “Do we really need to choose just one technological solution?”, it is worth explaining what constitutes each methodology and their specific benefits. We have chosen three tremendously popular types:
- Monolithic architecture
- Microservice architecture
- Lambda functions
Monolithic architecture
The monolith is the oldest of the selected architectures, with all functions built into one compact system. In order to illustrate its nature more thoroughly, let’s use an analogy from the construction industry.
Imagine a house with walls, ceiling, stairs and other elements, made from cement instead of concrete blocks. In the construction industry, the monolith is exactly this construction – made totally from one binding material.
Monolithic architecture in software development means that an application is built as one whole. One house made from concrete. Though it is the oldest architecture, it is still one of the leading approaches used for application development by multiple companies in the market. This mostly concerns MVP projects and PoCs.
The principle of operation is simple. Monolithic software is self-contained and independent from other applications. One system is responsible for all the functionalities of an application and uses one database. What differentiates it from other architectures is when making changes. Any modifications affect the entire system, which is why any changes in the code require thorough checking of the application operation.
Software creation should in many cases begin with this particular approach. The monolith is by assumption simpler, and makes it easier to handle the entire code enclosed in one “block”. All functionalities are connected in a simple manner, and the single database (one source of knowledge for the application) excludes any additional integration and combining of various technologies.
A monolithic application is created entirely in one unit (one file or container). A single instance of the application is intended to meet all the business and technical requirements of the digital product.
Pros and cons of monolithic architecture
| Pros | Cons |
| + a low barrier to entry for developers + simpler structure + one database + easy to test + simple to deploy + lower costs + faster development of applications (e.g. MVP) | – less scalable – failure affects the entire application – costly to make changes – complex integration with other technologies – difficulty with multiple teams working over the code simultaneously – changes can affect the entire system |
Microservice architecture
Microservice architecture is relatively young and involves creating more (sometimes many more) artefacts. Each artefact has limited functionality, and each functionality should correspond to a specific business need. Microservices require one or more servers.
Let’s use the analogy from the construction industry again. A microservice application can be compared to a house built from concrete blocks joined with cement. While the monolith should be a solid compact unit, microservices allow for combining smaller elements (mini applications), each responsible for a different functionality of the system. End users see all the microservices in the system as if it is one unit, yet in reality they are separate entities.
In more complex projects, modularity in software development is preferable. Changes in one functionality do not necessarily have to affect other segments of the system. In projects that involve several IT specialists, each of them can develop their parts of the software, without disturbing the others.
One example of software built with a microservice architecture would be an online video rental store, requiring a number of various modules performing particular tasks as part of the video rental process. A single module (microservice) could be the customer registration, adding a video to the cart, or making a payment.
Microservices need to communicate with each other, and as a result all the separate existences operate as one whole. End users do not notice this division. Each microservice can use a different knowledge base.
Microservices involve just a few software components, which is why the infrastructure that applications are built on needs to be more complex. Deployment of all the components can be done simultaneously, as each microservice can be implemented independently, not affecting other microservices. The testing environment is specific, and tests need to include the communication and relationships between all the functionalities.
This complicates the work, and it is often the case that instead of creating added value for a business, or taking care of the logics of an application and a positive UX, specialists have to devote significantly more time to the structure of an application and the right connection of particular microservices.
Pros and cons of microservice architecture
| Pros | Cons |
| + better for complicated/complex systems + proven by renowned brands + excellent scalability + allows for using a variety of technologies for various microservices + facilitates cooperation in a large IT team + a change in one service does not affect other services + easy control over technical debt | – requires a good division between the various services – requires complicated tests – complex structure – time-consuming overall changes in the system – greater complexity of IT projects – challenging debugging – operation dependent on the condition of the network infrastructure – more expensive |
Lambdas in software development architectures
Lambda functions were created several years ago, and are not an architecture in the true meaning of the word, but rather a way of building microservice applications with lambdas. Lambdas are a relatively simple fragment of the code in the form of a function that does not require a server. It is also possible to build a lambda for just one function. It all depends on the current needs.
For instance, when we need a simple smartphone application with a form to enter figures, a lambda makes it possible to perform tasks that could be too challenging for a mobile device. What is more, this technology allows for using internal and external sources of information in order to enhance a particular functionality. In this way, we can create one function that perfectly meets a specific business requirement.
There is value in highlighting that lambdas are currently available only in a cloud infrastructure. While monoliths and microservices can be used without a cloud infrastructure, lambdas are used precisely in the cloud. Major cloud suppliers offer their own lambda solutions, of which each is characterised by its own specificity defined by the manufacturer.
A lambda “is brought to life” in order to perform a particular task. After accomplishing its goal, it is extinguished. Lambdas can be used multiple times. They do not exist until they are necessary, and customers pay for their actual usage.
Simple applications do not require a whole team of developers to create a function – one IT specialist is sufficient. This allows for project cost optimisation, as we do not have to employ additional specialists for handling application servers and infrastructure.
Pros and cons of microservice architecture
| Pros | Cons |
| + does not require servers + easy creation and activation of small functionalities + easy operation + cost-effective when used to a limited extent + allows for creating lambdas in various programming languages + limited time of operation | – challenging testing in the case of complex applications – challenging debugging – available only in the cloud – problems with transfer between vendors |
Coexistence between microservices, monolithic architectures and serverless lambdas
Each of the presented architectures has its own specificity, strengths and weaknesses that should be taken into consideration when choosing architecture for your software. Stepwise experience shows that you do not need to limit yourself to one architecture, as monoliths, microservices and lambda can successfully coexist as part of one IT project.
A number of voices have been heard in the market claiming that the time of monoliths has come to an end and that it is not worth using older technologies. Microservices and serverless lambdas are considered to be the future of software development and are treated as advanced architectures.
The specialists at Stepwise look at these issues from a multidimensional and pragmatic perspective. We believe that these approaches will coexist in the market for a long time. Not only will this specific coexistence involve a simultaneous use of each technology independently, but also combining their elements in the same projects. The final effect will be complex applications benefiting from the greatest advantages of each of these technologies.
These days, businesses need to be resistant to multiple dangers and deliver customers a variety of values. A smart combination of appropriate architectures enables finding a solution to nearly every business issue.
The monolith allows for preparing a scheme of an application that is ready to present and evaluate in a short period of time. Testing and monitoring of a monolithic application facilitate identifying software bottlenecks and functionalities that are worth developing. Based on this data, we know which application elements we should focus on and develop as independent entities in the system. In this way, we can develop a digital product, and in a natural way move from monolithic architecture to microservice architecture.
Microservices are a natural stage in the evolution of a monolith. Without doubt, this method will not always be the best solution. Well-thought-out projects and precisely planned software, where the concept and all functionalities are known in advance, can be created in a microservice architecture from the very beginning.
The architectures discussed in this article are a solid foundation for most businesses worldwide. The vast majority of business applications in the world can be built in a monolithic architecture at the initial stages of development. As projects develop, teams engaged in software creation expand and it is known which functionalities should be developed – this is where the microservice architecture works perfectly.
Lambdas ideally complement both of the architectures. In this approach we work just with the code. We can paste a fragment of the code in the console of selected services and forget about the server.
Some developers have a very restrictive attitude toward the division of these three architectures. The best software houses have a more flexible attitude. There are some connections between each of the mentioned architectures. Moving from one to another requires passing between certain levels. These architectures can easily overlap with one another. In one project you can simultaneously use the advantages of each of them, or change your approaches depending on the current needs. In the future, monolithic architecture, microservices and lambdas will certainly coexist. For the benefit of business.
