Building Modern Applications Using Serverless and Microservices Architecture

What is microservices architecture? What are its benefits?
In a microservices architecture, a single large application is broken into smaller elements where each element delivers a specific value. In monolithic applications, all functions are connected to a single large codebase which is harder to manage. For modern applications, the preferred application development architecture is a microservices architecture, in which the codebase is decoupled into smaller functional units that interact with each other through well-defined APIs.

How does microservice architecture impact an application’s performance and scalability?
The biggest benefit of a microservices architecture is agility. The decoupled services are programmed, tested, and even deployed independently. Microservices are safer because the blast radius has been reduced with decoupling. Other merits are the use of well-defined interfaces for communication among the decoupled services. The backend code paths are well defined as well. Microservices are also easier to test due to the small-sized code for each decoupled service.

In comparison, the demerit of monolithic architecture is that all developers are contributing to the same codebase. Hence, over time, the codebase increases in size and becomes harder to manage. Each team member creates their own changes. For these changes to be incorporated into the codebase, the approval requests for a large number of changes get queued. And so, the development is simply not fast enough in monoliths.

A well-architected monolith application can outperform microservices but only in the short term. Over time, the monolithic application becomes bulkier but fragile, harder to maintain and operate. However, irrespective of the period, the agility and safety merits of microservices architecture trump the performance benefits of monolithic architecture.

What is the difference between Monolithic, Service-Oriented Architecture (SOA), and Micro-services Architecture?
All functions whether it is the database or the API layer(s), are part of the same codebase in monolithic architecture and are maintained as one repository of code as well. Generally, they get packaged as a single large container or VM that gets deployed. Contrary to monolithic architecture philosophy is the microservices architecture which has been explained earlier.

Microservices architecture uses the principles of service-oriented architecture. The service-oriented architecture combines discrete business functions that have been separately deployed and maintained. Its function is to provide data and code integration services and to ensure communication between these business functions.

The difference between the two is the scope of operations and their methods of communication. Microservices architecture operates within the mobile application development services realm whereas service-oriented architecture is an enterprise-wide phenomenon. In microservices, each decoupled element uses APIs to communicate with each other. In contrast, each element in service-oriented architecture uses an enterprise service bus, (ESB) to communicate between discrete business functions.

What are the best practices for designing microservices?

When microservices are designed, there are multiple ways to divide the application into the smallest element possible. The division can be based on teams called Service Per Teams e.g. front-end and back-end APIs teams, etc. It can also be based on functional areas that vary on the business use cases or application capabilities.

Can breaking an application w.r.t number of transactions, serve as a guiding principle?

Dividing application development architecture in terms of transactions can serve as a good guiding principle because the frequency of transactions per second can affect testing, deploying, and monitoring. Since there is no rule for the division parameter, the number of transactions can be one parameter. To cover all the use cases, the development team can conceive an agile way to implement, test, and monitor the application. The aim here is to achieve the best safety and performance for your application and its deployment.

Is microservice architecture better than others in terms of cost?

It depends on the use case. Any architecture can be costly if used carelessly. For example, it is more costly if the monolith application is running in big instances or if load balancers are not properly configured. Similarly, microservices can be costly if multiple VMs or containers are in use but not needed. In general monolithic architecture tends to be slightly less expensive.

Would you say that with a monolithic architecture, CI/CD pipelines are easier to manage?

No. It is rather hard to manage CI/CD pipelines in a monolithic architecture. One small change in a large codebase will impact other parts of the application. Whereas in microservices, the well-defined interfaces ensure fast defect isolation and resolution.

CI/CD pipelines and monolithic architecture are like oil and water. Monoliths are harder to build, harder to deploy, and harder to test whereas Microservices are much easier in comparison.

How do I maintain the security of my application in microservices architecture?

In terms of security, microservices and monolithic architecture are not fundamentally different because in both cases you have to perform your own security reviews.  The responsibility of patching your hosting and maintaining availability is on you. However, in serverless architecture, these actions are the responsibility of CSPs.

Does that mean for security serverless architecture is better?

No. Serverless takes away that responsibility and hence a pain point. There is a fleet of VMs and servers that do not need management in serverless architecture, depending on the scale of your operations. However, serverless is not easy to manage when it comes to security unless the serverless functions are divided into the smallest possible functions.  Fine-grained IAM policies, then, manage each microservices that communicate with each other. This allows each team to own their own space and to autonomously work on that service.

