From Monolithic to Serverless — The 3 W’s (Why, What and When)

Server Architecture plays a predominant role in every application regardless of the technology used. It is the foundation which dictates the behavioural pattern of the application and decides the experience the users get. Though each architecture has its own advantage, choosing the right one is always tricky. One needs to consider both the current and futuristic needs of the application, failing which complications may occur during modification of the application. Here we will see the most prominent prevailing architectures and the right scenarios to go for a particular architecture.

Monolithic

Monolithic Architecture is legacy and yet robust method of application development, where the entire business case is built as a single unit. This would be best suited for enterprise level applications where the entire environment is built in three parts: a database (consisting of many tables usually in a relational database management system), a client-side user interface (consisting of HTML pages and/or JavaScript running in a browser), and a server-side application. This server-side application will handle HTTP requests, execute some domain specific logic, retrieve and update data from the database, and populate the HTML views to be sent to the browser. It is a monolith — a single logical executable. Hence, modifications to the system will require a new build of the server side application and the new build must be deployed.

Benefits of Monolithic

1. Debugging and testing: Monolithic applications are easier to debug and test when compared to their microservices counterparts. In MSA (Micro Services Architecture), when we hop across processes, machines and networking boundaries, we tend to introduce many hundreds of new variables and have many opportunities for things to go wrong. Also, the looser the dependency between components, the harder it is to determine when compatibility or interface contracts are broken. We won’t know something has gone wrong until the run-time. But in Monolithic Architecture, since every associated component must be present in order for the code to be executed, there will be fewer variables and hence fewer errors.
2. Performance: Every time an application takes a lot of time to load (which is not so desirable), it is because in the background it is making multiple API calls to multiple services. Caching and request collapsing maybe effective but it only increases the complexity for the developer. This maybe suited for an application used by innumerable users but for an enterprise application, these complicated API calls are not needed. Monolithic architecture makes limited/zero calls to APIs as the components needed for the execution are present in the same unit.
3. Security and operations: Fortune 500 companies that we know sometimes struggle with the complexity in the application’s security that is used. The more the number of services that is used, the more complex it will be, to manage the components involved in every service for every call made. On the other hand, managing Monolithic architecture has its benefits being a single unit i.e. “Many as One”.
4. Planning and Design: Microservices need lot of planning before designing. We need an overall picture of how the services will interact, list the components out and decide on how loosely the components can be coupled. Thus, this consumes a lot of time and cost. There is also a possibility of over architecting. Whereas Monolithic Architecture requires minimal planning and design effort.

Microservices

Microservices is the hottest trend in the modern software development. A microservices architecture ensures that our application is made up of lots of smaller, independent components that are capable of running in their own memory spaces and every component scales independently from each other across separate machines.

Benefits of Microservices

1. Agility: The application is broken down to the basic level functionally and then the related services are abstracted from it. This allows the developers to update only the relevant portion to the application and also removes the painful process of integration (which is done in Monolithic applications). Microservices Architecture hence speeds up the development process, reducing the time considerably.
2. Efficiency: Leveraging a microservices based architecture can result in efficient use of code and underlying infrastructure. Up to 50% of cost savings is experienced by reducing the amount of infrastructure required to run a given application.
3. Resiliency: Because MSA disperses the functionality across multiple services, the application is not susceptible to single point of failure. Hence the applications with MSA perform better and have minimal downtime.

Miniservices

Miniservices are “less pure Microservices”. Miniservices are just like microservices with respect to agility, scalability and functionality binding around the services, without adhering to the event-driven design MSA would provide. If the Micro services that we create is not event based, then we are not creating a Micro Service at all.

In MSA, every service should have zero awareness of the other services around it. To achieve this a particular communication pattern is followed, publish-subscribe which is published in the message queue so that other services can retrieve them. This is thus loose coupling. However, practically developers tend to use REST APIs for communication. Since eventually REST is used, we know all the services around and the loose coupling is lost. Hence developers broke up the application into smallest functioning components that could still communicate but could not be fully independent if HTTP is used. This laid path to Mini services.

Miniservice is like a group of microservices that come together in a little pattern and share data.

“From Complexity to Agility - Plan right to grow straight”

Serverless

Serverless Architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”), the best known vendor host of which currently is AWS Lambda.

Serverless doesn’t actually mean running the code without servers. ‘Serverless computing” means the application owner need not own a server or a virtual machine for the code to run on.

Serverless code can be used in conjunction with other styles i.e., part Serverless code and part other server style code (Ex., Microservices). An application could also be completely serverless.

FaaS provides a platform that allows developers to execute code on event trigger. It is not required to build and maintain an infrastructure to execute the code in Serverless architecture. Instead, the third party will maintain the server side code.

Benefits of Serverless

1. Cheaper than the traditional cloud: FaaS allows you to pay a fraction of the price per request. Startups can build a nearly free MVP which cuts down the cost.
2. Scalable: In cases where infrastructure is difficult to provide, Serverless architecture allows this and provides volume of growth.
3. Ability to focus on user experience: Without having to maintain and user a server, the companies can focus on developing and improving customer-facing features.

So the next Big Question — When to use what?

Regardless of which architecture is chosen, the business impact matters. Organisations have a choice to build on any of these architectures and still arrive at the solution.

1. The principles of microservices architecture manages challenges by giving complex solution in leveraging the complexity effectively.

2. Miniservices are solid solutions where the complexity is high.

3. Microservices are less cost efficient than Miniservices because, we need to have multiple functions get loaded at the run time or all the services should be running all the time.

4. In a scenario where one functionality is in multiple repositories, microservices suit best.

5. On the other hand, if there are multiple functionalities in one repository, Miniservices suit best.

6. It need not be the trending Microservices or the emerging Miniservices that are solutions. In a game where there may be up to a hundred global concurrent players, with games running across many web services, scaling is the biggest challenge. In this scenario, prototyping with Monolith and then breaking down into Miniservices or Microservices helps to rapidly iterate.

7. So it is better to build a proof of concept in Monolith and then further break down into Mini or Micro services once we know about our MVP is better.

So it all boils down to the business, their Usecase and Business Strategy of any application.