This article discusses the advantages and real-time use cases of the Subscription Rules for the multiple Cloud Messaging options of Service Bus.

In this article, supplement your knowledge of Google Cloud Pub/Sub by learning how to create Spring Boot microservices to publish and subscribe to messages.

In this article, we’ll look at some microservices best practices and suggest a few ways to help you design, orchestrate, and secure your microservices architecture.

Modern applications rely on multiple data models that generate different data types. To help such use cases, NoSQL (Not only SQL) databases allow for the storage and processing of different data types in a non-tabular fashion. NoSQL databases process unstructured data using flexible schemas to enable efficient storage and analysis for distributed, data-driven applications. By relaxing data consistency restrictions of SQL-based databases, NoSQL databases enable low latency, scalability and high performance for data access. The performance of SQL databases varies with the cluster size, the application’s configuration and network latency. This means that developers don’t have to worry about optimizing data structures, indexes and queries to achieve peak performance from the storage subsystem. NoSQL databases are popular with modern cloud applications since they use APIs for the storage and retrieval of data structures. This makes it easy to interface NoSQL databases with a host of microservice-based applications for agile, cloud-native deployment. OpenEBS is a leading Container Attached Storage (CAS) that helps developers deploy workloads efficiently by turning storage available on worker nodes into dynamically provisioned volumes. With OpenEBS, developers can implement granular policies per workload, reduce storage costs, avoid vendor lock-in and develop persistent storage for applications with high availability. This post delves into how OpenEBS can be used to provision high-performance storage for NoSQL databases. A Deep Dive into NoSQL Databases Before the mid-2000s, relational databases dominated application development. The Structured Query Language (SQL) was used to store and retrieve data structures, with popular databases being MySQL, Oracle, PostgreSQL, DB2 and SQL Server. The decrease in the cost of storage options eliminated the need to use strict, complex data models allowing for data applications to store and query more types of data. NoSQL databases evolved to handle the flexible schema needed to process different combinations of structured, semi-structured and polymorphic data. This section explores various features, types and popular distributions of NoSQL databases. Features of NoSQL Databases Though there are various flavours of NoSQL databases, here’s a list of common features that distinguish them from SQL databases: Multi-Model NoSQL databases are built for flexibility to handle large amounts of data. Unlike SQL-based databases that access & analyze data in tables and columns, NoSQL databases ingest all types of data with relative ease. NoSQL databases enable the creation of specific data models for each application, enhancing agility in handling different data types without having to manage separate databases. Schema Agnostic Schemas are used to instruct a relational database on what data to expect and how to store the data. Any changes in data structures or data paths require extensive re-architecting of the database using a modified schema. On the contrary, NoSQL databases require no upfront design work before data is stored. These databases shorten development time by allowing developers to start coding and accessing data without having to understand the internal implementation of the database. Non-Relational Relational databases have strict restrictions on how tables associate with each other while relying on traditional master-slave architecture. On the other hand, NoSQL databases do not rely on tabularized data with fixed row and column records while running on peer-to-peer networks with no concept of relationships between their records. The databases, therefore, facilitate easy storage & retrieval and fast query speed for data-driven applications. Distributable NoSQL database systems are designed to use multiple locations involving different data centres/regions for global scalability. Thanks to their masterless architecture, NoSQL databases can maintain continuous availability through the replication of data in multiple read/write locations. Easily Scalable While relational databases are also scalable, their scalability is costly and complex since their architecture requires the addition of larger, more powerful hardware for scaling. NoSQL databases allow for linear scalability both vertically and horizontally, so developers can either provide more processors or powerful ones for increased workloads. Types of NoSQL Databases Document Databases In this database, data is represented as a JSON-type document or object for efficient and intuitive data modelling. Document-type NoSQL databases simplify application development since developers can query and store data with the same document model format used in application source code. Document databases are flexible, hierarchical and semi-structured, so they scale to match with an application’s evolving needs. Graph NoSQL Databases These databases store data in edges and nodes. A node stores information about entities while the edge stores information about the relationship between these entities. These databases are mostly used in applications that analyze relationships between users and other entities to identify patterns. These include social networking, knowledge graphs, recommendation engines and fraud detection. Key-Value Databases These store data in simple key-value pairs. Values are retrieved by referencing their keys, which simplifies how developers query for specific data entries. These databases are highly applicable in applications that need to store large amounts of data without needing complex query operations for retrieval. The most common use-case for key-value databases is the storage of user preferences. Wide-Column Stores These databases use dynamic columns, rows and tables to store data. They are more flexible than relational databases since each row can have a different number of columns. Wide column stores are used for large amounts of data with predictable query patterns. Popular NoSQL Databases Some popular NoSQL Database management solutions include: Cassandra A free, open-source, distributed, wide-column store that powers mission-critical deployments with fault-tolerant replication, hybrid cloud support and audit logging. Apache Cassandra is trusted by major brands, such as Facebook, Netflix, Macy’s and MobilePay for scalability, high availability and improved performance. Follow this guide to explore the steps to deploy Cassandra StatefulSets with OpenEBS storage. MongoDB MongoDB is popular with modern application development as it relies on the document data model to simplify database management for developers. MongoDB includes functionality such as data-geolocation, horizontal scaling and automatic failover to accelerate development and adapt to application changes. Read this guide to discover how to provision Persistent Volumes for MongoDB StatefulSets in Kubernetes with OpenEBS. Redis An open-source, distributed, in-memory key-value data store that can be used in application development as a message broker, cache and database. Redis supports multiple types of abstract data structures and provides high availability through automatic disk partitioning and the Redis Sentinel framework. This guide demonstrates how OpenEBS can be used to provide persistent storage for Redis StatefulSets. OpenEBS for NoSQL Databases OpenEBS simplifies the deployment of stateful Kubernetes workloads using a collection of data engines to implement persistent volumes. The OpenEBS control plane is deeply integrated with Kubernetes, and uses Kubernetes-friendly constructs to manage how volumes are provisioned, scheduled and maintained. With OpenEBS, cluster administrators can take advantage of dynamic provisioning for local and distributed volumes, depending on workload and cluster size. These features make OpenEBS a popular choice to orchestrate storage for stateful applications. The following section explores the steps taken to provision OpenEBS storage for NoSQL databases. Why Adopt OpenEBS for NoSQL? Many organizations and users have adopted OpenEBS to deploy and provision storage for their stateful workloads, including those who use NoSQL. Some of the following are reasons to adopt OpenEBS for NoSQL databases include: Open-Source, Kubernetes-Centric Cloud Native Storage OpenEBS follows a loosely coupled Container Attached Storage (CAS) architecture. OpenEBS itself is deployed as a workload on Kubernetes nodes, bringing the DevOps benefits of container orchestration in the application layer to the data layer. This allows developers to leverage the cloud-native benefits of Kubernetes such as agility and scalability for developing reliable, effective data-driven applications. No Cloud Lock-in With OpenEBS, application data is written into storage engines, creating a data abstraction layer. This allows developers to move data easily between multiple Kubernetes environments. OpenEBS can be deployed on-premises, local storage or managed cloud services -- thereby allowing NoSQL applications to simultaneously access data stored on different deployment platforms. OpenEBS Enables Granular Deployment and Management of Workloads The cloud-native, loosely-coupled architecture of OpenEBS clusters enable multiple teams to deliver faster since they are free of cross-functional dependencies. OpenEBS also makes it easier to declare policies and settings on a per-workload or per-volume basis, with constant monitoring to ensure workloads achieve desired results. Granularity makes it easier for developers to segregate large amounts of data based on data type, structure or use-case. Reduced Storage Costs The dynamic nature of NoSQL data often necessitates the over-provision of cloud storage resources to achieve higher performance and a lower risk of disruption. To help with this, OpenEBS relies on thin provisioning mechanisms to pool storage and grow data volumes when the NoSQL database needs it. While adjusting storage on the fly without disrupting volumes attached to workloads, OpenEBS enables cost savings of up to 60% leveraging a thin, dynamic provisioning. Configuration Workflow To provision high-performance storage for NoSQL databases using OpenEBS, the following steps are undertaken: Installing OpenEBS - OpenEBS integrates seamlessly into the Kubernetes workflow and is installed into the cluster using installation modes available to Kubernetes applications, such as helm and with YAML files via kubectl. This activates a declarative storage control plane that can be managed from within the cluster. Selecting the OpenEBS storage engine - The storage engine represents OpenEBS data plane components. OpenEBS includes a number of storage engines and may automatically choose one that suits the storage available on nodes and application requirements. OpenEBS comes with three storage engines: cStor, Jiva, Local PV and Mayastor. Creating a Storage Class - The StorageClass is used to provision volumes on physical storage devices. These classes consume storage pools created on the disks attached to cluster nodes. Launching the NoSQL database - The database is then deployed into the cluster either using operators or helm charts. A typical architecture of NoSQL database with OpenEBS Persistent Volumes Monitoring Deployment Metrics OpenEBS includes post-deployment recommendations to ensure a successful deployment for NoSQL workloads. While developers are advised to allocate sufficient volume size during initial configuration, the volume size should be constantly monitored to ensure seamless operation. Additionally, developers and administrators should watch pool capacity and add more physical disks once the workload hits an 80% threshold. OpenEBS integrates with Kubernetes centric monitoring & logging tools such as Prometheus and Grafana for easier metric collection, analysis and visualization. NoSQL databases enable data-driven application development since they facilitate global scalability, flexibility and delivery agility. Cloud-native application architectures are considered perfect for NoSQL databases since they deliver on-demand infrastructure for dynamic workloads. As an essential enabler, OpenEBS can orchestrate stateful Kubernetes workloads including NoSQL databases, offering multiple benefits such as reduced storage costs and zero lock-in. To know more on how OpenEBS can help to manage your organization’s stateful workloads, contact us here. This article has already been published on https://blog.mayadata.io/provisioning-high-performance-storage-for-nosql-databases-with-openebs and has been authorized by MayaData for a republish.

