Julien Contarin

3 results

Application Modernization with gravity9 And MongoDB Atlas: How Digital Decoupling Supports the Customer Offering

The goal of most organizations is pretty clear: to improve customer offerings and become more operationally efficient, streamlined and profitable. But is it possible for organizations to excel in an agile fashion when they are reliant upon legacy systems? It’s the age-old dilemma between risk and innovation. How can you mitigate the former while accelerating the latter? Nearly all organizations operate with some type of legacy system in place that, often, is central to the operation of the business or the customer offering—i.e., one that would be highly costly and disruptive to move away from. To solve this predicament, the process of digital decoupling enables organizations to detach incrementally from legacy systems while acknowledging the critical role they often play. In this blog, we’ll further explore the value of digital decoupling as well as introduce how gravity9 with MongoDB Atlas delivers the smoothest transition possible. Why Not Simply Upgrade? Digital decoupling is not a “big-bang” upgrade where one system is fully replaced by another overnight; rather, it allows for the continued existence of your legacy system as part of your digital architecture while simultaneously unlocking innovation. But why not simply upgrade? Isn’t “out with the old and in with the new” the faster route to take? Not always. When a big-bang upgrade focuses on the replacement of a legacy system that is central to a customer offering or business operations, it becomes a much more complex, risky, and time-intensive undertaking. Often, many months or years can pass before any value is delivered to customers. But while your organization is focusing time and effort on a long-term, large-scale system replacement initiative, your customers’ needs will be changing and your competitors will be continuing to innovate. Once your new system is finally ready to be deployed to the marketplace, there’s a good chance it may already be rendered obsolete. Digital decoupling offers a faster, less risky, and more flexible alternative. The legacy system is maintained as the core of your business, but strategic portions are exposed through modern microservices to allow for the rapid creation of new digital products and offerings. The organization can utilize new, modern technologies to maintain the functionality of the legacy system while building a more advanced, digital architecture around it. By maintaining the existing legacy system, the organization significantly reduces disruption and risk while unlocking the ability to innovate new products on a rapid timescale. How it Works Applying a digital decoupling approach makes quickly innovating new digital products and services on top of your data possible by way of microservices and an event-driven architecture. Microservice Architecture after Digital Decoupling By utilizing event-driven architecture, individual systems and capabilities can be built as fully scalable microservices each with their own database, allowing solutions to be built around each microservice that can be combined to provide limitless additional capabilities and services for customers in a rapid and agile fashion. Digital decoupling creates a customer experience delivered via a modern, feature-rich UI or website that is intuitive, user friendly and continuously evolving, while the legacy system still operates behind the scenes. After years of working with large organizations, the solutions architects at gravity9 have a deep understanding of event-driven architecture as a solution to digital decoupling. Our adherence to domain-driven design is in our DNA , it is how we build solutions and is core to the way we work….We build event-driven microservices on top of monolithic legacy architecture. Noel Ady, gravity9 Founding Partner. By utilizing domain-driven design, system actions are communicated or triggered by way of an event, with colloquialized messages sent between the legacy application and the new architecture via a bus. An adaptor is created to sit in front of the legacy system and speak to your “new IT” in the language of events. This adaptor looks at the data in your legacy system and raises events when changes occur, then optionally writes back changes raised by other systems, allowing your legacy system to participate in the event-driven architecture. The use of APIs ensures the traffic is two-way and non-intrusive to the legacy application so that it can continue to operate as expected. One of the key technology concerns related to adaptors for legacy systems is the concept of a “delta store.” Events in an event-driven architecture should contain the context for the event, often including the previous value, to help receiving systems properly respond to the event. In more modern systems it’s possible to get this data from webhooks or similar alternatives, but these mechanisms won’t exist in older legacy systems so a different approach via a delta store is needed. A delta store will contain the history of changes on a value (the ‘deltas’) to allow the adaptor to properly construct the event context and to ensure that events are only raised for true changes in values. Why MongoDB? MongoDB’s flexible data schema makes it an excellent implementation technology for a delta store, allowing a dynamic mechanism that can flex to new data and event types on demand. gravity9 partners with MongoDB Atlas, MongoDB’s multi-cloud, secure and flexible database service, as an integral technology enabler of digital decoupling to increase flexibility of the resulting architecture. Importantly, Atlas also enhances reliability for mission-critical production databases with continuous backups and point-in-time recovery. It’s secure for sensitive data and automates key processes like infrastructure provisioning, setup and deployment so teams can access the database resources they need, when they need them. Best of all, MongoDB’s features and benefits help free up developer time so they can focus their talent on more innovative tasks. What Should I do Next? The logic is just as important as the physical in digital decoupling when it comes to modelling your events. Utilizing best-practice, domain-driven design alongside a proven approach is the key to success. Together, gravity9 and MongoDB have replicated this success time and time again, enabling organizations to lay the foundations for newer more modern architecture without the disruption of removing their legacy systems. Interested in learning more about MongoDB’s Modernization Program? Contact us today!

May 27, 2021

How Accenture’s Data Modernizer Tool Accelerates the Modernizing of Legacy and Mainframe Apps to MongoDB

