You might have heard the buzzword serverless previously, perhaps through your colleagues or cloud advocate. You must have wondered what this means for your enterprise or for you as developer, architect, or DevOps associate. However, do not get confused by the word serverless; it does not refer to the process of running your code without servers.

For an enterprise, serverless actually means managing the enterprise's IT workload in cloud without having to make vast investments in setting up an infrastructure to run products and services. For new and existing organizations, a serverless platform means that an enterprise need only be billed for consumed resources.

For developers, serverless means writing efficient code that makes the most of the resources available. Cloud computing has evolved over time, and we need to appreciate this when making applications for the cloud. The following diagram describes the journey of cloud computing:

Throughout this journey, Microsoft has invested heavily in making its infrastructure more suited to customer requirements in a much more efficient manner. With Azure, Microsoft's own cloud service, there are numerous platforms and services that let you get started without having to consider the internal infrastructure and any starting costs. These platforms include Azure Functions, Logic Apps, Cosmos DB, Data Factory, API Management, and many more. In this book, we will concentrate on Microsoft's serverless integration stack and how you can take advantage of these serverless platforms in the real world.

In this section, we will discuss the advantages and disadvantages of having a serverless environment in your organization. As the name suggests, a serverless environment provides you with abstraction from operating systems, servers, and infrastructure. This comes with its own set of advantages and disadvantages. For example, if you are using Function as Service (FaaS) or an integration workflow, you only need to concern yourself with development implementation rather than with procurement of hardware and the building of infrastructure to run functions or integration workflows. This allows an organization to concentrate more on business requirements and innovation in the sector, rather than external factors such as infrastructure setup, firewalls, hardware procurement, and networking.

The following diagram is a representation of a serverless FaaS environment in the cloud, where auto scaling is catered for through multiple execution runtime environments:

As there are multiple layers to this discussion, let's discuss how you and your organization benefit from a serverless application architecture:

• Event-driven architecture: As we move closer to a serverless architecture, we also move closer to reactive asynchronous design patterns. For example, think of your application reacting to an event of your choice instead of polling for all events and then filtering for the required data. This has huge benefits for your organization in terms of the optimization of available resources and minimizing the overall application running cost in the cloud.
• Language of your choice: Organizations often struggle to find the right set of development resources that work for their business requirements. You might be a .NET developer or Node.js expert; these serverless platforms provide us with a platform in which language and framework are not constraints and you can write your own code with the language of your choice. This is one of the amazing benefits of utilizing serverless environments for your organization.
• Microbilling: A business cares about expenditure and innovation. When you think about a business owner's prospective costs, optimization is one of the biggest challenges in today's world. Most cloud vendors have worked through this challenge to provide better experiences to businesses by introducing a consumption-based pricing model. As more and more organizations are moving to the cloud, there has been a huge reduction in consumption across all cloud vendors. This helps cloud vendors to maximize their resource utilization.
• Scale on demand: Serverless environments are highly flexible in terms of scaling. As each serverless platform runs on a separate container, it is easy for cloud vendors to scale services as per demand. With auto scaling enabled, we need only worry about the best implementation of our applications and software, rather than about making applications to suit infrastructural requirements.
• Geolocation: Most serverless platforms can run across multiple regions. This is another key advantage when moving to the cloud. With geolocation features, businesses can meet customer requirements across different regions the world over without experiencing any latency or user experience problems.
• Better monitoring and priorities: With great monitoring capabilities in serverless environments, the DevOps team can now concentrate more on best practices for application development, deployment, and innovation, rather than spending endless nights supporting the infrastructure. This has benefited organizations in remaining competitive against market changes and innovation in their respective sectors.

We just covered some of the benefits of serverless environments – those were just a few of the many that there are. Now, let's discuss some disadvantages of serverless platforms:

• Vendor-specific resources: Most serverless platforms are managed and controlled by specified cloud vendors. This has potential drawbacks if you think of moving your resources to different hosting platforms or different cloud vendors. When using serverless platforms, you are locked into a specific implementation design that may not allow for your organization's flexibility requirements, and there may also be compatibility issues regarding business regions and changing pricing models.
• Governance: Most serverless platforms provide you with frameworks with easy startup, but there is a potential drawback to this. If you do not follow the right practices from the start, then you can put your business at risk. An example of this would be storing your database connection in your configuration file rather than using secure configuration storage or not implementing security for your outbound APIs. Though these are considered best practices, sometimes teams tend to move toward unsecured architecture patterns to meet business requirements.
• Monitoring across different cloud platforms: If your organization uses multiple cloud platforms, then each vendor will likely have a different set of monitoring implementations. This drawback means it can be harder for enterprises to maintain cross-cloud platform resources.
• Infrastructure insights: With serverless solution patterns, you can lose insights into the overall infrastructure setup. To gain maximum resource utilization, most cloud vendors share resources across multiple application implementations. This has the potential drawback of you not being aware of neighboring systems or encountering application noise, which might hinder the performance of your application.

