Cloud Native Applications with Ballerina: A guide for programmers interested in developing cloud native applications using Ballerina Swan Lake

BIRMINGHAM—MUMBAI

Cloud Native Applications with Ballerina

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Richa Tripathi

Publishing Product Manager: Sathyanarayanan Ellapulli

Senior Editor: Rohit Singh

Content Development Editor: Vaishali Ramkumar

Technical Editor: Karan Solanki

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Shyam Sundar Korumilli

First published: September 2021

Production reference: 1210921

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80020-063-0

www.packt.com

To my mother and father

– Dhanushka Madushan

Contributors

About the author

Dhanushka Madushan is a senior software engineer at WSO2 and has a bachelor of engineering qualification from the Department of Computer Science and Engineering, University of Moratuwa. He has 5+ years' experience in developing software solutions for cloud-based platforms in different business domains. He has worked on the WSO2 integration platform for 3+ years and is responsible for building and maintaining integration products. He often writes blogs about the latest cutting-edge, cloud native-related technologies using his experience of working on many open source projects, including Micro-integrator, WSO2 ESB, and Apache Synapse, as well as development of the Choreo iPaaS platform and the Zeptolytic SaaS data analytics platform. Dhanushka's extensive exposure to cloud native-related technologies, including Docker, Kubernetes, Jenkins, AWS, and multiple observability tools, is a key area of expertise.

First and foremost, my thanks go to my loving parents who have supported me throughout the long journey of writing this book. Next, my thanks extend to Sameera Jayasoma and all Ballerina team members for supporting me whenever I had questions. I especially need to thank Lakmal Warusawithana and Anjana Fernando for the support given in the initial drafting and code sample creation process. Also, I would like to thank the technical reviewers, Nadeeshaan Gunasinghe, Joy Rathnayake, Shiroshica Kulatilake, and Shenavi de Mel, for the amazing work they have done. I would also extend my gratitude to the Packt team who supported and guided me throughout the process of publishing this book. Finally, I would like to thank Dr. Sanjeewa Weerawarna for founding and this awesome programming language.

About the reviewers

Nadeeshaan Gunasinghe is a technical lead at WSO2 with over 6 years' experience in enterprise integration, programming languages, and developer tooling. Nadeeshaan leads the Ballerina Language Server team and is also a key contributor to Ballerina, which is an open source programming language and platform for the cloud era, as well as being an active contributor to the WSO2 Enterprise Service Bus. He is also passionate about sports, football and cricket in particular. 

Joy Rathnayake is a solutions architect with over 16 years' industry experience and is part of the solution architecture team at WSO2, based in Colombo, Sri Lanka. He is primarily responsible for understanding customer requirements, identifying the products/technologies required, and defining the overall solution design/architecture. 

Joy has been recognized as both a Microsoft Most Valuable Professional (MVP) and Microsoft Certified Trainer (MCT). He was the first to hold both MVP and MCT recognitions in Sri Lanka. He has contributed to developing content for Microsoft Certifications and has worked as a Subject Matter Expert (SME) for many Microsoft exam development projects. He has contributed a lot to the community by presenting at various events, including Tech-Ed Europe, Tech-Ed Southeast Asia, Tech-Ed Sri Lanka, Tech-Ed India, Tech-Ed Malaysia, Southeast Asia SharePoint Conference, and SharePoint Saturday. He enjoys traveling, speaking at public events/conferences, and reading. 

Connect with him on LinkedIn at https://www.linkedin.com/in/joyrathnayake/.

Shiroshica Kulatilake is a solutions architect at WSO2 where she works with customers around the world to provide middleware solutions on the WSO2 stack for digital transformation projects. In her work, she is involved with real-world problems that organizations face in a rapidly changing digital world and gets the opportunity to help these organizations achieve what they require in their business from a technological standpoint. Her expertise lies in API Management, API Security, Integration, and EIPaaS. She started her career as a software engineer and is still passionate about the nitty-gritty aspects of building things, with her current focus being microservice architectures.