What are the challenges you face with serverless architecture? Please go into details of runtime and resource isolation.

One of the challenges is the time budget. Serverless can only run for a certain period. It is both a blessing and a curse. A blessing because it ensures developers finish early or at least timely. And a curse because you must finish work on serverless architecture in the designated time. This poses even more strain in high-load situations.

Resource isolation is another challenge with serverless architecture. Serverless is no different when it comes to shared resources on the same infrastructure. Hence, the noisy neighbor effect will be a factor. The effect will be exasperated if a lot of serverless functions are running on the same infrastructure.

How would the security, latency, and privacy of the data be impacted for a complex, distributed application in microservices architecture?

There were times when it was believed that microservices take longer to deploy. However, computing has evolved to such an extent that monolith does not yield more performance benefits than microservices, in general.

 The only time monoliths yield better performance is when IPC communication is used on the same Unix machine. Monoliths are faster in that case than using APIs. However, GraphQL query across two microservices, running on two different machines, may not be so.

Nowadays network fabric, switching, and computing infrastructure has evolved enough to minimize the difference.

How does microservices architecture deal with asynchronous calls resulting in congestion and latency?

The issue of congestion and latency resulting from asynchronous calls does not change for monolithic architecture or microservices architecture. If you have a use case with high Transactions Per Second (TPS) then you design the architecture to handle high TPS. One important design consideration for monolith and microservices is to autoscale your system. Every Cloud Service Provider (CSP) allows you to autoscale. For example, for a food delivery service, the TPS will be low in the middle of the night vs during lunch hour. If you fail to autoscale, then the payment for both times will be the same. When in fact, you should pay less for times with fewer TPS.

As a startup founder, what should be my motivation for going serverless? How would this impact my cost?

Your motivation to use serverless architecture should be agility and time efficiency. Independent teams can move faster. There is higher availability and safety of applications in a serverless architecture. Serverless also allows you to reduce your blast radius, build test cases that are specific to each microservices, and avoid unpredictable code paths. More important is the benefit of cost because you pay for only what you use. It is reasonable to run VMs as long as they are needed. All these cumulatively make serverless infrastructure an excellent choice for application architecture. Therefore, you should use serverless until you can’t.

The cost of serverless architecture or the cost of the on-prem solution, which is easier to bear?

On-prem solutions also have serverless with VM support, nowadays. Whether you are on-prem or on the cloud, the cost will be according to the infrastructure consumption time. Serverless prevents you from hogging resources when not needed. Once the resource is released for use somewhere else, you get more from the same infrastructure.

What are the different types of APIs that microservices can use to communicate with each other?

There are many. However, there are three standard APIs. The most commonly practiced API is the Representational State Transfer (REST). REST uses a client/server approach where the front and back-end APIs operate separately. RESTful APIs usually exchange data or documents and can communicate with each other both directly and with the help of intermediaries such as load balancers and API gateways.

SOAP i.e. Simple Object Access Protocol is commonly used in the creation of Web API. Therefore SOAP supports a wide range of the internet protocols such as HTTP, SMTP, TCP, and more. SOAP works with XML (Extensible Markup Language). The extensible nature provides developers the ease and flexibility to add new features and functions.

And the third is the Remote Procedural Call (RPC) usually solicits executable processes that help the exchange of parameters and their results. However, RPC is the least commonly used API because of its higher security risks and limited data-type support.

What are the best practices to implement microservices APIs?

Instead of implementing APIs yourself, use standard APIs. Make sure the standard API, you have opted for, has developer community support to back it up. There are a lot of libraries available to implement APIs. In the public cloud, even technologies resemble AWS API gateway. Other clouds have similar tools as well. They are easy to set up and can provide a restful interface that performs CRUD operations on the backend infrastructure in no time.

Explain the way to implement service discovery in a microservices architecture.

Earlier, there might have been debates on the selection of many different service discovery architectures but currently, DNS is used by the majority. It is simple. Every service has a name. You register with a DNS and it guides the communication and service location. Service registration and service discovery are standardized on DNS and no longer require complex architectures.

What does the future hold for these application development architectures? How do you see them evolving?

For the application development architecture debate, winners have been called. The future of computing would be more and more serverless applications except for the workloads that cannot be serverless. For each use case, you need to choose which workload will be serverless. Therefore, it would be a mix of serverless and container or serverless container and database running as VMs.

To Watch the Complete Episode, Please Click on This YouTube Link:

https://www.youtube.com/watch?v=9Jcse3Vjw4I&t