1989 results

Starting a Career as a Solutions Architect in MongoDB’s Remote Presales Centre

MongoDB’s Remote Presales Centre is kickstarting presales careers and helping customers unlock the value of MongoDB technology. I spoke with Chris Dowling and Snehal Bhatia to learn more about the Remote Presales Centre Solutions Architect role, how they’re making an impact, and why this is an exciting opportunity for those interested in understanding the intersection of business and technology. Jackie Denner: Hi, Chris and Snehal. Thanks for sitting down with me today to discuss the Remote Presales Centre. What is MongoDB’s Remote Presales Centre team? Chris Dowling: The Remote Presales Centre Solutions Architect is an introductory Solutions Architect (SA) role. Our global team is spread across the Americas, EMEA, and APAC, and we are actively growing. We currently have SAs in EMEA covering French, German, Italian, Spanish, and English speaking customers. By joining the team, you’ll essentially be in an “incubation” period to gain experience in a presales role and exposure to sales cycles. Snehal Bhatia: Yes, this Solutions Architect role is for people who are earlier in their career and might not necessarily come from a presales background. We’re not dedicated to particular customers or accounts, rather we cover a wider perspective to help a larger volume of customers across various regions and Sales teams. Not only do we gain valuable experience, but we’re able to add value to the sales cycle by way of customer education through enablement sessions and workshops, along with engaging with customers at an earlier stage to bring technical value from the get-go. We’re also brought in to help qualify opportunities during discovery meetings. Overall, the biggest gap we see is that customers often have a difficult time understanding MongoDB technology, so we’re there to provide clarity, answer questions, and showcase the value of MongoDB. JD: So, what is a typical week like in your Solutions Architect role? CD: I’ve had 15 customer contacts this week. If you’re looking at strictly one-on-one sessions, the maximum number of customers someone on our team would handle per week is around 20. If you take into account some of the wider marketing events we help run as well, it could be as many as 100 customers, it really depends on the day. We don’t just do account-based activities, we also run wider campaigns like workshops and webinars. Snehal and I also had the opportunity to speak at MongoDB.local London in November 2021 on the topics of read and write concerns and how to set up your database for the tradeoffs you need and how ethical concerns need to be factored into technology and IoT design. We also get the chance to do things outside of core responsibilities and are able to work on side projects if we’d like. For example, I really enjoy management and education so I do a lot with sales reps to help them understand MongoDB technology. We really do a mixture of things. In a typical week, we’ll have one or two webinars, a few security questionnaires which is part of the end of a deal cycle and includes some technical questions that we need to respond to, then we have discovery meetings and prep calls with different reps, and we also have a day dedicated to enablement. SB: Yes, we have all of these customer engagements but the core of it is the prep that comes beforehand. We end up working with Marketing, Sales, Sales Managers, Product Owners, Professional Services - we work with a lot of different teams to get their insight so that we’re able to provide a complete view or solution to the customer. The internal prep meetings are a big part of that execution. JD: Why would someone move from an implementation role into a Remote Presales Centre role? CD: Snehal and I both come from an implementation background. I think you should join the Remote Presales Centre team if you’re interested in the architecture of how businesses are running their systems and want to see how the sales process works. In this role, we’re uncovering the answers to “What is motivating the customer to do this? Why would they buy MongoDB? Does MongoDB work for them?” Every day is different for us. In an implementation role, you end up working on the same system and use cases day in and day out, whereas in our role we get to see everything under the sun of what customers might want to do and get to go in and explore a new piece of technology. It’s exciting to see the newest things in tech. SB: In my previous implementation role the goal was to become an expert on just one of the products, which didn’t really help with broadening my skillset. When I came here, I had the opportunity to work with customers from financial services, telecom, banking, IoT, startups, big enterprises, you name an industry or company size and we’ve done something for them, or you name a technology and we’ve likely worked with it. That variety is not something you’d get in an implementation role. Not to mention, in implementation roles you’re often told what to do. The requirements are already made up and you just have to meet them. In our roles as SAs, we’re really influencing the direction of things and understanding the bigger picture and business implications of utilizing the technology. We have the ability to influence customers in a positive way and provide value. JD: Can you describe the learning curve for someone moving into the Remote Presales Centre from a more delivery-focused role? SB: I would say that the biggest mindset shift is instead of immediately answering questions, you need to stop and ask why. If someone says “We want to do this” your first instinct may be to respond and say “Yes we have the capabilities to meet that”, but really you should stop and ask “Why do you want to do this? What value is it going to bring for you? How is this going to influence your business direction?” You need curiosity to understand what the customer is trying to achieve instead of focusing on solving specific issues and pain points, which is very much the focus in an implementation role. CD: It’s also learning the sales cycle and how sales operates, along with figuring out what drives reps and what they want out of the Remote Presales Centre. Sometimes reps need us to explain the technology and sometimes we’re just there for credibility. It’s getting in the mindset of partnering with sales not working for sales. There is obviously a technology learning curve as well since MongoDB products are vast and often complex. SB: I think that extends to the customers we work with as well. Every call you go into you’ll be meeting with a different “customer persona”. Sometimes you’re talking to very technical people like developers and DBAs, so you need to be able to tailor the conversation as per their priorities. But, if you’re meeting with the CTO, you need to contextualize it in business terms to relay what the business needs. It’s all about understanding your audience and tailoring the conversation. JD: Aside from databases, what other technologies do you need to be familiar with or are you exposed to? SB: Everything! When you think of a database, you will never use a database by itself, you have to build an application on top of it. A lot of our role is understanding how the database is contributing to the whole software development lifecycle and overall project. At the end of the day, it’s a part of the tech stack, so you have to understand the whole tech stack, the underlying infrastructure, and the application that’s built on top of the database. It’s not just MongoDB that we talk or learn about, but it’s every other database in the market and every technology that the customer is working with. Every customer we talk to is working with a different tool, programming language, or software development methodology, and you need to be able to communicate with them. JD: How do you stay connected with your colleagues when you are all working remote? CD: If we’re running a workshop it’s a team event, so we end up working closely for that. We also have weekly syncs where we talk about what we’re working on and talk through challenges, and we have things like enablement sessions and coffee chats. SB: These sessions are also on a global level so we have the opportunity to work with the team in the Americas. Since we operate on a volume basis, we’ll discuss workload distribution and try to prioritize tasks based on people’s interests. CD: Yes, for example, I really like time series and search, so I’ll handle a lot of time series and search requests. There’s someone else on the team who loves Realm, our mobile database, so we give him all the Realm requests. JD: Often people are reluctant to move into presales as they don’t consider themselves sales-oriented. How would you respond to that? CD: Stop thinking of it as sales! Think of it as you get to talk to tons of customers about what they think the best technological solution is, and then you can provide insight into MongoDB and how our technology can improve what they’re trying to do. It’s a really technical job in the sense that you’re looking at organizations’ architectures and you’re figuring out why customers are doing what they do. You get to ask a lot of questions and see a lot of new technology. You could end up building proof of values out of that which means you then get to play around with this new technology. SB: I think presales is the best of both worlds. You get to interact with a lot of people in various scenarios, but you are the trusted advisor for the customer. You’re there to help them and are on their side, which means customers trust and confide in you. JD: What learning and growth opportunities are there for someone on the Remote Presales Centre team? CD: You start off doing simple things like learning about MongoDB products, getting ground knowledge, learning customer stories, and understanding why customers use MongoDB. Then you move on to discovery calls with customers and learning how to scope things out for yourself. From there, as you spend more time in the Service Centre, you slowly get further and further through the deal cycle. For example, a few months ago I was in a workshop to determine the technical feasibility of MongoDB’s solution after we had already worked with the customer to determine business objectives and requirements. You eventually go through the whole sales cycle with the goal being that you can execute the whole sales cycle by the time you leave to go into the field. SB: Since the Service Centre is a somewhat new team for MongoDB, you’re also part of discussing processes and helping determine what makes the team most efficient. You get to contribute to building a whole new team and company right now, which is not something you would get in a mature team with defined processes. CD: As the team grows there are a lot of mentorship opportunities as well. MongoDB is growing so quickly that new sales reps come in and are great at selling, but they don’t always have a technical background or understand MongoDB’s value proposition. We are that technical backup for them, and this allows the field SAs more time to do the really deep technical things that we’ll eventually get to do once we move into a more senior position. JD: Why should someone join your team? CD: You have the opportunity to learn so much about MongoDB’s technology and sales cycle, and you get to meet anyone and everyone. I could be talking to a Product Manager in the morning about the newest release and a Customer Success Manager in the afternoon. You really get to meet the whole organization. You’ll have a lot of internal visibility which is great because it also provides pathways to transfer internally if you want to. SB: You don’t get this visibility in most other roles because you’re usually aligned to a region or team. Here, we get to meet everyone in Europe. Chris and I put together a spreadsheet of all of the sales reps in Europe and there’s only 12 we haven’t had the chance to work with yet. Not only do we get to work with all the reps, but we also work with Product Managers, Customer Success, Marketing, Information Security, plus all of their managers. It’s a great way to get introduced to the company. Interested in a Presales career at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!