Shenavi de Mel is an experienced software solutions engineer with 7+ years' experience working in the computer software industry. She is passionate about building great customer relationships and enhancing her knowledge of the field. She has extensive hands-on experience in many development languages and technologies, including Java, Jaggery, Ballerina, JavaScript/jQuery, SQL, PHP, HTML, Docker, and Kubernetes. Currently, she is working as a lead solutions engineer as part of the solutions engineering team, assisting customers in implementing their solutions using the WSO2 platform. She is also very familiar with API management, integration, and identity protocols, having spent the majority of her career working at WSO2, one of the leading companies as regards middleware and open source technology.

Table of Contents

Preface

Section 1: The Basics

Chapter 1: Introduction to Cloud Native

Evolution from the monolithic to the microservice architecture

The N-tier architecture in monolithic applications

Monolithic application architecture

The ESB simplifies SOA

The emergence of microservices

Understanding what cloud native architecture is

Cloud computing

Serverless architecture

Definition of cloud native

Why should you select a cloud native architecture?

Challenges of cloud native architecture

Security and privacy

The complexity of the system

Cloud lock-in

Deploying cloud native applications

Design is complex and hard to debug

Testing cloud native applications

Placing Ballerina on cloud native architecture

Building cloud native applications

The twelve-factor app

Code base

Dependencies

Config

Backing services

Dev/prod parity

Admin processes

API-first design

The 4+1 view model

Building an order management system

Breaking down services

Impact on organizations when moving to cloud native

Challenges of moving to a cloud native architecture

Outdated technologies

Building cloud native delivery pipelines

Interservice communication and data persistence

Conway's law

Netflix's story of moving to cloud native architecture

Summary

Questions

Further reading

Answers

Chapter 2: Getting Started with Ballerina

Technical requirements

Introduction to the Ballerina language

A glimpse of Ballerina

The Ballerina compiler

The Ballerina threading model

Setting up a Ballerina environment

Downloading and installing Ballerina

Setting up VS Code

Using VS Code to develop a Ballerina application

Writing a simple hello world program

Building a Ballerina project

Understanding the Ballerina type system

Simple types

Structured types

Sequence types

Behavioral types

Other types

Working with types

Using types to build applications with Ballerina

Controlling program flow

Ballerina functions

Treating functions as variables

The Ballerina main function

Working with Ballerina classes

Ballerina objects

Error handling

Using custom errors

Summary

Questions

Answers

Section 2: Building Microservices with Ballerina

Chapter 3: Building Cloud Native Applications with Ballerina

Technical requirements

Ballerina cloud native syntaxes and features

The role of Ballerina in cloud native architecture

Building a Ballerina HTTP service

Passing data to HTTP resources

Using query parameters on an HTTP server

Passing structured data to HTTP services

Invoking remote HTTP services

Ballerina JSON support

Working with XML format in the Ballerina language

Ballerina remote methods

Containerizing applications with Ballerina

Introduction to containers

Containers versus VMs

Containerizing applications with Docker

Building a Docker image with Ballerina

Using Ballerina's development Docker image

Container orchestration with Kubernetes

Introduction to Kubernetes

Generating Kubernetes artifacts with Ballerina

Utilizing Kubernetes resources

Using config maps in the Kubernetes cluster

Configuring a Kubernetes health check for Ballerina services

Using Kustomize to modify Ballerina Kubernetes configurations

Summary

Questions

Further reading

Answers

Chapter 4: Inter-Process Communication and Messaging

Technical requirements

Communication between services in a microservice architecture

Communication over services in the Kubernetes cluster

Using environment variables for service discovery

Using the Kubernetes DNS resolver for service discovery

Using a service mesh to simplify inter-service communication

Service discovery in a service mesh by using Consul

Using resiliency patterns in Ballerina