As companies scale their MongoDB estates and apply them to more and more use cases, opportunities for deeper insights arise—but first come issues around data modeling. The Challenge It’s one thing to start modeling for a green field application where you have the ability to apply modeling patterns . But it’s a different matter entirely to start from an existing relational estate and take into account multiple data sources and their business requirements in an effort to create the ideal MongoDB data model based on explicit schema (table and relations) as well as implicit schema (access patterns and queries). Unfortunately, this is a fairly common obstacle. Perhaps an application has been around for a while and documentation hasn’t kept up with changes. Or maybe a company has lost talent and expertise in some areas of a monolithic app. These are just a couple of examples that demonstrate how time consuming and error-prone this effort can be. The Solution MongoDB and Accenture are excited to announce a modernization tool which enables faster MongoDB adoption by accelerating data modeling. As part of its mainframe offload and cloud modernization initiatives, Accenture’s Java-based data modernizer helps companies arrive at a recommended MongoDB document data model more quickly and efficiently. Using this tool results in a faster operational data layer for offloading mainframes and faster implementation of MongoDB Atlas for migrating applications to the cloud while also transforming them. Accenture and MongoDB are long-standing strategic partners, and this investment is another addition to our joint customers’ toolkits. “This modernizer is the right tool for teams who are focused on changing business requirements as they rethink their applications for the cloud. With on average 50% faster data modeling and 80% data model accuracy straight out of the tool, developers can work on modernizing instead of spending weeks figuring out the right data model to simply meet existing business requirements that have not been explicit.” (Francesco De Cassai) How it Works The modernizer analyzes access logs and relational schema from Oracle and DB2 databases, whether they’re powered by mainframes or not. This allows teams to obtain critical insights before kicking off development activities, thereby better informing the process. Additionally, the modernizer combines the implementation of modeling patterns , development best practices such as document sizing (best, average, worst case), and naming conventions, while also providing confidence levels to predict the accuracy of the model it’s suggested. The tool combines Accenture’s deep expertise and lessons learned from numerous successful projects. Our customers are investing in a new approach to managing data: Data as a Service & Data Decoupling. This strategic initiative focuses on consolidating and organizing enterprise data in one place, most often on the cloud, and then making it available to serve digital projects across the enterprise. MongoDB Atlas unlocks data from legacy systems to drive new applications and digital systems, without the need to disrupt existing backends as companies modernize and migrate to the cloud. With this tool and MongoDB capabilities, MongoDB and Accenture allow organizations to get the most out of their data. Find out more about the MongoDB & Accenture partnership here . Learn more about MongoDB’s Modernization Initiative .

January 21, 2021

Connecting MongoDB Stitch to Google Places

One of the services that make available a wealth of data via API, is Google Places . Imagine we want to provide users of our application with information about a business with whom we partner. Insurance companies do this with providers of accommodations, transportation, and healthcare. We don’t want to maintain this information, or own it - rather, we’d prefer to leverage a service that provides this information about these service providers. Google Places is just such a service provider. For this application, we’ll use the following Stitch components to integrate MongoDB with Google Places. Stitch Functions Stitch functions are written in JavaScript ES6 and can be called from our SDKs, Triggers, or Webhooks and are great for coordinating data access or doing light processing alongside a query or insert. Communicating with data provider services such as Google Places is as simple as leveraging an HTTP service within a serverless stitch function: const http = context.services.get("GooglePlaces"); return http .get({url: GooglePlacesSearchURL}) .then(resp=>{ //The response body is encoded as raw BSON.Binary. Parse it to JSON. var search_result = EJSON.parse(resp.body.text()); Stitch’s Functions also let you reference context – such as services, variables, or user information – in order to make it easier to leverage services and information across your entire application. Stitch also provides several third-party services including AWS, Twilio, and Github. Stitch Services The HTTP service that we create here will also have an incoming webhook, meaning that it can make outgoing HTTP requests within Stitch Functions, but also handle incoming HTTP services. Stitch Trigger Stitch Triggers enable reactivity to inserts, updates, deletes, and replaces that occur in the database. In our case, an insert will trigger execution of a function. Figure 1. Trigger Configuration Building Your Application Let’s take a look at how all the pieces of this application fit together – Figure 2. Stitch Architectural Diagram In step 1, an application accepts input either from a user or as a result of some action the user performed (using geofencing, for example.) The input, in our case, will be the name of a business. The application will insert a document with the name of the business into MongoDB. The firing of the trigger is automatic because we configured it to watch for inserts or updates to our database. The trigger executes a custom function called getGooglePlaceInfo then captures and forwards the entire inserted document. Next, in step 4, the function we created invokes the HTTP Webhook we created. The webhook conducts the conversation between Google Places and Stitch. In step 5, Google Places will respond with a JSON document containing the requested information. The function will catch this JSON information and update the MongoDB document. It is worth saying that the function can also manipulate the data before inserting it. Allowing it meet all your project requirements (format, types, calculations). As an example, the function may create a new GeoJSON object from the Google coordinates. All of this is done in step 6. In Conclusion We’ve taken a very brief look at how leveraging MongoDB Atlas, Stitch, and Triggers in conjunction with a data API service such as Google Places transforms applications into intelligent apps users will truly love to use. Because we’re adding data without having to bother the user, the application becomes much more usable, much more valuable. MongoDB Stitch and Triggers give your application the ability to react to changes in the database. Then leverage integration with external services to fetch in-context data to enrich your applications’ data further. This improves both usability and value to the user. Without MongoDB Stitch, a developer would have had to contend with building an application server, dealing with management, availability, scalability, and backup and restoration of the data. Oh, and did we mention that Stitch provides other benefits as well? It leverages Atlas security, adds third-party authentication and granular, field-level access controls to MongoDB data. This gives the ability for users to retrieve data anywhere. Without developers having to create REST APIs from scratch, secure and maintain them? The content described in this blog article is publically available and can be found here: https://github.com/julienmongodb/mongodb-googleplaces

October 9, 2018