January 20, 2022

Optimize Atlas Spending with the Billing Dashboard in Atlas Charts

Managing infrastructure spend across cloud services is a universal challenge for organizations around the world. Teams want to know that their investments in services are driving business value. How much are we spending every month? Where are we spending the most within a given product or service? Are there outliers in our spending we need to take a closer look at? Are there changes that could reduce costs without a negative impact? These are just a few of the many questions you can answer about your Atlas services with the new billing dashboard built on Atlas Charts. Most modern software services give you the basic tools needed to track spending. Information such as: monthly cost, next payment date, billing period, cost by product and/or sub product, past invoice access, and saved payment methods are all common. Atlas itself offers all of these options and more – you can read all about this in our billing page documentation . For digging in even further, that’s where the billing dashboard on Atlas Charts becomes useful. The billing dashboard provides a dedicated space for additional insights into your Atlas spending and it requires minimal setup. If you’re ready to dive in, check out our Github repository for setup instructions, or read on below to learn more about how the dashboard works and how it can help your team find new insights into your Atlas spending. Visualizing your billing data with Atlas Charts The billing dashboard is available as an open source Github project , containing a Realm app to ingest billing data from the Atlas Billing API, an Atlas Charts dashboard to visualize the data, and scripts to help you set this up within your own Atlas organization. If you’re not familiar, Realm is our fully managed solution for edge-to-cloud sync and backend services for quickly building web and mobile apps. Atlas Charts is our native data visualization tool. Charts gives teams the ability to build dashboards from cluster data to quickly answer general questions about your business, to investigate specific questions or issues in your application data, to share dashboards with stakeholders on your team, or even to embed visualizations into your internal or external applications. Take a look at the video below to learn more about setup and see some of the built-in functionality and benefits: The solution comes with a ready-built dashboard that will answer many common questions about your cloud spend. Aggregate metrics such as current monthly spend, your previous month’s spend, and yearly spend provide an overview of your data. Detailed charts break down your projects, clusters, and product categories (i.e. instance, backup, and data transfer) across different time horizons to take your analytics a level deeper. Many Atlas customers further customize charts, and build new charts and dashboards leveraging the same underlying billing data. The dashboard gives you complete flexibility to track the metrics that are most important to your business. For organizations with many projects and clusters inside of Atlas, this flexibility can be invaluable in identifying opportunities to optimize the use of MongoDB. The set up process was recently updated to greatly simplify the steps required to get started. Check out the Github repo for step-by-step instructions. Upleveling your billing insights, for free Gaining additional insight into your Atlas billing will make your team confident that you are doing all you can to best manage your infrastructure spending with MongoDB Atlas. We want you to get the most out of MongoDB, while spending the least! If you need help getting started, feel free to reach out to your customer success manager (CSM). MongoDB’s customer success team works with customers every day to ensure they get the most of the Atlas platform. If you don’t have a CSM and would like to learn more about support at MongoDB, get in touch and we can talk more. Interested in using Atlas Charts for other insights? Get started today by logging into or signing up for MongoDB Atlas , deploying or selecting a cluster, and activating Charts for free.

January 20, 2022

Introducing the MongoDB 5.2 Rapid Release