Ballerina client-side load balancing

Synchronous communication

Handling HTML form data

Building a Ballerina backend with GraphQL

Using the OpenAPI Specification with Ballerina

Building a chat application with WebSocket

Building Ballerina services with the gRPC protocol

Asynchronous communication

Asynchronous communication over microservices

Building the publisher and subscriber pattern with Apache Kafka

Connecting Ballerina with Kafka

Connecting Ballerina with RabbitMQ

Summary

Questions

Further reading

Answers

Chapter 5: Accessing Data in Microservice Architecture

Technical requirements

Accessing data with Ballerina

Connecting the Ballerina application with MySQL

Querying from MySQL

Using parameterized queries

Using batch execution

MySQL data types and Ballerina data types

Connecting databases with JDBC drivers

Connecting Ballerina application with DaaS platforms

Managing transactions in Ballerina

Building an order management system

Initializing the MySQL database for the order management system

Building an order management system with Ballerina

Understanding ACID properties

Ballerina transaction management

The database-per-service design pattern

The role of Domain-Driven Design in cloud native architecture

Creating aggregates with Ballerina

Distributed transactions with saga

Building a saga orchestrator with Ballerina

Using event sourcing and CQRS in a distributed system

Using events to communicate among services

Developing with event sourcing

Creating aggregates with event sourcing

Creating snapshots

Querying in microservice architecture

Summary

Questions

Further reading

Answers

Section 3: Moving on with Cloud Native

Chapter 6: Moving on to Serverless Architecture

Technical requirements

Introducing serverless architecture

Developing Ballerina applications with Azure Functions

Introducing Azure cloud features

Building serverless applications with the Azure cloud

Building Ballerina applications with Azure Queue

Developing Ballerina applications with AWS Lambda functions

Understanding AWS Cloud services

Configuring the AWS CLI and AWS Console

Creating your first Ballerina AWS Lambda function

Adding triggers to invoke a Lambda function

Using AWS Step Functions with an AWS Lambda function

Building the Lambda function with Ballerina

Creating Step functions in the AWS Console

Creating an API gateway to invoke Step functions

Summary

Questions

Further reading

Answers

Chapter 7: Securing the Ballerina Cloud Platform

Technical requirements

Managing certificates in Ballerina applications

Securing the Ballerina service with HTTPS

Calling an HTTPS endpoint with Ballerina

Securing Ballerina interservice communication with mutual SSL

Authenticating and authorizing with LDAP user stores

Authenticating and authorizing users with the LDAP server

Setting up Apache Directory Studio

Authenticating and authorizing Ballerina services with LDAP

Token-based authorization with Ballerina

Securing Ballerina services with a JSON Web Token

Generating and validating a JWT with Ballerina

Generating JWT with WSO2 Identity Server

Authorizing Ballerina services with JWT

Authorizing Ballerina services with WSO2 IS-generated JWT claims

Building a Ballerina service with JWT authorization

OAuth2 authentication and authorization with WSO2 IS

Summary

Questions

Further reading

Answers

Chapter 8: Monitoring Cloud Native Applications

Technical requirements

Introduction to observability and monitoring

Observability versus monitoring

Ballerina logging

Printing logs with Ballerina

Using Logstash to collect logs

Using Logstash with Filebeat in container environments

Using Elasticsearch to collect logs

Using Kibana to analyze Ballerina logs

Tracing with Ballerina

Understanding the OpenTelemetry standard

Using Jaeger as a tracing platform

Monitoring the Ballerina application with Jaeger

Creating custom spans with the Ballerina language

Collecting and visualizing metrics with Ballerina

Exposing metrics from Ballerina

Collecting metrics with Prometheus

Visualizing metrics with Grafana

Creating custom metrics with Ballerina

Summary

Questions

Answers

Further reading

Chapter 9: Integrating Ballerina Cloud Native Applications

Technical requirements

