This first chapter introduces the book’s content, which includes the modernization of apps using application programming interfaces (APIs), event-driven architecture, functions, and Service Fabric, and connecting them with a database.

Modernization is not just reserved for companies that have been operating stable systems for years and whose data volume has evolved. Organizations want to remain profitable and not be left behind by not modernizing technology and taking advantage of changes in the market due to world-changing factors, such as Covid-19.

Modernization is about accelerating innovation and reducing costs. Modernization is not just about the app but also the data.

In this chapter, we’re going to cover the following main topics:

• Understanding serverless architecture
• Understanding the role of APIs inside an application and their ecosystem
• Understanding event-driven architecture
• Exploring cloud databases

Serverless architecture is a software design pattern where applications are hosted by a third-party service, allowing developers to build and run services without having to manage the underlying infrastructure.

Applications are divided into separate functions that can be called and scaled individually.

Developers implement and deploy application-only code and can run applications, databases, and storage systems hosted in servers provisioned by cloud providers.

We will understand the role of APIs inside an application and the ecosystem. To start modernizing legacy applications without any modification, we can use APIs to interact with existing code. These APIs will run in the cloud, but if we need to add more features to the application to modernize it, we will encapsulate the data and the functions in services via an API. This encapsulation phase is a technique that consists of reusing legacy software components. The goal is to keep the code in its environment and connect it to the new presentations via encapsulation to access the different layers through an API. APIs permit you to define common protocols (rules) to expose data from an application with the possibility of decoupling the presentation layer.

Technically, the encapsulation works with wrapper technology, providing a new interface for a legacy component. This component will be easily accessible from the rest of the software components.

These minimal modifications reduce the risk of destabilizing the application. Even if encapsulation is a fast, effective, and less expensive solution, it will not solve the present problems related to the difficulties of maintenance or upgrading.

Because we are talking about the role of APIs in digital transformation and their life cycle, we need to define them.

API definition

APIs form a bridge between different applications to ensure communication and the exchange of information between them. They can even define the behavior of these applications.

APIs are considered connectors because they provide the ability for disparate applications to exchange information.

The information exchanged is generally data; for example, if we make a request in a mobile application, the data will be sent to a server that performs the reading and then sends back a response in a format readable in JSON.

Sometimes, microservices are compared with APIs. We often talk about the relationship between APIs and microservices, but there is also a difference between them. Microservices are a style of architecture that divides an application into a set of services; each service presents a very particular domain, for example, an authentication service or another service for the management of the products. On the other hand, an API is a framework (a structure that you can build software on) used by developers to provide interaction with a web application. Alternatively, microservices can use an API to provide communication between services. But how does an API work?

Applications that send requests are called clients, and applications that send responses are called servers. Using bees as an example, the hive is the client, the flower is the server, and the bee is the communication path (REST API requests).

The API life cycle

The API manager – usually the enterprise architect or API product manager – manages the API life cycle.

The API life cycle consists of the following three main phases:

• The creation phase: This consists of creating and documenting the API. There are some key aspects of API creation to consider; the API will use or reuse backend resources (service or business capability implementation). These resources are typically available as RESTful services, Simple Object Access Protocol (SOAP)-based web services, or even Advanced Message Queuing Protocol (AMQP)-compliant message brokers.
• The control phase: This consists of applying the security policies necessary to ensure that the exchanges are secure.
• The consumption phase: This consists of publishing the API so that we can consume and monetize it.

After understanding the API life cycle and the different phases, we will next look at the important role of an API in terms of communication between applications.

An APIs role

A set of rules ensures the communication of APIs by defining how applications or machines can communicate, so the API is an intermediate bridge between two applications wanting to communicate with each other.

API types

A web API is an API that can be accessed via the HTTP protocol. There are many API protocols/specifications, as follows:

• Open APIs
• Partner APIs
• Internal APIs
• Composite APIs
• Representational State Transfer (REST)
• SOAP
• Extensible Markup Language Remote Procedure Call (XML-RPC)
• JavaScript Object Notation Remote Procedure Call (JSON-RPC)

The most popular type of API is RESTful because it has several advantages in terms of flexibility when creating an API that meets the client’s needs and dependencies because the data is not bound to methods or resources. A RESTful API supports different data formats, such as application/json, application/xml, application/x-wbe+xml, multipart/form-data, and application/x-www-form-urlencoded.

RESTful APIs take advantage of existing protocols – for example, web APIs take advantage of the HTTP protocol.

So far, in this chapter, we have talked about encapsulation to access the different layers through an API as a technique used for legacy system modernization. We have presented the API life cycle and API roles, which encompasses several roles to ensure communication, and we have identified the API types, such as RESTful APIs, which are the most popular. In the next section, we will present the event-driven architecture used to improve agility in complex applications.