MongoDB allows you to address a wide variety of data workloads using a single API. Our latest rapid release — MongoDB 5.2 — builds upon this vision with improvements to query ergonomics, enhancements to time series collections (introduced in MongoDB 5.0), scaling, operational resilience, and new capabilities that allow teams to execute more sophisticated analytics in-place. Columnar Compression for Time Series Collections Introduced in MongoDB 5.0, time series collections allow you to easily ingest and work with time series data alongside your operational or transactional data, without the need to integrate a separate single-purpose database into your environment. The 5.2 Rapid Release introduces columnar compression for time series collections in MongoDB. Time series use cases — whether it’s device monitoring, trendspotting, or forecasting — require that new data be inserted into the database for every measurement. In cases where data is being continuously created, the sheer amount of data can be staggering, making it difficult to manage an ever growing storage footprint. To help teams achieve high performance while maintaining resource efficiency, we’ve introduced a few capabilities to time series collections. New columnar compression for time series collections will help teams dramatically reduce their database storage footprint by as much as 70% with best-in-class compression algorithms such as delta, delta-of-delta encoding, simple-8b, run-length encoding, and more. For teams using MongoDB Atlas, Atlas Online Archive support for time series collections (introduced with the 5.1 Rapid Release) allows them to define archiving policies to automatically move aged data out of the database and into lower-cost, fully managed cloud object storage. Better Query Ergonomics and Point in Time Queries for Operational Analytics More efficient queries make developers’ lives easier. With the MongoDB 5.2 Rapid Release, we are introducing new operators and enhancements that will increase productivity, query performance and reduce the number of queries needed to unlock insights. This also allows teams to push more work down to the database, reducing the amount of code developers need to write and maintain while limiting the amount of data that has to be pushed back and manipulated in applications. New accumulators & expression to sort arrays MongoDB 5.2 brings new operators that streamline your queries. The $top and $bottom operators allow you to compute the top and bottom elements of a data set and return related fields within the same query without complex logic. For example, let’s say that you were analyzing sales performance and wanted the top salesperson for every region, including their sales. These new operators can help you retrieve the results in a single dataset, including any additional fields from the original dataset. {$group: { _id: "$region", person: {$top: {output: ["$name", “$sales”], sortBy: {“sales”:1}} }} Result: { {_id:’amer’, person: [‘Daniel LaRousse’, 100000]}, {_id:’emea’, person: [‘John Snow’, 1]}, {_id:’latam’, person: [‘Frida Kahlo’, 99]} } We are also introducing $maxN , $minN , and accumulators such as $firstN , $lastN , which return elements while taking into account the current order of documents in a dataset. A highly requested feature, the new $sortArray expression allows you to sort the elements in an array directly in your aggregation pipeline in an intuitive, optimized way. The input array can be as simple as an array of scalars or as complex as an array of documents with embedded subdocuments. Let’s say you had previously sorted product reviews based on timestamp but now want to sort based on user rating. You can now easily do this using the $sortArray operator to change the sorting criteria with no additional code required. Sorting an array of integers $sortArray: { input: [3, 1, 4, 1, 5, 9], sortBy: 1 } Result: [1, 1, 3, 4, 5, 9] Sorting arrays of documents { "team": [ { "name": "kyle", "age": 28, "address": { "street": "12 Baker St", "city": "London" } }, { "name": "bill", "age": 42, "address": { "street": "12 Blaker St", "city": "Boston" } } ] A simple sort: "name" ascending {$project: { _id: 0, result: { $sortArray: { input: "$team", sortBy: {name: 1} } } } Output: { "result": [ { "name": "bill", "age": 42, "address": { "street": "12 Blaker St", "city": "Boston" } }, { "name": "kyle", "age": 28, "address": { "street": "12 Baker St", "city": "London" } } ] } Long-running snapshot queries now generally available Your applications can now execute complex analytical queries against a globally and transactionally consistent snapshot of your live, operational data. Even as data changes beneath you, MongoDB preserves point-in-time consistency of the query results returned to your users without you having to implement complex reconciliation controls back in your code. The default for long-running snapshot queries in MongoDB Atlas is 5 minutes but can be changed with the help of our support team. Queries can span multiple shards, unlocking analytics against large, distributed data sets. By routing long-running queries to secondaries, you can isolate analytics from transactional queries with both workloads served by the same cluster, avoiding slow, complex, and expensive ETL to data warehouses. Query results can be returned directly to the application or cached in a materialized view, providing your users with low latency access to deep analytics. Typical uses include end-of-day reconciliation and reporting, along with ad-hoc data exploration and mining. All of these use-cases can now be served directly from your transactional data layer, dramatically simplifying the data infrastructure you need to serve multiple classes of workloads. Improving Resilience with Faster Initial Sync via File Copy Initial sync is how a replica set member in MongoDB loads a full copy of data from an existing member. This process occurs when users are adding new nodes to replica sets to improve resilience, or to reduce read latency or improve read scalability with secondary reads. Initial sync is also commonly used to recover replica set members that have fallen too far behind the other members in a cluster. Prior to 5.2, logical initial sync was the only option available for performing an initial sync. With logical initial sync, every collection in the source node is scanned and all documents are then inserted into matching collections in the target node (with indexes being built at the time of document insertion). However, users and customers leveraging logical initial sync, especially those trying to synchronize large data sizes, have reported frustratingly long initial sync times. Starting with the 5.2 Rapid Release, we have added the option of initial sync via file copy to significantly improve the performance of initial syncs. With this method, MongoDB will copy files from the file system of the source node to the file system of the target node. This process can be faster than a logical initial sync, especially at larger data sizes. In our testing with a 630 GB dataset, initial sync via file copy was nearly four times (4X) faster than a logical initial sync on the same dataset. This new capability builds upon the continuous enhancements we’ve made to improve resilience and scalability, including the ability for initial sync to automatically resume after a network failure, and allowing users to specify their preferred initial sync source – both introduced with MongoDB 4.4. For more information, see the documentation on initial sync . Enhanced Developer Experience with MongoDB Analyzer for .NET And finally, we’re pleased to announce the release of the MongoDB Analyzer for .NET , which enables C# developers to more easily troubleshoot queries and aggregations, and prevent errors from cropping up at runtime. The MongoDB Analyzer builds on earlier releases of the MongoDB .NET driver. It makes it easier and faster for developers to use MongoDB with C#, including a fully redesigned LINQ interface. Previously, C# developers were able to interact with MongoDB idiomatically using Builders or LINQ expressions, but there was no easy way to see before running their code if those mapped correctly to the MongoDB Query API. Downloadable as a NuGet package, the MongoDB Analyzer allows developers to easily see if their queries and aggregations correspond to expressions supported by the Query API. By surfacing unsupported expressions during code development, the MongoDB Analyzer ultimately improves developer productivity and reduces the pain of debugging. Getting Started with MongoDB 5.2 MongoDB 5.2 is available now. If you are running Atlas Serverless instances or have opted in to receive Rapid Releases in your dedicated Atlas cluster, then your deployment will be automatically updated to 5.2 starting today. For a short period after upgrade, the Feature Compatibility Version (FCV) will be set to 5.1; certain 5.2 features will not be available until we increment the FCV. MongoDB 5.2 is also available as a Development Release for evaluation purposes only from the MongoDB Download Center. Consistent with our new release cadence announced last year, the functionality available in 5.2 and the subsequent Rapid Releases will all roll up into MongoDB 6.0, our next Major Release scheduled for delivery later this year. Safe Harbour Statement The development, release, and timing of any features or functionality described for our products remains at our sole discretion. This information is merely intended to outline our general product direction and it should not be relied on in making a purchasing decision nor is this a commitment, promise or legal obligation to deliver any material, code, or functionality.

January 19, 2022

Utilizing AI and MongoDB to Power Content Personalization

Content is everywhere. Whatever it is a consumer is looking for, and whatever industry that person might be in, it’s not hard to find content. The problem, however, is trying to find the right content. That’s where Concured comes into play. Concured , an AI-startup based in Montreal, helps marketing teams align their website and sales content to audiences, as well as content marketing teams who need to differentiate and accelerate insight-driven content personalization. Concured was founded in 2015 by CEO Tom Salvat and built for content marketers to better understand their audience's interests in order to deliver more impactful content. Built with MongoDB spoke with CTO Tom Wilson , who joined Concured roughly a year after it was founded. We discussed Concured’s use of artificial intelligence, how Wilson joined Concured, as well as what he sees as the future for the company. Built with MongoDB: What does Concured do? Tom Wilson: Concured is a software company that leverages artificial intelligence techniques developed in the last five to 10 years. It is designed to help marketers know what to write about on a per-topic basis, to see what is working well from their own content, as well as that of their competitors, and within their industry. Finally, it maximizes the return on investment they make on any content that they create by personalizing the web visitor’s journey through the client’s website. Concured has developed a recommender system, which is personalized to the individual visitor. It is a privacy friendly approach that doesn’t use third-party cookies or spy on the user, it is purely based on the web visitor’s behavior on the site, and it builds up an interest profile on that visitor as they click through successive web pages. As it builds a more precise picture of the interests and intent of the user, it tries to recommend content to them to read next, whether it’s a blog post, a product description, or any other kind of content. Built with MongoDB: Built with MongoDB: You mentioned artificial intelligence. How does Concured use artificial intelligence behind the scenes? Wilson: We use artificial intelligence in a number of places. One of our unique selling propositions to our clients, is that, unlike other personalized systems, Concured doesn’t require a lengthy integration period, nor does it require ongoing maintenance on the part of the domain. Our approach is to scrape the content of the clients’ websites using AI powered bots to find the content that is relevant and to extract the text, the title, and any other relevant metadata, and to index that in an automatic way. Our system leverages recent advances in natural language processing (NLP) in order to generate semantic metadata for each document, corresponding to a unique point within a multi-dimensional space. Another aspect is to understand the key entities that are in it, and also to understand the relationship of that particular article to the other ones within the same website. We create a lot of metadata automatically on each piece of content that we find using AI powered web crawlers and scrapers. Built with MongoDB: Since AI isn’t always 100% accurate, what is the accuracy for the NLP that you’ve created at Concured? Wilson: With recommender systems, it’s very hard to say what the best recommendation is, because it could be very different for the same person depending on the day, or the web session. If you think of some of the most famous recommender systems, such as Netflix, Amazon, or Spotify, they try to show us what we want to see next, but there’s actually no single right answer. Because of that, it’s very hard to measure the performance, so the approach that we use is not to say that there is a 100% correct answer, but rather, to say, if we make changes to the algorithms, do the visitors on these websites click on more articles, and do they reach the target pages defined by the website’s owner, e.g. a product page or a sign-up form. The higher proportion of people performing that action at the end of the journey on the website relative to the number of the people who arrived on the website, the more successful the recommender system is, and we can compare the success rate that our clients have on their websites before and after they activate the personalization system from Concured. So far we’re looking at a two to three times uplift, and the algorithms are improving all the time. Built with MongoDB: When did you join the team at Concured? Wilson: At a time when the company had raised its first serious money from external investors, and one of the requirements was that they brought on a professional CTO, this often happens in early stage companies, the investors want to impose some structure, they want to know that their money is going to be spent wisely, and do things a little less shooting from the hip. And so, in some companies they joke about bringing in adult supervision. I don’t know if I’d say that about my role, since the team was already nicely established, but I was able to provide a lot more structure to ensure that we would meet our next milestones, as well as longer-term strategic planning and a technical vision. Built with MongoDB: How did your team decide to build with MongoDB? Wilson: The team that I joined was already using MongoDB at the time. Within a few months of joining, there was some discussion about whether to move to a structured database. That was a decision that had to be made, so that’s where I got involved and it became a conscious decision not to move away from MongoDB. This was the right fit for what we wanted going forward, and we absolutely made the right decision. We are also going to move away from our Community edition hosted on Google Cloud Platform to MongoDB Atlas Serverless. We’ll be happy not to manage machines any more, thanks to the serverless aspect, and we’re also excited to try out the text search features available on Atlas, since this could potentially simplify our tech stack For where we are, as a business today, and where we want to be in five years, MongoDB is and will continue to be the right choice. Built with MongoDB: What does the future of Concured look like? Wilson: The future is being written as we speak. It’s bringing on more clients with similar needs to those of our largest clients at the moment, namely enterprises that have a huge amount of content, already in the archives, that they would like to continue to squeeze value out of, as well as publishing a lot; whether it’s big companies, such as consultancies or financial services industries, or traditional publishers, you want to make sure that they’re promoting the right content that’s going to have the biggest uplift in terms of whatever KPIs they’re measuring. Built with MongoDB: What is the best piece of feedback that you’ve received? Wilson: One nice piece of feedback I’ve received from my team is that I’ve always been there for them. If they have a problem, I will either fix it or remove obstacles for them so they can do the best that they can. It’s part of my philosophy that if you take care of the team, a lot of other things will take care of themselves. For any business that invests in content as part of its marketing strategy, it makes only good business sense to try to maximize the return on that. Learn more about how to turn readers into customers via Content Personalization on Concured’s website . Interested in learning more about MongoDB for Startups? Learn more about us here .

January 19, 2022

Manufacturing at Scale: MongoDB & IIoT

In recent years, we’ve seen a massive shift in digital transformation. As people, we’re all “connected”, by our smart devices, smart homes, smart cars, smart cities, and so on. We interact with smart devices because of the convenience it offers us- automating daily tasks and giving insight into daily movements, from how much pressure is in each car tire to whether we left our stove on before leaving the house. The reasons we use smart devices is mirrored in why businesses are adopting IoT and IIoT (Industrial IoT) on a much larger scale- for convenience, insight, predictive maintenance, automation, and productive efficiency. IoT is becoming increasingly more critical in manufacturing and engineering, connecting thousands of sensors and actors of devices in the processes before, during, and after fabrication. The implementation of IoT within manufacturing processes, from raw materials to the product or smart products has only just begun and is destined to evolve into a key differentiator for successful manufacturing companies throughout the entire supply chain. The digital transformation in IIoT comes down to data at its core and how data is generated, stored and analyzed. IIoT requires data to be collected and processed at massive volumes in real/ near real time to provide accurate and live business insights for better decision making. Shop floors are continuously optimized as new components, sensors and actors are introduced to improve OEE (Overall Equipment Effectiveness), increase quality and reduce waste. With almost every new device, additional data variety is introduced and thus requires a flexible, highly available and scalable data platform to store and analyze this data. Furthermore, with the increasing convergence of IT and OT, even more complexity and diverse data needs to be integrated and processed, which adds higher complexity to the picture. MongoDB’s general purpose data platform, allows manufacturers to store OT / time series data sets in MongoDB together with recipes or digital twins for a complete real time end-to-end picture from edge to cloud and onto mobile devices for insights and control anytime and anywhere, online or offline. A connected factory model The Industry Solutions team at MongoDB set out to demonstrate how easily MongoDB can be integrated to solve the digital transformation challenges of IIoT in manufacturing with its flexible, scalable, application data platform. Using the small scale model of a smart fabrication factory, from Fischertechnik , the team collects and sends data via MQTT and processes it in MongoDB Atlas and Realm . Similar to a full scale physical factory, the smart factory model demonstrates how easily IIoT use cases can be built on top of MongoDB’s application data platform to enable and accelerate digitalization of manufacturing processes in any industry. The Fischertechnik model factory itself is often used to train engineering students in the field of what a manufacturing fabrication would look like, as well as a model for manufacturing companies to plan for the very real setup, building, and investment of their factories . So, what initially looks like a toy in robotics gets serious quite quickly. The model factory operates as the foundation of an IIoT use case. It is made up of several components- a warehouse, multiprocessing station, and sorting area. The warehouse is where raw material is stacked and stored, and when triggered, the raw material is retrieved and moved to processing by a mobile crane. From there, the items are sorted by color (i.e. red, white, or blue), to be sent to the correct outbound destination. The process covers ordering and storing of raw material to ordering and manufacturing of end products. Throughout these processes, there are multiple sensors detecting the type and color of the items, as well as environmental aspects like temperature and how much inventory is in stock. A surveillance camera detects motion and sends alerts including photos via MQTT. This simulates the wide variety of data a smart factory would emit in real time for track and trace, monitoring and visualization, alerts and as input for machine learning algorithms. The factory's infrastructure Out of the box, the Fischertechnik factory comes with a few dashboards connected to the Fischertechnik cloud, established via a WLAN router integrated in the factory. These dashboards include a: Customer View: A webshop interface, where a product can be ordered to trigger the supply chain processing Supplier View: A visualization and display of the ordering process of raw material Production View: A visualization of the factory status, production process, and sensor values from the camera and NFC/RFID readers. To emphasize and explain how MongoDB can be leveraged in this picture, the MongoDB team developed additional apps, using JavaScript, ReactJS, and Realm, to integrate and streamline data flows and processes on top of the MongoDB data platform. This included a: MongoDB Realm Order Portal: A ReactJS web application to order new products and track the process of orders. Data Visualization: A visualization of the different data types collected in MongoDB and visualized via MongoDB Charts for insights. Alert Management App: A mobile app leveraging MongoDB Realm and Realm Sync for alert notification and management offline and online. The machines of the factory are controlled by TXT controllers, Linux-based computers which use MQTT to communicate between each other and also with the cloud based applications. There are basically two types of data sent and received via MQTT- commands to trigger an action and streaming of event and time series sensor data. The main TXT controller runs a MQTT broker and replicates selected topics to a HiveMQ MQTT broker in the HiveMQ cloud. From there a redpanda kafka container collects the data streams and inserts them into MongoDB. The data persisted in MongoDB is then visualized via MongoDB Charts for real-time insights. Factory layout connected to data infrastructure The MongoDB Order Portal uses the Realm Web SDK and the serverless GraphQL API. GraphQL is used to pull data from MongoDB Atlas and the web SDK is used to add new orders (insert new documents) into a MongoDB cluster. When a new order is inserted into the Atlas database, an Atlas trigger is executed, which then sends a MQTT message directly to the HiveMQ MQTT broker, alerting the factory to process the order. The HiveMQ broker then replicates the order to the factory for processing. Sending data to the factory Receiving data from the factory is just as simple. The Factory provides a large amount of live data that can be streamed from the factory. In order to receive the data, HiveMQ and Kafka are used. The factory has an MQTT broker, which is bridged to a cloud HiveMQ broker. From the HiveMQ broker Kafka Connect with an MQTT source and a MongoDB sink connector the data is moved into MongoDB Atlas. Receiving data from the factory MongoDB & IIoT Digitalization in manufacturing means connecting IT and OT, mixing and meshing data from both domains and providing access to people and algorithms for higher levels of automation, increased efficiency and less waste. MongoDB’s application data platform is the data platform optimized for large varieties and amounts of data with a powerful query language for better decision making across a large volume of data. All easier said than done. However, Atlas helps solve these complex requirements with its ecosystem of functions, including: Real Time Analytics: As IIoT continues to boom with a surge of connected devices, limits are pushed each day with increased volumes of data. Atlas scales seamlessly, capable of ingesting enormous amounts of sensor and event data to support real time analysis for catching any critical events or changes as they happen. Dynamic Scalability: MongoDB Atlas and Realm provide automated scalability allowing you to start small and dynamically adapt your clusters with increasing/decreasing demand. Especially as sensor data gets colder over time, you can automatically offload cold data into object stores, such as S3, while maintaining the ability to query the hot and cold data through a single API. Time-Series: MongoDB 5.0 supports Time-Series Data natively through optimized storage with clustered indexes and optimized Time-Series query operators to analyze trends and identify anomalies quickly. The combination of time series data with other data structures such as digital twin models within the same data platform dramatically reduces complexity, development efforts and costs by avoiding additional technologies, ETL processes and data duplication. The MongoDB database can also be deployed next to the shop floor for data collection and analysis, making the shopfloor independent of the cloud. Pre Aggregated or raw data can then be seamlessly replicated or streamed into the public cloud for global views across factories. Additionally Realm, the serverless backend on top of MongoDB Atlas provides easy application and system integrations through REST / MongoDB Data and GraphQL APIs as well as synchronizing data with mobile devices for offline first use cases such as workforce enablement use cases. Atlas, Realm, and IIoT IIOT is an exciting realm (no pun intended) right now, with a massive opportunity for growth and innovation. The next level of innovation requires a resilient multi-functional data platform that reduces complexity, increases developer efficiency and reduces data duplication/integration while scaling elastically with your demand. What the MongoDB team scratched by quickly syncing the smart model factory with Atlas and Realm and iterating on top of that is just a fraction of the innovation we can support within manufacturing use cases. Learn more MongoDB Atlas and Realm, and how major enterprises are using these solutions for their manufacturing and IIoT needs here . This is the first of an IIoT series from MongoDB’s Industry Solutions team. Stay tuned for more to come!

January 19, 2022

Revolutionizing Data Storage and Analytics with MongoDB Atlas on Google Cloud and HCL

Every organization requires data they can trust—and access—regardless of its format, size, or location. The rapid pace of change in technology and the shift towards cloud computing is revolutionizing how companies handle, govern and manage their data by freeing them from the heavy operational burden of on-premise deployments. Enterprises are looking for a centralized, cost-effective solution that allows them to scale their storage and analytics so they can ingest data and perform artificial intelligence (AI) and machine learning (ML) operations, ultimately expanding their marketing horizon. This blog post explores why companies should partner with MongoDB Atlas on Google Cloud to begin their data revolution journey, and how HCL Technologies can support customers looking to migrate. MongoDB Atlas as the distributed data platform MongoDB Atlas is the leading database-as-a-service on the market for three main reasons: Unparalleled developer experience - allows organizations to bring new features to market at a high velocity Horizontal scalability - supports hundreds of terabytes of data with sub-second queries Flexibility - stores data to meet various regulatory, operational, and high availability requirements. The versatility offered by MongoDB’s document model makes it ideal for modern data-driven use cases that require support for structured, semi-structured, and unstructured content all within a single platform. Its flexible schema allows changes to support new application features without costly schema migrations typically required with relational databases. MongoDB Atlas extends the core database by offering services like Atlas Search and MongoDB Realm that are a necessity for modern applications. Atlas Search provides a powerful Apache Lucene-based full text search engine that automatically indexes data in your MongoDB database without the need for a separate dedicated search engine or error-prone replication processes. Realm provides edge-to-cloud sync and backend services to accelerate and simplify mobile and web development. Atlas’ distributed architecture supports horizontal scaling for data volume, query latency, and query throughput which offers the scalability benefits of distributed data storage alongside the rich functionality of a fully-featured general purpose database. MongoDB Atlas is unique in its ability to provide the most wanted database as a managed service and is relied on by the world’s largest companies for their mission-critical production applications. Innovation powered by collaboration with HCL Technologies MongoDB’s versatility as a general-purpose database, in addition to its massive scalability, makes it a perfect foundation for analytics, visualization, and AI/ML applications on Google Cloud. As an MSP partner for Google Cloud, HCL Technologies helps enterprises accelerate and risk-mitigate their digital agenda, powered by Google Cloud. We’ve successfully implemented applications leveraging MongoDB Atlas on Google Cloud, building upon MongoDB’s flexible JSON-like data model, rich querying and indexing, and elastic scalability in conjunction with Google Cloud’s class-leading cloud infrastructure, data analytics, and machine learning capabilities. HCL is working with some of the world’s largest enterprises in building secure, performant, and cost-effective solutions with MongoDB and Google. Possessing technical expertise in Google Cloud, MongoDB, machine learning, and data science, our dedicated team developed a reference architecture that ensures high performance and scalability. This is simplified by MongoDB Atlas’ support for Google Cloud services which allows it to essentially operate as a cloud-native solution. Highlighted features include: Integration with Google Cloud Key Management Service Use of Google Cloud’s native storage snapshot for fast backup and restore Ability to create read-only MongoDB nodes in Google Cloud to reduce latency with Google Cloud-native services regardless of where the primary node is located (even other public cloud providers!) Integrated billing with Google Cloud Ability to span a single MongoDB cluster across Google Cloud regions worldwide, and more As represented in Figure 1 below, MongoDB Atlas on Google Cloud can be used as a single database solution for transactional, operational, and analytical workloads across a variety of use cases. Figure 1: MongoDB's core characteristics and features The following architecture in Figure 2 demonstrates the ease of reading and writing data to MongoDB from Google Cloud services. Dataflow, Cloud Data Fusion, and Dataproc can be leveraged to build data pipelines to migrate data from heterogeneous databases to MongoDB and to feed data to create interactive dashboards using Looker. These data pipelines support both batch and real-time ingestion workloads and can be automated and orchestrated using Google Cloud - native services.. Figure 2: MongoDB Atlas' integration with core Google Cloud services A data platform built using MongoDB Atlas and Google Cloud offers an integrated suite of services for storage, analysis, and visualization. Address your business challenges with HCL: Industry use cases Data-driven solutions built with MongoDB Atlas on Google Cloud have multiple applications across industries such as financial services, media and entertainment, healthcare, oil and gas, energy, manufacturing, retail, and the public sector. Every industry can benefit from this highly integrated storage and analytical solution. Use Cases and Benefits Data lake modernization with low cost and high availability for media and entertainment customers: Maintaining high availability and a low-cost data lake is an obstacle for any online entertainment platform that builds mobile or web ticketing applications. However, building on Google App Engine with MongoDB Atlas Clusters in the backend allows for a high-availability, low-cost data platform that seamlessly feeds data to downstream analytics platforms in real time. Unified data platform for retail customers: The retail business frequently requests an agile environment in order to encourage innovation among its engineers. With its agility in scaling and resource management, seamless multi-region clusters, and premium monitoring, running MongoDB Atlas on Google Cloud is a fantastic choice for building a single data platform. This simplifies the management of different data platforms and allows developers to focus on new ideas. High-speed real-time data platform of supply chain system for manufacturing units: By having real-time visibility and distributed data services, supply chain data can become a competitive advantage. MongoDB Atlas on Google Cloud provides a solid foundation for creating distributed data services with a unified, easy-to-maintain architecture. The unrivaled speed of MongoDB Atlas simplifies supply chain operations with real-time data analytics. The way forward Even in just the past decade, organizations have been forced to adapt to the extremely fast pace of innovation in the data analytics landscape: moving from batch to real-time, on-premise to cloud, gigabytes to petabytes, and the increased accessibility of advanced AI/ML models thanks to providers like Google Cloud. With our track record of success in this domain, HCL Technologies is uniquely positioned to help organizations realize the joint benefits of building data analytics applications with best-of-breed solutions from Google Cloud and MongoDB. Visit us to learn more about the HCL Google Ecosystem Business Unit and how we can help you harness the power of MongoDB Atlas and Google Cloud Platform to change the way you store and analyze your data through these solutions.

January 13, 2022

Retail Tech in 2022: Predictions for What's on the Horizon

If 2020 and 2021 were all about adjusting to the Covid-19 pandemic, 2022 will be about finding a way to be successful in this “new normal”. So what should retailers expect in the upcoming year, and where should you consider making new retail technology investments? Omnichannel is still going strong Who would have anticipated the Covid-19 pandemic would still be disrupting lives after two years? For the retail industry this means more of the same - omnichannel shopping. Despite the hope many of us had for the end of the pandemic and the gradual increase of in-person shopping, retail workers can expect to continue accommodating all kinds of shopping experiences – online shopping, brick and mortar shopping, buy online and pick up in store, reserve online and pick up in store. Even beyond the pandemic, the face of shopping is likely forever changed. This means retailers need to start considering the long-term tech investments required to meet transforming customer expectations. Adopting solutions that offer a single view of the consumer gives you the unique opportunity to personalize offerings, products and loyalty programs to their demand. With a superior consumer experience, you can achieve repeat business and increased customer loyalty. While many retailers may have thought they could “get by” with their current solutions until the pandemic ends, it’s time to rethink that approach and start exploring more long-term solutions to improve omnichannel shopping experiences. Leaner tech stacks over many specialized solutions In 2022, you should explore solutions that allow your IT teams to do more with less. The typical retail tech stack looks something like the diagram below. Legacy, relational databases are supplemented by other specialist NoSQL and relational databases, and additional mobile data and analytics platforms. As a result, retailers looking to respond quickly to changing consumer preferences and improve the customer experience face an uphill battle against siloed data, slow data processing, and unnecessary complexity. Your development teams are so busy cobbling solutions together and maintaining different technologies at once that they fail to innovate to their full potential, so you’re never quite able to pull ahead of the competition. This is the data innovation recurring tax (or DIRT) . Think of this as the ongoing tax on innovation that spaghetti architectures, like the example above, legacy architecture costs your business. As technology grows more sophisticated and data grows more complex, companies are expected to react almost instantaneously to signals from their data. Legacy technologies, like relational databases, are rigid, inefficient, and hard to adapt, making it difficult to deliver true innovation to your customers and employees in a timely manner. Your development teams are so busy cobbling solutions together that they fail to innovate to their full potential, so you’re never quite able to pull ahead of the competition. It’s time to rethink your legacy systems, and adopt solutions that streamline operations and seamlessly share data to ensure you’re working with a single source of data truth. Many retailers recognize the need to upgrade legacy solutions and get away from multiple different database technologies, but you may not know where to start. Look for modern data applications that simplify data collection from disparate sources and include automated conflict resolution for added data reliability. Also, consider what you could do with fully managed application data platforms, like MongoDB Atlas . With someone else doing the admin work, your developers are free to focus on critical work or turn their talents to innovation. Digital worker enablement will increase retention For employees, 2022 looks set to continue last year’s trend of the “ Great Resignation ”. To combat worker fatigue, and retain your workforce you need to prioritize worker engagement. One way to better engage your employees is through mobile workforce enablement. While many companies consider how to engage their customers with a more digital-friendly work environment, you shouldn’t forget about your workers in the process. Global companies like Walmart are starting to invest in mobile apps to enable their workforce. A modern, always-on retail workforce enablement app could transform the way your employees do their jobs. Features like real-time view of stock, cross-departmental collaboration, detailed product information, instant communication with other stores can simplify your workers’ experiences and help them to better serve your customers. Your workers need an always-on app that syncs with your single source of data truth, regardless of connectivity (which may be an issue as retail workers are constantly on the move). But building a mobile app with data sync capabilities can be a costly and time-intensive investment. MongoDB Realm Sync solves for this with an intuitive, object-oriented data model that is simple to use, and an out-of-the-box data synchronization service. When your mobile data seamlessly integrates with back-end systems, you can deliver a modern, distributed application data platform to your workers. Huge investment in the supply chain From microchips to toilet paper, disruptions in the supply chain were a huge issue in 2020 and 2021, and the supply chain pain continues in 2022. And while there continue to be supply chain issues beyond the control of retailers, there are steps that can be taken to mitigate some of the pain and prepare for future disruptions. Warehouse tech is getting smarter, and you need to upgrade your solutions to keep up. For starters, consider adopting the right application data platform to unify siloed data and gain a single view of operations . A single view of your data will allow for better management of store-level demand forecasts, distribution center-to-store network optimizations, vendor ordering, truck load optimizations, and much more. With a modern application data platform, all this data feeds into one, single view application, giving retailers the insights to react to supply chain issues in real time. With disruption set to dominate 2022, as it did in 2020 and 2021, investing in proactive solution upgrades could help your business not only survive, but thrive. Want to learn more about gaining a competitive advantage in the retail industry? Get this free white paper on retail modernization .

January 13, 2022

Ventana Research's Latest Report Highlights MongoDB's Role as a Cloud Data Platform Provider

Ventana Research, a market advisory and research firm, recently published an Analyst Perspective on MongoDB, noting that MongoDB and its application data platform provide businesses the ability to accelerate development and data-driven decision-making. As Ventana Research explains the evolution from traditional databases to modern, cloud-based application data platforms, the study covered multiple trends related to both the present and future of data platform software. We have identified six key trends from MongoDB that were represented in the Ventana Research Analyst Perspective. Non-relational, or NoSQL, databases are on the rise . We see this as evidence of an unprecedented, widespread change in how businesses perceive and use their databases. Cloud-based services and products are rapidly gaining popularity . Given the rise of real-time, data-driven applications, organizations are relying more and more on the flexibility, availability, and functionality of cloud-native data platforms. Such products are ideal for quickly building competitive products, delivering highly personalized experiences, and improving business agility. As a result, operational database requirements will only become more demanding . As applications become more advanced, databases will become a pivotal part of an organization’s success — or failure. We believe that in order to keep up with their applications (and their competition), companies require a comprehensive, powerful application data platform like MongoDB Atlas. Convergence is the name of the game . As companies seek out new and better operational data platforms, both relational and non-relational database providers will venture into areas that were traditionally dominated by their competitors. Examples include non-relational databases (like MongoDB) adding relational features like ACID transactions, or relational databases offering compatibility for non-relational data models like graphs or documents. Companies are increasingly opting for hybrid and multi-cloud models . MongoDB Atlas’ multi-cloud clusters enable users to leverage exclusive provider features (like Google Cloud’s AI tools), improve availability in geographic regions, or migrate data across clouds with no downtime. Non-relational, cloud-native databases are becoming more powerful — and more attractive to customers . Thanks to convergence and competition, non-relational databases are becoming ever more capable. Their advancements include real-time analytics, rich visualizations, and mobile data sync and storage. Read Ventana Research Analyst Perspectives to gain insight into the current data landscape and the possibilities of tomorrow. Updated January 17, 2022.

January 12, 2022

Safe Software Deployments: Through the Looking Glass

We’ve covered a lot of ground in this Safe Software Deployment series, from the 180 Rule to Z Deployments to the Goldilocks Gauge. But there is an elephant in the room. Or should I say, a jabberwock. In Lewis Carroll’s novel Through the Looking Glass , Alice discovers that the mirror above her mantle is not a mirror at all, but a doorway to another world in which things work very differently. When developers push software from staging to production, they often have a similar experience. Though they want to believe that staging and production are the same, they discover that staging is not a mirror at all, and production is another world, in which things work very differently. And out of that distortion come bugs and outages. The bottom line is this: Staging ≠ Production. And it never will. There are simply too many variables between these two environments to ever achieve exact alignment. Those environments can be different in hardware: CPU cores, threads per core, cache size, microcode; bus architectures; memory size; firmware. Or different in software or configuration: OS versions; compilers; libraries; network traffic profiles. Or different in network topology, edge caching; DNS and directory services. And of course we know that no matter how diligent you test in staging, customer workloads exercise the software in different ways. But the major reason they are different is because both environments have had a different set of software deployed to them over time, with a different set of configuration parameters - and a different combination of patches, hacks, and rollbacks. That staging is a mirror of production is one of the great delusions of software development. Developers often tell this lie to themselves, to overcome their fear of pushing to prod. Worse, developers often know the truth, but don’t really know how to explain this ambiguity to their management chain, leading to inevitable trust issues when deployments fail. So what can we do about it? First, accept reality. Modern, distributed software systems are nonlinear, and all test environments are simulacrums. It’s particularly important to help managers understand that even if it were possible to create exact duplicates of production – which it’s not – it would be practically and financially unjustifiable. Second, approach testing like an actuary. The leap from staging to production is essentially an exercise in probability. You should know your architecture, operational characteristics, and costs well enough to prioritize tests and reduce risk. You may even want to create two or more test environments that are deliberately different to reduce the odds of failure. And you should continue to run tests after the release, so you can surface bugs before your customers do. Third, if you can, treat both production and staging like cattle, not pets. If you have an enlightened software organization, one that believes in best practices, set up your systems so that you can blow away and recreate both your production and staging environments at regular intervals. This will reset many of the deviations and environment drift that build up over time. Finally, you have to be able to do automated rollbacks (the 180 Rule ) which work reliably ( Z Deployments ), and that are the right size for optimum efficiency and safety (the Goldilocks Gauge . ;-) I saved this column for last because completely eliminating the differences between staging and production is not a solvable problem. And frankly, you shouldn’t even try. But you don’t want to get caught flat-footed either, so you need a system of best practices that greatly reduces risk and fosters confidence. In other words, a system of Safe Software Deployment that helps you overcome the fear of pushing to prod. And most importantly, everyone in your organization needs to have a common understanding of the problem, from the top down. So feel free to print this post out, slide it under the door of your manager, and slink away like that Cheshire Cat. Have another technique for managing the divergence between staging and production? Share it with me at @MarkLovesTech .

January 11, 2022