Fronting Ballerina services with an API gateway

Building an API gateway with Ballerina

Setting up and using WSO2 API Microgateway

Using interceptors in Microgateway with Ballerina

Building Ballerina integration flows with Choreo

Introduction to Choreo low-code development

Building HTTP services with Choreo

Integrating services with Choreo

Summary

Questions

Answers

Chapter 10: Building a CI/CD Pipeline for Ballerina Applications

Technical requirements

Testing Ballerina applications

Testing cloud native applications

Writing a simple test in the Ballerina language

Writing test functions with the Ballerina test framework

Ballerina test reports

Understanding Ballerina's testing life cycle

Grouping Ballerina tests

Mocking functions with Ballerina

Automating a cloud native application's delivery process

CI/CD pipeline in a cloud native application

Using GitHub Actions with Ballerina

Setting up GitHub Actions

Building and deploying applications with Ballerina Central

Introduction to Ballerina Central

Building and publishing packages in Ballerina Central

Publishing packages to Ballerina Central with GitHub Actions

Using Ballerina Central packages

Summary

Questions

Further reading

Answers

Why subscribe?

Other Books You May Enjoy

Preface

Ballerina is the latest general-purpose programming language that is specially written to build cloud native applications. Ballerina is a relatively new programming language initially released in 2019. Unlike other general-purpose programming languages, Ballerina provides built-in syntax to define services, native support for JSON and XML data types, and many more cloud native syntax styles. Kubernetes and Docker deployment support and remote functions are special built-in features provided by the Ballerina language.

This book has been written to help you to understand cloud native architectural design patterns and how to use the Ballerina language to implement them. We will discuss the availability, maintainability, deployability, resiliency, and security aspects of the Ballerina language with practical implementations.

We will discuss a sample order management system throughout the book to implement different cloud native architectural patterns. We will discuss architectural concepts that are essential in building cloud native systems. The examples given in each chapter start from simple applications to more advanced applications. We will use multiple free open source tools and libraries throughout the book to build more advanced cloud native systems.

In this book, we will focus on multiple different platforms you can use to deploy a Ballerina application. You can deploy on a stand-alone computer, cloud platform, Kubernetes, serverless platform, or Choreo Integration Platform as a Service (iPaaS) platform. You can select the best-fit platform for your system.

By the end of this book, you should be able to understand the basic concepts of cloud native and how it can be practically implemented with the Ballerina program in different deployment platforms.

Who this book is for

This book is intended for developers and software engineers who want to learn how to use the Ballerina language to develop cloud native applications. The samples given in this book cover a wide range of requirements for building cloud native applications. You should have a basic understanding of programming languages and programming to follow this book. Since we are discussing basic to advanced concepts of both cloud native architecture and the Ballerina language, both beginner and intermediate developers can easily follow the content.

What this book covers

Chapter 1, Introduction to Cloud Native, helps you to understand what cloud native is and important facts that you should keep in mind when you are building cloud native applications.

Chapter 2, Getting Started with Ballerina, explores Ballerina language syntaxes and setting up Ballerina on your local computer.

Chapter 3, Building Cloud Native Applications with Ballerina, helps you to understand the cloud native features provided by the Ballerina language and deploying a simple Ballerina service on a Kubernetes cluster.

Chapter 4, Inter-Process Communication and Messaging, teaches you about different types of communication protocols that can be used in a Ballerina-based cloud native application.

Chapter 5, Accessing Data in Microservice Architecture, covers using the database-per-service design pattern to build complex real-world applications with other microservice architecture design patterns.

Chapter 6, Moving on to Serverless Architecture, covers building a Ballerina application with the AWS and Azure serverless platforms.

Chapter 7, Securing the Ballerina Cloud Platform, helps you to understand security concepts and securing Ballerina applications with Ballerina security features.

Chapter 8, Monitoring Cloud Native Applications, covers monitoring Ballerina applications with logs, metrics, and traces.