Event-driven architecture is a software architecture that uses events in order to be able to communicate between decoupled services. It is a pattern for designing applications that are loosely coupled and is used in modern applications built with microservices. When consumers are listening to an event, which could be a status change or an update, event producers are not able to know which event consumers are listening to and do not even know the consequences of its occurrence.

In an event-driven architecture, we have the following three key components:

• Event producers: These generate a stream of events
• Event routers: These manage event delivery between producers and consumers
• Event consumers: These listen to the events

The following diagram illustrates these components:

Figure 1.1 – Event-driven architecture

The source of an event is triggered by internal or external inputs. They can be generated by either a user (by clicking or using keyboard input, for example), an external source (such as a sensor output), or through a system (such as loading a program).

In an event-driven architecture, we can use event streaming or a publisher/subscriber model. But what is the difference between event streaming and a publisher/subscriber model?

• Publisher/subscriber model: This provides a framework that enables message exchanges between publishers and subscribers. This pattern involves the publisher and the subscriber and depends on a message broker that reroutes messages from the publisher to the subscriber.
• Event streaming: When a stream of events is published to a broker, the clients are able to subscribe to the stream and join at any time; they have access to them and can consume multiple preferred streams, and they are able to read from any part and advance their position. The events are always written in a log file.

Event-driven architectures are recommended to improve agility and move quickly. They are used in modern applications, mainly microservices, or in any application that includes several decoupled components. When adopting an event-driven architecture, you may need to rethink how you view your application design.

In this section, we have explored event-driven architecture and the different key components.

A cloud database is a database service created and accessed through a cloud platform.

A cloud database is a collection of information, structured or unstructured, that is hosted in a private, public, or hybrid cloud computing infrastructure platform. There is no structural or conceptual difference between a cloud or on-premises database, it’s just the location that’s different.

Cloud databases are divided into two broad categories: relational and non-relational.

As in the case of databases with traditional ancestors, we have the same definition for a relational database, which is written in Structured Query Language (SQL). It is composed of tables organized in rows and columns with relationships between them, called fields. This relationship is specified in a data schema.

Non-relational databases, also called NoSQL, use a different storage concept based on documents. They do not use a table model to store content as in the traditional approach; they use a single document instead.

A non-relational database is recommended for unstructured data – for example, for social media content, photos, or video storage. There are two models of cloud database environments: traditional (which we discussed earlier) and database as a service (DBaaS).

For the first case, we can host a virtual machine, install the cloud database management system (DBMS), and the database runs on this machine, so the management and monitoring of the database are managed by the organization. On the other hand, the DBaaS model is a paid subscription service in which the database runs on the physical infrastructure of the cloud service provider.

Azure offers a set of fully managed relational, NoSQL, and in-memory databases:

• Azure SQL Database: This is used for applications that scale with intelligent, managed SQL databases in the cloud
• Azure SQL Managed Instance: This is used to modernize your SQL Server applications with a managed, always up-to-date SQL instance in the cloud
• SQL Server on Azure Virtual Machines: This is used to migrate SQL workloads to Azure while maintaining full SQL Server compatibility and OS-level access
• Azure Database for PostgreSQL: This is used to build scalable, secure, fully managed enterprise-grade applications using open source PostgreSQL, scale PostgreSQL with single-node and high performance, or move your PostgreSQL and Oracle workloads to the cloud
• Azure Database for MySQL: This used to provide high availability and elastic scaling for your open source mobile and web apps with the managed community MySQL database service or move your MySQL workloads to the cloud
• Azure Database for MariaDB: This is used to build applications anywhere with guaranteed low latency and high availability at any scale, or move Cassandra, MongoDB, and other NoSQL workloads to the cloud
• Azure Cache for Redis: This is used to run fast and scalable applications with open source compatible in-memory data storage
• Azure Database Migration Service: This is used to accelerate your move to the cloud with a simple, self-paced migration process
• Azure Managed Instance for Apache Cassandra: This is used to modernize existing Cassandra data clusters and apps and enjoy flexibility and freedom with the Managed Instance service

If you are building a new application or are in the process of modernizing a legacy application, you need to understand these architectures: serverless architecture, APIs, and event-driven architecture. These architectural patterns are critically important to master.

This chapter was about serverless architecture, API definition, types, life cycles, communication between applications or machines, event-driven architecture, and cloud databases.

In the next chapter, you will learn how to deploy web APIs and the explore function of the API management service.

If you need more information about serverless architecture, you can check out this link: https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-serverless-computing/ and this e-book: https://learn.microsoft.com/en-us/dotnet/architecture/serverless/.

You can check out event-driven architecture documentation at these links: https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven and https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/serverless/event-processing.

1. What are the three key components of event-driven architecture?
2. What are the different Azure database services?