So, we have given you a glimpse of the pros and cons of serverless environments. These are what you need to consider when you port your new services to serverless environments. In the following sections, we will concentrate on Microsoft's serverless offerings, discussing their concepts before moving on to their implementation logic.

In the current era of digital transformation and cloud-first strategy, organizations host their applications both in the cloud and in on-premises environments in a hybrid model. These organizations often struggle to find the right platform to connect these disparate systems.

To address this problem, Microsoft has heavily invested in building an integration framework to run in Azure; it is called Azure Integration Services. Azure Integration Services comprises a set of different services and platforms in Azure, such as Azure Logic Apps, Service Bus, Azure Event Grid, and API Management. Taking the capabilities and power of multiple serverless platforms, Azure Integration Services now serves a variety of customer sectors, ranging from healthcare and the automobile industry to governmental organizations and insurance companies.

Before we dive into a detailed explanation, let's understand what Azure Integration Services is and why you should bother with it. As we've already explained, Azure Integration Services is an umbrella for a number of Azure serverless integration platforms, and you will be surprised at how well these offerings work in harmony; for instance, by how well Azure Functions integrates with Azure Logic Apps to improve an organization's workflow. In the coming chapters, we'll get into more detail about all this, but for now, we'll just concentrate on familiarizing ourselves with the basics of these individual offerings, including what they are and a bit about how they work together to form a cloud-first integration solution.

Granular integration design and microservice patterns have changed the face of modern integration. Now, modern integration is not about learning a specific platform or mastering a product, but is more about getting the best out of connecting platforms. For example, if you want to automate your business workflow, then you can use Azure Logic Apps to build workflows in the cloud by utilizing a reactive programming model along with Azure Event Grid capabilities. Another example might be securing your external-facing endpoint. In that case, API Management is for you. If this confuses you, do not worry; we will learn all of these techniques and best practices throughout this book.

The following diagram describes what you are going to master in this book. We also urge you to go through the Microsoft Azure Integration Services whitepaper at https://azure.microsoft.com/en-au/resources/azure-integration-services/en-us/:

Since we have now looked at an overview of Azure Integration Services, let's discuss the individual offerings separately. We will start with Azure Logic Apps and then move on to other services such as API Management, Service Bus, Azure Functions, and Azure Event Grid.

If you are already familiar with integration frameworks in the cloud, then we urge you to read these about services' individual capabilities in this chapter. This will help you to get a broader overview of the different platforms and services available within the Azure Integration Services umbrella for connecting enterprise-wide applications with better design patterns.

Azure Logic Apps is part of the Azure Integration Services family and is an integration workflow engine in the cloud. With Azure Logic Apps, you can get started in no time and automate your workflows as required. With Azure Logic Apps, you can build highly scalable workflows in the cloud by taking advantage of more than 200 connectors (more than 200 were available at the time of writing):

Logic Apps works natively in a serverless fashion. What this means is that, like other serverless platforms, Logic Apps is also highly extensible in terms of micro-billing, scaling on demand, no infrastructure cost, a high level of monitoring, and the ability to bring your own APIs into Logic Apps and use it as a standard connector for building your integration solution.

Organizations are also reaping the benefits of flexible pricing models for Logic Apps. With Logic Apps, you are only charged for your usage (consumption-based pricing model); alternatively, you can opt for the Integration Service Environment (ISE) and pay a fixed price for your enterprise integration environment. ISE is a great step toward running an enterprise integration environment within a client's own virtual network, while still enjoying all the benefits of the cloud. We will learn more about ISE capabilities in later chapters.

Azure Service Bus is a multi-tenant, cloud-based service that sends and receives information between application and services. It is the oldest and most widely used member of Azure Integration Services.

As Azure Service Bus promotes asynchronous programming and works in a publish-subscribe model, various enterprises use its capability for message routing to provide decoupling for their existing solution. Azure Service Bus has grown over the years, experiencing success stories and supporting multiple languages for developers. With Azure Service Bus, you can either use queues for First-In-First-Out (FIFO) messaging or use topics to work with a publish-subscribe model.

Some of the languages that are supported for sending and receiving messages from a Service Bus queue are listed here:

• .NET
• Java
• Node.js
• Python
• Ruby
• The Azure portal
• The Azure CLI
• Azure PowerShell

The following list notes the languages supported for communication with Service Bus topics/subscriptions:

• .NET
• Java
• Node.js
• PHP
• Python
• Ruby
• The Azure portal
• The Azure CLI
• Azure PowerShell