Chapter 9, Integrating Ballerina Cloud Native Applications, covers exposing Ballerina services with a gateway and building integration with the Choreo platform.

Chapter 10, Building a CI/CD Pipeline for Ballerina Applications, teaches you how to build, test, and deploy a Ballerina program automatically with CI/CD pipeline tools.

To get the most out of this book

You don't need to have full knowledge of the Ballerina programming language to follow the samples given here. But you should have a basic understanding of at least one general-purpose programming language, such as Java, C, or Go, since Ballerina syntax is very similar to those.

The samples given in this book are tested on macOS. These samples should also work with Linux and Windows operating systems as well. The tools and libraries used in this book are free and open source. You can try out all of these samples free of charge. But the samples given in iPaaS and Software as a Service (SaaS) platforms such as AWS, Azure, Choreo, and Snowflake may charge you based on usage of the resources.

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book's GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

You can get the latest information on Ballerina and cloud native development by following the author on Twitter (https://twitter.com/DhanushkaDEV) or adding them as a connection on LinkedIn (https://www.linkedin.com/in/dhanushkamadushan/).

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Cloud Native-Applications-with-Ballerina/. If there's an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Code in Action

The Code in Action videos for this book can be viewed at https://bit.ly/3l1Exb9.

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here:

https://static.packt-cdn.com/downloads/9781800200630_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: The sayHello resource will simply send a Hello, World! response back to the caller.

A block of code is set as follows:

import ballerina/http;

service /hello on new http:Listener(9090) {

    resource function get sayHello(http:Caller caller,      http:Request req) returns error? {

        check caller->respond(Hello, World!);

    }

}

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

[dependencies]

dhanushka/invoice_util = 0.1.0

Any command-line input or output is written as follows:

kubectl apply –f target/kubernetes/code_to_cloud

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: Then, you can log in to the Ballerina Central dashboard and see your package listed under the My Packages section.

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Cloud Native Applications with Ballerina, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Section 1: The Basics

This first section focuses on the basics of cloud native technology concepts and the basic building blocks of the Ballerina language. This section is necessary to understand the more advanced concepts that we are going to discuss in later sections.

First, we will discuss what cloud native is, the history of cloud-based software architecture, the definition of cloud native, and transforming an organization to using cloud native technologies. Here, we will focus on the theoretical aspects of building a cloud native system.

Next, we will discuss the architecture of the Ballerina language, setting up a development environment, fundamental Ballerina syntaxes, the Ballerina type system, error handling, and controlling the program flow. Here, we will learn about the practical aspects of using the Ballerina language and fundamental concepts that are needed to build complex cloud native applications.

This section comprises the following chapters:

Chapter 1, Introduction to Cloud Native

Chapter 2, Getting Started with Ballerina

Chapter 1: Introduction to Cloud Native

In this chapter, we will go through how developers came up with cloud native due to the problems that are attached to monolithic architecture. Here, we will discuss the old paradigms of programming, such as three-tier architecture, and what the weaknesses are. You will learn about the journey of shifting from an on-premises computation infrastructure model to a cloud-based computing architecture. Then we will discuss the microservice architecture and serverless architecture as cloud-based solutions.

Different organizations have different definitions of cloud native architecture. It is difficult to give a cloud native application a clear definition, but we will discuss the properties that cloud native applications should have in this chapter. You will see how the twelve-factor app plays a key role in building cloud native applications. When you are building a cloud native application, keep those twelve factors in mind.

Organizations such as Netflix and Uber are transforming the way applications are designed by replacing monolithic architecture with the microservice architecture. Later in this chapter, we will see how organizations are successful in their business by introducing cloud native concepts. It is not a simple task to switch to a cloud native architecture. We will address moving from a monolithic architecture to a cloud native architecture later in the chapter.

We will cover the following topics in this chapter:

Evolution from the monolithic to the microservice architecture

Understanding what the cloud native architecture is

Building cloud native applications

The impact on organizations when moving to cloud native

By the end of this chapter, you will have learned about the evolution of cloud native applications, what cloud native applications are, and the properties that cloud native applications should have.

Evolution from the monolithic to the microservice architecture

The monolithic architecture dictated software development methodologies until cloud native conquered the realm of developers as a much more scalable design pattern. Monolithic applications are designed to be developed as a single unit. The construction of monolithic applications is simple and straightforward. There are problems related to monolithic applications though, such as scalability, availability, and maintenance.

To address these problems, engineers came up with the microservice architecture, which can be scalable, resilient, and maintainable. The microservice architecture allows organizations to develop increasingly flexible. The microservice architecture is the next step up from the Service-Oriented Architecture (SOA). Both these architectures use services for business use cases. In the next sections, we will follow the journey from the monolithic architecture to SOA to the microservice architecture. To start this journey, we will begin with the simplest form of software architecture, which is the N-tier architecture. In the next section, we will discuss what the N-tier architecture is and the different levels of the N-tier architecture.

The N-tier architecture in monolithic applications

The N-tier architecture allows developers to build applications on several levels. The simplest type of N-tier architecture is the one-tier architecture. In this type of architecture, all programming logic, interfaces, and databases reside in a single computer. As soon as developers understood the value of decoupling databases from an application, they invented the two-tier architecture, where databases were stored on a separate server. This allowed developers to build applications that allow multiple clients to use a single database and provide distributed services over a network.

Developers introduced the application layer to the two-tier architecture and formed the three-tier architecture. The three-tier architecture includes three layers, known as data, application, and presentation, as shown in the following diagram:

Figure 1.1 – Three-tier architecture

The topmost layer of the three-tier architecture is known as the presentation layer, which users directly interact with. This can be designed as a desktop application, a mobile application, or a web application. With the recent advancement of technology, desktop applications have been replaced with cloud applications. Computational power has moved from consumer devices onto the cloud platform with the recent growth of mobile and web technologies.

The three-tier architecture's middle layer is known as the application layer, in which all business logic falls. To implement this layer, general-purpose programming languages, along with supporting tools, are used. There are several programming languages with which you can implement business logic, such as Node.js, Java, and Python, along with several different libraries. These programming languages might be general-purpose programming languages such as Node.js and Java or domain-specific languages such as HTML, Apache Groovy, and Apache Synapse. Developers can use built-in tools such as API gateways, load balancers, and messaging brokers to develop an application, in addition to general-purpose programming languages.

The bottom layer is the data layer, which stores data that needs to be accessed by the application layer. This layer consists of databases, files, and third-party data storage services to read and write data. Databases usually consist of relational databases, which are used to store different entities in applications. There are multiple databases, such as MySQL, Oracle, MSSQL, and many more, used to build different applications. Other than using those databases, developers can select file-based and third-party storage services as well.

Developers need to be concerned about security, observability, delivery processes, deployability, and maintainability across all these layers over the entire life cycle of application development. With the three-tier architecture, it is easy and efficient to construct simple applications. Separating the application layer allows the three-tier architecture to be language-independent and scalable. Developers can distribute traffic between multiple application layer instances to allow horizontal scaling of the application. A load balancer sitting in front of the application layer spreads the load between the application instance replicas. Let's discuss monolithic application architecture in more detail and see how we can improve it in the next section.

Monolithic application architecture

The term monolithic comes from the Greek terms monos and lithos, together meaning a large stone block. The meaning in the context of IT for monolithic software architecture characterizes the uniformity, rigidity, and massiveness of the software architecture.

A monolithic code base framework is often written using a single programming language, and all business logic is contained in a single repository.

Typical monolithic applications consist of a single shared database, which can be accessed by different components. The various modules are used to solve each piece of business logic. But all business logic is wrapped up in a single API and is exposed to the frontend. The user interface (UI) of an application is used to access and preview backend data to the user. Here's a visual representation of the flow:

Figure 1.2 – A monolithic application

The scaling of monolithic applications is easy, as the developer can increase the processing and storage capacity of the host machine. Horizontal scalability can be accomplished by replicating data access layers and spreading the load of the client within each of these instances.

Since the monolithic architecture is simple and straightforward, an application with this paradigm can be easily implemented. Developers can start designing the application with a model entity view. This architecture can be easily mapped to the database design and applied to the application. It's also easy for developers to track, log, and monitor applications. Unlike the microservice architecture, which we will discuss later in this chapter, testing a monolithic application is also simple.

Even though it is simple to implement a monolithic application, there are lots of problems associated with maintaining it when it comes to building large, scalable systems:

Monolithic applications are designed, built, and implemented in a single unit. Therefore, all the components of the architecture of the system should be closely connected. In most cases, point-to-point communication makes it more difficult to introduce a new feature component to the application later.

As a monolithic application grows, it takes more time to start the entire application. Changing existing components or adding new features to the system may require stopping the whole system. This makes the deployment process slower and much more unstable.

On the other hand, having an unstable service in the system means the entire system is fragile. Since the components of a monolithic application are tightly coupled with each other, all components should function as planned. Having a problem in one subsystem causes all the dependent components to fail.

It is difficult to adopt modern technology because a monolithic application is built on homogeneous languages and frameworks. This makes it difficult to move forward with new technologies, and inevitably the whole system will become a legacy system.

Legacy systems have a business impact due to problems with the management of the system:

Maintaining legacy systems is costly and ineffective over time. Even though developers continue to add features, the complexity of the system increases exponentially. This means that organizations spend money on increasing the complexity of the application rather than refactoring and updating the system.

Security gets weaker over time as the dependent library components do not upgrade and become vulnerable to security threats. Migrating to new versions of libraries is difficult due to the tight coupling of components. The security features of these libraries are not up to date, making the system vulnerable to attacks.

When enforcement regulations become tidal, it gets difficult to adjust the structure according to these criteria. With the General Data Protection Act (GDPA) enforcement, the system should be able to store well-regulated information.

When technology evolves over time, due to compatibility problems, it is often difficult to integrate old systems with new systems. Developers need to add more adapters to the system to make it compliant with new systems. This makes the system a lot more complicated and bulkier.

Due to these obstacles, developers came up with a more modular design pattern, SOA, which lets developers build a system as a collection of different services. When it comes to SOA, a service is the smallest deployment unit used to implement application components. Each service is designed to solve problems in a specific business domain.

Services can be run on multiple servers and connected over a network. Service interfaces have loose coupling in that another service or client is able to access its features without understanding the internal architecture.

The core idea of SOA is to build loosely coupled, scalable, and reusable systems, where services work together to execute business logic. Services are the building block of SOA and are interconnected by protocols such as HTTP, JMS, TCP, and FTP. SOA commonly uses the XML format to communicate with other services. But interconnecting hundreds of services is a challenge if each service uses a point-to-point communication method. This makes it difficult to have thousands of links in interservice communication to maintain the system.

On the other hand, the system should be able to handle multiple different data formats, such as JSON, XML, Avro, and Thrift, which makes integration much more complicated. For engineers, observing, testing, migrating, and maintaining such a system is a nightmare. The Enterprise Service Bus (ESB) was introduced to SOA to simplify these complex messaging processes. In the next section, we will discuss what an ESB is and how it solves problems in SOA.

The ESB simplifies SOA

The ESB is located in the middle of the services, connecting all the services. The ESB provides a way of linking services by sitting in the center of services and offering various forms of transport protocols for communication. This addresses the issue of point-to-point connectivity issues where many services need to communicate with each other. If all of these services are directly linked to each other, communication is a mess and difficult to manage. The ESB decouples the service dependencies and offers a single bus where all of its services can be connected. Let's have a look at an SOA with point-to-point communication versus using an ESB for services to communicate:

Figure 1.3 – ESB architecture

On incoming service requests, the ESB may perform simple operations and forward them to another service. This makes it easier for developers to migrate to SOA and expose existing legacy systems as services so that they can be easily handled instead of creating everything from scratch.

An ESB is capable of managing multiple endpoints with multiple protocols. For example, an ESB can use the following features to facilitate the integration of services in SOA:

Security: An ESB handles security when connecting various services together. The ESB offers security features such as authentication, authorization, certificate management, and encryption to secure connected services.

Message routing: Instead of directly calling services, an ESB provides the modularity of SOA by providing routing on the ESB itself. Since all other services call the ESB to route services, developers can substitute service components without modifying the service.

Central communication platform: This prevents a point-to-point communication issue where each service does not need to know the address of the endpoint. The services blindly send requests to the ESB and the ESB routes requests as specified in the ESB routing logic. The ESB routes traffic between services and acts as smart pipes, and that makes service endpoints dumb.

Monitoring the whole message flow: Because the ESB is located in the center of the services, this is the perfect location to track the entire application. Logging, tracing, and collecting metrics can be placed in the ESB to collect the statistics of the overall system. This data can be used along with an analytical tool to analyze bugs, performance bottlenecks, and failures.

Integration over different protocols: The ESB ensures that services can be connected via different communication protocols, such as HTTP, TCP, FTP, JMS, and SMTP. It is also supported for various data interchange formats, such as JSON and XML.

Message conversion: If a service or client application is required to access another service, the message format may be modified from one to another. In this case, the ESB offers support for the conversion of messages across various formats, such as XML and JSON. It also supports the use of transformation (XSLT) and the modification of the message structure.

Enterprise Integration Patterns (EIP): These are used as building blocks for the SOA messaging system. These patterns include channeling, routing, transformation, messaging, system, and management. This helps developers build scalable and reliable SOA platforms with EIP.

SOA was used as mainstream cloud architecture for a long time until the microservice architecture came along as a new paradigm for building cloud applications. Let's discuss the emergence of the microservice architecture and how it solves problems with SOA in the next section.

The emergence of microservices

SOA provides solutions to most of the issues that monolithic applications face. But developers still have concerns about creating a much more scalable and flexible system. It's easy to construct a monolithic structure. But as it expands over time, managing a large system becomes more and more difficult.

With the emergence of container technology, developers have been able to provide a simple way to build and manage large-scale software applications. Instead of building single indivisible units, the design of microservices focuses on building components separately and integrating them with language-independent APIs. Containers provide an infrastructure for applications to run independently. All the necessary dependencies are available within a container. This solves a lot of dependency problems that can impact the production environment. Unlike virtual machines (VMs), containers are lightweight and easy to start and stop.

Each microservice in the system is designed to solve a particular business problem. Unlike monolithic architectures, microservices focus more on business logic than on technology-related layers and database designs. Even though microservices are small, determining how small they should be is a decision that should be taken in the design stage. The smaller the microservices, the higher the network communication overhead associated with them. Therefore, when developing microservices, choose the appropriate scope for each service based on the overall system design.

The architecture of microservices eliminates the concept of the ESB being the central component of SOA. Microservices prefer smart endpoints and dumb pipes, where the messaging protocol does not interfere with business logic. Messaging should be primitive in such a way that it only transports messages to the desired location. While the ESB was removed from the microservice architecture, the integration of services is still a requirement that should be addressed.

The following diagram shows a typical microservice architecture:

Figure 1.4 – Example microservice architecture

The general practice of the design of microservices is to provide a database for each service. The distributed system should be designed in such a way that disk space or memory is not shared between services. This is also known as shared-nothing architecture in distributed computing. Sharing resources creates