June 24, 2022 | Updated: January 10, 2023
We’re proud to announce further expansion in the Middle East coming in 2023 with the launch of MongoDB Atlas on AWS in the United Arab Emirates (UAE) region. MongoDB Atlas is now available in 22 AWS regions around the world, including eight Asia Pacific regions and three Middle East and Africa regions.
The UAE region is an AWS Recommended Region, meaning it has three Availability Zones (AZ), bringing significant infrastructure to the Middle East. After the expansion in 2023, when you deploy a cluster in the UAE, Atlas automatically distributes replicas to the different AZs for higher availability. If there’s an outage in one zone, the Atlas cluster will automatically fail over to keep running in the other two. And you also will be able to deploy multi-region clusters with the same automatic failover built-in.
We’re delighted that — as with customers in Bahrain, Cape Town, and more — United Arab Emirates organizations will be able to keep data in their own country, delivering low-latency performance and ensuring confidence in data locality. We’re confident our UAE customers in government, financial services, and utilities in particular will appreciate this upcoming capability as they build tools to improve citizens’ lives and better serve their local users.
MACH Aligned for Retail: API-First
Retailers must constantly evolve to meet growing customer expectations and remain competitive. Both their internal- and external-facing applications must be developed using principles that promote agility and innovation, moving away from siloed architectures. As discussed in the first article of this series , the MACH Alliance promotes the development of modern applications through open tech ecosystems. MACH is an acronym that represents Microservices, API-first, Cloud-native SaaS, and Headless. MongoDB is a proud member of the Alliance, providing retailers with the tools to build highly flexible and scalable applications. This is the second in a series of blog posts focused on MACH and how retail organizations can leverage this framework to gain a competitive advantage. In this article, we’ll discuss concepts relating to the second letter of MACH: API-first. Read the first post in this series, "MACH Aligned for Retail: Microservices." What is an API-first approach and why is it important? An application programming interface (API) is a set of routines, protocols, and tools that allow applications, or services within a microservices architecture, to talk to each other. APIs can be seen as messengers that deliver requests and responses. Applications built around APIs are said to be API-first. With this approach, the design and development of APIs come before the software implementation. Typically, an interface is created that is used to host and develop the API. The development team will then leverage the interface to build the rest of the application. This methodology enables developers to have access to specific functionalities of external applications or other microservices within the same application, depending on their needs. It promotes reusability because functionalities are interoperable with mobile and other client applications. In addition, applications developed with an API layer in mind can adapt to new requirements more easily because additional services and automation can be integrated into production when new requirements arise, therefore remaining competitive for longer. An API-first approach to developing applications The role of API-first in retail APIs play a crucial role in deeply interconnected systems that need to interface with other internal applications, third-party partners, and customers — all key areas when it comes to developing powerful retail applications. Think about how an e-commerce platform connects to the different systems making up the purchase process, such as inventory management, checkout, payment processing, shipping, and loyalty programs. The use of APIs is deeply interlinked with the concept of microservices . Software and data need to be decoupled to enable retailers to meet ever-increasing requirements, including omnichannel and cross-platform integration, seamless experiences across physical and online stores, and the ability to leverage real-time capabilities that enable differentiating features, such as live inventory updates and real-time analytics. APIs can be seen as a bridge for loosely coupled microservices to communicate with each other. Besides enabling a microservices architecture, an API-first approach offers the following additional benefits: Avoid duplication of efforts and accelerate time to market . Developers can work on multiple frontends at the same time, being confident that functionalities can be integrated by embedding the same APIs once ready. Think of multiple development teams working on an e-commerce web application, mobile portal, and internal inventory management system all at the same time. An API enabling the placement of a new order can be seamlessly leveraged by the web and mobile application and fed into the inventory management system to aid warehouse workers. Bug-fixing and feature enhancements can happen simultaneously, avoiding duplication of efforts and allowing new capabilities to be released to market more quickly. Reduce risks and operating costs . An API-first approach enables system stability and interoperability from the beginning because API efficiency is placed at the center of the development lifecycle and is no longer an afterthought once the application or functionality has been developed. This approach reduces the risk for retailers and saves money and effort in troubleshooting unstable systems. Enable new opportunities and scale faster . A flexible approach revolving around APIs provides more opportunities when it comes to integrating and refactoring the way different client applications and microservices communicate with each other, allowing retailers to improve and scale their IT offering in a fraction of the time. This approach also changes the way retailers can interact with external partners and do business with them since they can be provided with the tools to easily integrate with the retailer’s offering. Achieve language flexibility . Effective retailers need to have the capability to adapt their digital offering to different regions and languages. The plug-in capabilities of API-first allow developers to offer language-agnostic solutions that different microservices can integrate with, leveraging region-specific frontends. Steps to an API-first application What is the alternative? The four MACH Alliance principles combined (Microservices, API-first, Cloud-native SaaS, Headless) act as a disrupting force compared to the way applications were built until recently. Adapting to a new technology paradigm requires effort and a different developer mindset. But what was there before? From an API-first perspective, it can be said that the opposite is code-first. With this approach, application development starts in the integrated development environment (IDE), in which code is written and the software takes shape. Development teams know that they will need to build an interface to be able to interact with each function of the code, but it is seldom a priority; developing core functionalities takes precedence over the interface where those functionalities will be hosted and accessed. When the time comes for the interface to be developed, the code has already been defined. This means the API is developed around existing code rather than vice versa, which poses limitations. For example, developers might not be able to return data the way they want because of the underlying data schema. The code-first approach Bottlenecks can also occur as other teams requiring the API will need to wait until the code is finalized to be able to embed it in their underlying applications. Any delays in the software development lifecycle will hold them up and delay progress. Although a code-first approach might have worked in the past, it is no longer suitable for dealing with highly interconnected applications. Learn more about how MongoDB and MACH are changing the game for ecommerce. How MongoDB helps achieve an API-first approach Simply lifting and shifting monolithic applications to a microservice and API-first architecture will only provide minimal benefits if they are still supported by a relational data layer. This is where most of the bottlenecks occur. Changes to application functionalities will require constant refactoring of the database schemas, object-relational mapping (ORM), and refining at the microservice level. Moving to a modern MACH architecture requires a modern data platform that removes data silos. The MongoDB developer data platform provides a flexible data model, along with automation and scalability features to adapt to even the most challenging retail use cases and to multiple platforms (e.g., on-premises, cloud, mobile, and web applications). MongoDB Atlas, MongoDB’s fully managed cloud database, also provides capabilities to manage the data layer end to end via APIs, such as the MongoDB Atlas Data API . This is a REST-like, resilient API for accessing all Atlas data that enables CRUD operations and aggregations with instantly generated endpoints. This is a perfect answer to an API-first approach, since developers can access their data using the same principles leveraged to connect to other applications and services. The MongoDB Atlas Data API workflow MongoDB’s Atlas Data API provides several other benefits, allowing developers to: Build faster with developer-friendly data access. Developers work with a familiar, REST-like query and response format, no client-side drivers are necessary. Scale confidently with a resilient, fully managed API that reduces the operational complexity needed to start reading and writing your data. Integrate your MongoDB Atlas data seamlessly into any part of your stack — from microservices to analytics workloads. This article has provided only a sample of what can be leveraged via MongoDB’s APIs. The MongoDB Query API provides a comprehensive set of features to seamlessly work with data in a native, familiar way. It supports multiple index types, geospatial data, materialized views, full-text search, and much more. In the next part in this MongoDB and MACH Alliance series, we will discuss how a cloud-native SaaS architecture can enable full application flexibility and scalability. Read the first post in this series, "MACH Aligned for Retail: Microservices."
RegData & MongoDB: Streamline Data Control and Compliance
While navigating the requirements of keeping data secure in highly regulated markets, organizations can find themselves entangled in a web of costly and complex IT systems. Whether it's the GDPR safeguarding European personal data or the Monetary Authority of Singapore's guidelines on outsourcing and cloud computing , the greater the number of regulations organizations are subjected to, particularly across multiple geographical locations, the more intricate their IT infrastructure becomes, and organizations today face the challenge of adapting immediately or facing the consequences. In addition to regulations, customer expectations have become a major driver for innovation and modernization. In the financial sector, for example, customers demand a fast and convenient user experience with real-time access to transaction info, a fully digitized mobile-first experience with mobile banking, and personalization and accessibility for their specific needs. While these sorts of expectations have become the norm, they conflict with the complex infrastructures of modern financial institutions. Many financial institutions are saddled with legacy infrastructure that holds them back from adapting quickly to changing market conditions. Established financial institutions must find a way to modernize, or they risk losing market share to nimble challenger banks with cost-effective solutions. The banking market today is increasingly populated with nimble fintech companies powered by smaller and more straightforward IT systems, which makes it easier for them to pivot quickly. In contrast, established institutions often operate across borders, meaning they must adhere to a greater number of regulations. Modernizing these complex systems requires the simultaneous introduction of new, disruptive technology without violating any regulatory constraints, akin to driving a car while changing a tire. The primary focus for established banks is safeguarding existing systems to ensure compliance with regulatory constraints while prioritizing customer satisfaction and maintaining smooth operations as usual. RegData: Compliance without risk Multi-cloud application security platform, RegData embraces this challenge head-on. RegData has expertise across a number of highly regulated markets, from healthcare to public services, human resources, banking, and finance. The company’s mission is clear—delivering a robust, auditable, and confidential data protection platform within their comprehensive RegData Protection Suite (RPS), built on MongoDB. RegData provides its customers with more than 120 protection techniques , including 60 anonymization techniques, as well as custom techniques (protection of IBANs, SSNs, emails, etc), giving them total control over how sensitive data is managed within each organization. For example, by working with RegData, financial institutions can configure their infrastructure to specific regulations, by masking, encrypting, tokenizing, anonymizing, or pseudonymizing data into compliance. With RPS, company-wide reports can be automatically generated for the regulating authorities (i.e., ACPR, ECB, EU-GDPR, FINMA, etc.). To illustrate the impact of RPS, and to debunk some common misconceptions, let’s explore before and after scenarios. Figure 1 shows the decentralized management of access control. Some data sources employ features such as Field Level Encryption (FLE) to shield data, restricting access to individuals with the appropriate key. Additionally, certain applications implement Role-Based Access Control (RBAC) to regulate data access within the application. Some even come with an Active Directory (AD) interface to try and centralize the configuration. Figure 1: Simplified architecture with no centralized access control However, each of these only addresses parts of the challenge related to encrypting the actual data and managing single-system access. Neither FLE nor RBAC can protect data that isn’t on their data source or application. Even centralizing efforts like the AD interface exclude older legacy systems that might not have interfacing functionalities. The result in all of these cases is a mosaic of different configurations in which silos stay silos, and modernization is risky and slow because the data may or may not be protected. RegData, with its RPS solution, can integrate with a plethora of different data sources as well as provide control regardless of how data is accessed, be it via the web, APIs, files, emails, or others. This allows organizations to configure RPS at a company level. All applications including silos can and should interface with RPS to protect all of the data with a single global configuration. Another important aspect of RPS is its functions with tokenization, allowing organizations to decide which columns or fields from a given data source should be encrypted according to specific standards and govern the access to corresponding tokens. Thanks to tokenization, RPS can track who accesses what data and when they access it at a company level, regardless of the data source or the application. This is easy enough to articulate but quite difficult to execute at a data level. To efficiently manage diverse data sources, fine-grained authorization, and implement different protection techniques, RegData builds RPS on top of MongoDB's flexible and document-oriented database. The road to modernization As noted, to fully leverage RegData’s RPS, all data sources should go through the RPS. RPS works like a data filter, putting in all of the information and extracting protected data on the other side, to modernize and innovate. Just integrating RegData means being able to make previously siloed data available by masking, encrypting, or anonymizing it before sending it out to other applications and systems. Together, RegData and MongoDB form a robust and proven solution for protecting data and modernizing operations within highly regulated industries. The illustration below shows the architecture of a private bank utilizing RPS. Data can only be seen in plain text to database admins when the request comes from the company’s headquarters. This ensures compliance with regulations, while still being able to query and search for data outside the headquarters. This bank goes a step further by migrating their Customer Relationship Management (CRM), core banking, Portfolio Management System (PMS), customer reporting, advisory, tax reporting, and other digital apps into the public cloud. This is achieved while still being compliant and able to automatically generate submittable audit reports to regulating authorities. Figure 2: Private bank business care Another possible modernization scheme—given RegData’s functionalities—is a hybrid cloud Operational Data Layer (ODL), using MongoDB Atlas . This architectural pattern acts as a bridge between consuming applications and legacy solutions. It centrally integrates and organizes siloed enterprise data, rendering it easily available. Its purpose is to offload legacy systems by providing alternative access to information for consuming applications, thereby breaking down data silos, decreasing latency, allowing scalability, flexibility, and availability, and ultimately optimizing operational efficiency and facilitating modernization. RegData integrates, protects, and makes data available, while MongoDB Atlas provides its inherent scalability, flexibility, and availability to empower developers to offload legacy systems. Figure 3: Example of ODL with both RegData and MongoDB In conclusion, in a world where finding the right solutions can be difficult, RegData provides a strategic solution for financial institutions to securely modernize. By combining RegData's regulatory protection and modern cloud platforms such as MongoDB Atlas, the collaboration takes on the modernizing challenge of highly regulated sectors. Are you prepared to harness these capabilities for your projects? Do you have any questions about this? Then please reach out to us at email@example.com or firstname.lastname@example.org You can also take a look at the following resources: Hybrid Cloud: Flexible Architecture for the Future of Financial Services Implementing an Operational Data Layer