Azure API Management is a Platform-as-a-Service (PaaS) framework for publishing an organization's internal and external APIs. With Azure API Management, you can secure your internal or external APIs, or compose your own API that talks to your backend system to cater to the needs of client applications.

Like other serverless platforms, API Management also comes with a variety of pricing models. For example, you can run an instance of API Management with a consumption plan, or you can pay a fixed price to utilize services in both the standard and premium plans. You can integrate API Management as part of your ISE:

People are often confused by the role of API Management. API Management is not only the façade layer preceding your APIs, but also a security door to your enterprise data. A better solution design should also cater to the security aspect of talking to internal or external services.

We have seen stories where organizations continue creating a plethora of APIs to connect their internal or external business partners, without paying much attention to security, content-type handling, caching, and so on. Often, these service behaviors are managed on an individual basis, which is not suited to a highly scalable infrastructure.

In Chapter 4, Azure API Management, we will discuss these aspects in more detail, along with industry best practices, so that you can get the most out of your investment and make your organization more agile and secure.

Azure Functions embraces a code-first approach to developing enterprise-grade solutions in Azure. Like other serverless platforms, Azure Functions is a powerful framework available in Microsoft Azure, where you can run your code on demand and pay only for your resource consumption.

The Azure Functions runtime supports multiple languages. When developing custom code for integration, developers can use the language of their choice, such as .NET, Node.js, Java, PowerShell, and more. When it comes to hosting, you can host your Azure Functions in any environment, such as Kubernetes, Windows, or a Linux environment. With various available application bindings, Azure Functions also follow a reactive programming model and can be used in a plethora of use cases. On the development front, you can either use the Azure portal to develop your Azure Function, or you can embrace development environments such as Microsoft Visual Studio or Visual Studio Code:

You can combine the workflow capabilities of Logic Apps and the code-first execution of Azure Functions to develop enterprise-grade integration solutions without worrying about the infrastructure implementation. Alternatively, you can develop your lightweight API though Azure Functions and leverage the capabilities of API Management to expose your API to the outside world.

When you have a huge workload running on an Azure Functions runtime, you can concern yourself with latency rather than changing your design patterns. There are also various pricing models for Azure Functions, such as fixed-price application plans or the premium runtime environment. All of these considerations are essential architecture decisions, and this book will help you to get the most out of Azure Functions through a chapter dedicated entirely to it.

We also suggest that as you go through this book, you keep yourself informed by reading the Azure Functions documentation: https://docs.microsoft.com/en-au/azure/azure-functions/.

The Azure Functions runtime is a great platform for processing data, offering capabilities to integrate systems through input and output bindings, while also suiting big data ingestion use cases such as the Internet of Things (IoT) and Azure Data Factory.

Azure Event Grid is a fully managed, intelligent event-routing service. With Azure Event Grid, enterprise applications can leverage an event-driven programming model to build reactive interfaces that can be used to connect external or internal applications. Using Azure Event Grid as a middleware messaging layer for application and interface integration helps organizations to optimize the performance of their software resources with a notification push design pattern, rather than a data pull operation model. Azure Event Grid works with a publish-subscribe mechanism, where you can have one or more event publishers and with each event, there can be one or more subscribers consuming the events.

In the following example, Logic Apps acts as a subscriber to the event published to Azure Event Grid. Events are routed to a Logic Apps endpoint in real time, and once an event is posted to the Logic App endpoint, a Logic Apps workflow sends an auto-triggered email using a Logic Apps-managed API connector for Office 365:

Azure Event Grid is the perfect match for Logic Apps and Azure Functions, and you can leverage events emitted from your environment or external resources to react in real time, instead of consuming resources through a polling-based mechanism. Various blogs and articles have been written on how to use the capabilities of Azure Event Grid, along with other connecting Azure resources such as Data Factory, blob storage, Service Bus, and external services.

This book has dedicated a chapter to the use of Azure Event Grid within enterprise applications, and how you can connect Event Grid services to an application of your choice and reap the benefits of the event-based messaging pattern.

We've now covered the basics of all the services that constitute Azure Integration Services. In the coming chapters, we will discuss each of these services separately, looking at their various architecture design patterns along with the code that can be implemented within your enterprise integration framework.

In this chapter, we looked at an overview of Azure Integration Services and what it means for an organization's digital transformation roadmap. We also covered an introduction to serverless platforms and their advantages and disadvantages, and we briefly described some individual product offerings, such as Logic Apps, API Management, Service Bus, Event Grid, and Azure Functions.

In next chapter, we will discuss Azure Functions in more detail, learning about some of the advanced capabilities of Azure Functions for building robust solutions and secure frameworks in the cloud.