The term microservices stands for a combination of cloud services that serve a particular business domain or process. Example of domains for an e-commerce application is payment, order management, user authentication, etc.
Each microservice employs different services, databases, third-party applications, and languages.
Serverless technology provides businesses with the computing power and infrastructure to host applications without the added overhead of managing servers and their configurations. The serverless environment is built with services from Cloud Services Providers (CSPs) that handle the standard functionalities. Thus, developers can write only code without worry about the configurations and maintenance of the back-end architecture. They can focus on translating the business logic into microservices, executed thanks to serverless functions(FaaS) that handle the different building blocks of the application. All CSPs base the execution and billing on a per-request model.
Let’s explore the elements above into more details:
• Cloud Services Providers (CSP): With serverless, the building blocks needed to run applications and workloads are managed by third-party providers in the cloud. The main providers in the industry today are Amazon (AWS Lambda), Google(Cloud Functions), Microsoft (Azure Functions), Oracle (Functions), IBM (Cloud Functions),and Alibaba (Function Compute).
• The term “serverless” does not mean applications are hosted on no servers. With serverless, workloads are managed in the cloud, developers can solely focus on code, and all infrastructure is housed and managed by the CSP. Developers no longer need to manage provisioning, patching, maintaining, and securing applications.
• Microservices: Serverless uses a microservices architecture model, where each service represents a business function, uses separate logic, and is part of the whole application. For example, business software could have different components to manage order details, payments, shipping information, and customer service. These components communicate with each other to function as an entire application.
• FaaS: Function-as-a-Service (FaaS) is the centerpiece of event-driven architecture and allows the execution of microservices in response to an event without managing servers, operating systems, and web server hosting processes. It is often used interchangeably with the term serverless but is not the only component in serverless technology. Serverless is a larger concept that includes other application services such as computing, cloud storage, messaging, API gateways, etc.
• Per-request execution: With serverless, code only runs when there is a request. This means that the system can scale up and down transparently when it requires additional computing resources. Companies only pay for resources that they use, not for idle capacity like for other architectures.
Microservice architecture is a particular style of programming that designs applications to be a collection of several microservices instead of one monolithic application with a tightly packed business logic. In a microservice architecture, the business logic is separated into individual units of code that can run independently of the other microservices.
Each microservice has its own set of data and executes only to answer the user's specific request. This way, the developer can run multiple functionalities so that they can scale without having to maintain one large resource-intensive application. Microservices allow for a high level of modularity and efficiency in execution and are often deployed to a serverless environment.
Microservices characteristics:
• Easy to maintain and test,
• Loosely coupled,
• Can be developed and deployed independently,
• Designed to serve a specific purpose or business logic.
According to O’Reilly’s survey about “Microservice Adoption in 2020”, microservice architecture is a topic of interest for organizations of all sizes. Most respondents (61%) have been using microservices for a year or more.
A microservice architecture offers the following advantages:
• Can be built independently and be owned and managed by smaller dev teams, facilitating the frequency of code releases and development of new features.
• Allows for scalable use of cloud services, as with microservices, you need not scale an entire application but just the microservice that is used the most.
• Improves fault isolation: in case of errors or crashes, other microservices will remain unaffected.
• Allows for flexibility in choosing the tech stack for developing each microservice. As each microservice will have its own database and business logic, you can choose to develop them in any programming language or tech stack you choose independent of other microservices.
On the business side, O’Reilly’s survey respondents also mention the fastest response to changing technology and business requirements and lower development costs.
As with any architecture, microservices have some challenges related to the changes in development practices associated with their properties. But they can be managed with the proper methodology and best practice adoption.
A few challenges to consider:
• Monitoring is essential: Because microservices work with individual components, it can be more challenging to perform root-cause analysis on errors. Efficient monitoring will help reduce time during code reviews and help developers find issues faster.
• Adoption of a DevOps culture: DevOps and microservices go hand-in-hand. Developers use automated services to deploy their code to microservice components, and manual promotions are no longer needed. They can even automate testing. Developers and operations teams need time to adopt the new culture and deployment changes.
• Testing: Testing can be automated, but it must be thorough. Because microservices are decoupled from infrastructure and work independently, testing can be more challenging for developers unfamiliar with the new architecture.
• Code design must be fault-tolerant: Decoupled services will work independently, but they also function as a single application. Failure in one component must not affect other sections of the application.
In a traditional architecture, the development team packages all the components into a monolithic application. It is hosted on servers that can either be on-premises or in the cloud. The provision, maintenance, and security of these physical or virtual servers are managed by IT admins.
The main advantage of a monolithic application is its simplicity:
• There is no need of managing domain definition and complex interdependencies between components. Defining the requirements for a new project is easier.
• As the application runs as a block, and the code is in one place, it’s easier to test and maintain its overall performance.
• In terms of organization, everyone works on the same tech stack, and feature prioritization can be managed globally.
The server capabilities must be sufficient to cover any surges in application usage and must be scalable according to the user demands. Data storage for the server operations can also be either maintained in an on-premises physical data center or in a cloud-based hosting solution.
But with a microservice architecture, the maintenance and management of servers are shifted from the company to the Cloud Service Provider. Here are some aspects in which the microservice architecture differs from traditional architecture:
• Each domain is managed as a collection of microservices, independent from one another. Each microservice represents one component of the application.
• The entire server application, along with the standard components required to run microservices, is hosted in the cloud and managed by the Cloud Service Provider.
• The dev team needs only to write the custom code for their business-specific logic and deploy it in the cloud in the form of microservices.
Containers are basically lightweight virtualization architecture. The configuration, the specific code, the runtime engine, and all dependencies are packaged into a smaller software unit.
Containers share the required system resources with the host server and allow deployment of microservices without having to tweak the overall application configuration and environmental settings.
Containers are a way of deploying more heavy-duty applications, long-running applications that require fine-grained control of computing resources and memory. They have the advantage of being vendor-agnostic and portable. But they require much more administration and server consumption than serverless.
Serverless is a simpler application development platform that allows organizations to go to market much quicker without worrying about its infrastructure procurement components.
Not all applications are suitable for serverless as not all applications are suitable for containers. A majority of enterprises leverage a hybrid model, with some serverless functions and some functions deployed in containers, and maturing towards serverless more and more.