To prevent a few compromised services from affecting all the services on the platform, a microservices platform needs to limit the interactions between services.

The Agile Enterprise Architecture Framework helps formulate a model in which the Agile Enterprise architect can be involved in the end-to-end activities.

Want a powerful, self-hosted personal cloud? Then look no further than Nextcloud running on Kubernetes with a service mesh to add all the help and features you need.

Now that you are running on Heroku, John Vester helps explore options for scaling your applications or services to meet end-user demands.

In this article, we'll learn how to use the Spring Cloud Configuration server to centralize managing the configuration of our microservices.

Read this article to learn core concepts of Mule servers, server group, and cluster of Mule runtime engine instances (servers).

In this post, we’ll take a close look at how Kong Gateway and the Kuma service mesh fit into a Zero Trust architecture security design.

Vue.js is a popular JavaScript framework to create interactive applications. Did you know it provides data-reactive components with a simple and flexible API?

Cloud migration is accelerating every day but every application you migrate is not configured for a cloud environment, that's where re-platform strategy comes into play.

In this article, we want to focus on using Kafka in the microservice architecture, and we need an important concept named Kafka Topic for that.

Editor's Note: The following is an article written for and published in DZone's 2021 Low-Code Development Trend Report. If you ride on a sailboat in a steady breeze, it glides through the water effortlessly. Few things can compare to crossing a bay without the noise and commotion of a thundering internal combustion engine. The dream of no-code and low-code development is to effortlessly glide from problem to solution. Back in the ‘80s, no-code/ low-code development was called “end-user computing.” Since the invention of the spreadsheet, we’ve had a kind of low-code computing. The technologies continue to evolve. Let’s take our boat out of the slip and sail around a little. We’ll look at two ways Python is commonly used to create no-code and low-code solutions to problems. The first thing we’ll look at is using JupyterLab to create solutions to problems with minimal code. I liken this to using winches to help lift the sails. It’s not an internal combustion engine, but it is a machine that helps us manipulate heavy, bulky items like sails and anchors. The second thing we’ll sail past is using Python as an integration framework to knit together tools and solutions that aren’t specifically written in Python themselves. In this case, we’re going to be writing integration code, not solution code. This is how sailboats work; given a hull and some masts, you’ll have to select and set the sails that will make the boat move. JupyterLab As a developer, and as a writer about Python, I rely on JupyterLab a lot. It’s often the tool I start with because I get handy, pleasant spreadsheet-like interaction. The “spreadsheet” feature that I’m talking about is the ability to change the value of one cell, and then recompute the remaining cells after that change. This lets me create elegant, interactive solutions where the bulk of the interaction is handled by the notebook’s internal model: a lattice of inter-dependent cells. In this picture, we can see the computation of cell 2 depends on prior results in cell 1. I consider this “low code” because there’s a vast amount of code we don’t need to write. The Jupyter Notebook provides us an interactive framework that’s robust and reliable. More important than that, the framework fits the way a lot of people have grown to use computers by putting values into some cells and checking results in other cells. The big difference between Jupyter and a spreadsheet is Jupyter lets us write extensions and expressions in Python. Recently, I had a boat-related problem crop up that was perfect for this kind of low-code processing. The tank under the pointy part of the boat (the “V-berth”) has a fairly complex shape. The question really is: “How big is it?” The problem is access; I have to make a series of approximations and models. I really need a spreadsheet-like calculator, but I need a lot more mathematical processing than is sensible in a spreadsheet. Consequently, let me apologize to any math-phobic readers. This example involves a lot of math. For folks who don’t like math, think of using a spreadsheet where you never looked at the formula in a given column. A notebook can (and often does) hide the details. This specific example doesn’t try to hide the details. Here’s an example: https://github.com/slott56/replacing-a-spreadsheet. I want to lift up a few key features of this low-code development approach. I created three notebooks, each of which had a common structure. They all have a collection of measurements as the input. As the output, it reports a computed volume. The rest of the cells provide some background to help me make sure the math is right. Here’s the input cell’s content in the “prism.ipynb” notebook. This is cell 8. Python measured = { # Forward triangle, in inches "h_f": 8, "w_f": 10 + Rational(1, 2), # Aft triangle, in inches "h_a": 27, "w_a": 48, # Overall length from forward to aft, in inches. "l_fa": 46, } This is a Python dictionary that has a number of input values. This is a bit more complex-looking than spreadsheet cells, making it solidly “low-code” not “no-code.” The output is computed in cell 10, providing a single numeric result with a format like the following: '50 85/88 gallons' This shows me that the volume of space, given the measurements, is just shy of 51 gallons. The best part about this data is there are two kinds of changes I can make. The most important change is to the measurements, which leads to recomputing the notebook. Anyone who can use a spreadsheet can alter the numbers to the “measured” dictionary to recompute the volume. The other change I can make is to adjust some of the underlying assumptions. This is a more nuanced change to the model that is also implemented in the notebook. I find that for a wide variety of problems, a notebook is the place to start. It lets me gather data, formulate alternative approaches to algorithms and data structures, and work out candidate solutions that are richly interactive. This is an excerpt from DZone's 2021 Low-Code Development Trend Report. For more: Read the Report The JupyterLab project is like a boat with three masts and dozens upon dozens of sails for all conditions and situations. There are a lot of features that can be used to create interactive solutions to problems. The idea is to write only the code that’s directly related to the problem domain and leverage the notebook’s capabilities to present the solution so that people can make decisions and take actions. In addition to the notebook for a low-code interactive user experience, we can look at Python as an engine for integrating disparate applications together. Python as Integration Engine Python’s standard library includes modules to help us work with OS resources, including other applications. Rather than build or modify existing code, we can treat applications as opaque boxes and combine them to create an integrated solution. To a limited extent, integration applications is what shell scripts do. There’s a world of difference, however, between integration with a shell script and integration with Python. Shell scripting involves the almost impossible-to-understand shell programming language. (See this article on replacing shell scripts with Python for more thoughts on this.) When we integrate applications with Python, we can easily introduce additional computations and transformations. This can help to smooth over gaps, remove manual operations, and prevent potential errors. I’m a fan of code like the following: Python command = [ "markdown_py", "-v", "-e", "utf-8" ] temp = options.input.with_suffix(".temp") output = options.input.with_suffix(".html") params = dict(CSS=str(options.style), TITLE=options.title) with temp.open('w') as temporary, options.input.open() as source: subprocess.run(command, stdout=temporary, stdin=source) This is part of a larger and more complex script to publish a complex document written in markdown. It has a lot of code examples, which are a lot easier to read in HTML format. I must do some pre-processing of the markdown and some post-processing of the HTML. It seems easiest to execute the markdown_py command from inside a Python script, avoiding a complex python-bash-python kind of process. Since I’m not modifying the underlying applications, I find this fits with a low-code approach. I’m using the source application (markdown_py) for the thing it does best — adjusting the inputs and outputs using Python. Conclusion We can use Python in a variety of ways. It’s a programming language, so we can build code. More importantly, we can use the vast number of pre-built Python libraries to create low-code solutions. We can use a Jupyter Notebook as a low-code way to create a sophisticated interactive experience for users, and we can use Python to integrate other applications. Sailing isn’t effortless. The boat glides only when the sails are set properly, and we keep the rudder in the right position. Just as skill and expertise are required to make a boat move, so too is careful attention needed to write the minimal Python code to solve an information processing problem. Steven Lott, Writer, Python Guru & Retiree @slott on DZone | @s_lott on Twitter | slott-softwarearchitect.blogspot.com Steven has been programming since the 70s, when computers were large, expensive, and rare. As a former contract software developer and architect, he worked on hundreds of projects from very small to very large. He’s been using Python to solve business problems for over 20 years. His titles with Packt Publishing include Python Essentials, Mastering Object-Oriented Python, Functional Python Programming, Python3 Object-Oriented Programming, and Python for Secret Agents. Steven is currently a technomad who lives in various places on the east coast of the US.

Do you want to make the most out of your integration tests by using the popular Testcontainers library? Learn how to use it from the ground up.

Learn how Microservice Architecture strategy drives the teams naturally Agile.

See the 10 most popular articles on Low-Code with topics covering Low-Code introduction, building an application with Low-Code, comparison with Microservices, a smack-down with pro-code, and more!

In this article, you’ll learn about implement and design Twitter search backend systems functionality how to work using Java microservices with explanations.

Learn what Tomcat clustering is and what problems it can solve by working together with Redis.