October 20, 2021
Over the course of my career, I’ve had the privilege of deploying many different types of software. I’ve shipped CDs. I’ve pushed customer software over the web. I’ve updated database instances and control planes. And I’ve live-updated large, running, mission-critical systems.
I call this a privilege because getting software into the hands of end users is what software engineers love most. But deployments are not all fun and games. And while each deployment presents its own unique challenges, there is one thing they all have in common: fear.
Those of you responsible for significant software deployments know exactly what I’m talking about. You work, you prepare, you test. But when the day finally comes for your software to set sail, you are left hoping and praying it proves seaworthy on the Ocean of Production. In most companies, production is so different from your development and staging environments, that it’s almost impossible to know whether the code that worked in staging is going to succeed in production. Yet one thing is certain: if your software fails, everybody is going to know about it. Hence the fear.
When it comes to understanding the effects of fear on the developer, I think Frank Herbert, author of the epic science-fiction saga Dune, said it best: “Fear is the mind-killer.” Fear undermines experimentation and the entrepreneurial spirit. It discourages risk-taking and leads to bad habits, like avoiding deployment for months. And worst of all, fear slows down the innovation process. (See my post on the Innovation Tax many organizations are paying, and don’t know it.)
Pushing to production is undeniably scary. But over the last 30 years, working with my peers, I’ve developed a few methods for creating the conditions for safe, confident deployments. And my next four blogs in this series will unpack each of them in turn:
· The 180 Rule - Enabling fast, automated, easily reversible deployments
· Z Deployments - Limiting downtime from failed rollbacks
· The Goldilocks Gauge - Making the size and frequency of deployments just right
. Through the Looking Glass - Ensuring alignment between Dev, Stage, and Prod environments
These methodologies aren’t perfect and they won’t guarantee you a bug-free deployment. But they’re the best practices I’ve seen. And they help create a culture of confidence within an engineering team, which is the foundation of meaningful innovation.
To get started, my next blog will explain the “180 Rule” to help you reduce outage minutes in production. In the meantime, feel free to share your own tips and techniques for safe deployments with@MarkLovesTech.
Take Advantage of Low-Latency Innovation with MongoDB Atlas, Realm, and AWS Wavelength
10 Signs Your Data Architecture is Limiting Your Innovation: Part 1
For most businesses, the data layer is usually out of sight and out of mind. But that approach can mask the cause of major challenges facing a business — from slow time to market for new products to spiraling maintenance costs to a difficulty in focusing on innovation. The truth is, all of those issues are often rooted directly in the complexity of your data architecture. Whether you’re working with a cloud migration that has accumulated dozens of components or a legacy infrastructure that has been jerry-rigged to support modern applications, that complexity sucks up your developers’ time and resources, keeps you focused on maintenance, and creates data duplication and integration challenges that eat your budget. This complexity manifests in many different ways; as they accumulate, they can become a serious hindrance on your ability to bring innovative ideas to market. We think of the effect as a kind of tax — a tax that is directly rooted in the complexity of your data architecture. We call it DIRT — the Data and Innovation Recurring Tax. We have identified ten symptoms that can indicate your business is paying DIRT. For an in-depth view, read our white paper 10 Signs Your Data Infrastructure is Holding You Back . Symptom #1: Insights come by the month or week, not by the minute How can you serve your customers if you know nothing about them? In today’s world, insights into your customer and their needs are vital to survive, but real-time insights are what give you the competitive edge to thrive. Often, this seems to necessitate a separate database dedicated to analytics, with difficult-to-maintain ETL pipelines shuttling data between databases. But if you’re trying to match real-time insights with real-time behavior, then slow ETL pipelines put you behind before you’ve even started. And analytics databases often struggle to accommodate semi-structured, unstructured, and geospatial data. Meanwhile, the shape of your data is changing more quickly than your systems can adapt. Many organizations house their analytics in a data warehouse or a data lake. With a data warehouse or data lake, you still need to move data back and forth, introducing latency, rather than working with data where it resides. The whole process is still too slow to allow real-time analytics and power rich application experiences. Our solution: MongoDB’s application data platform solves this problem by allowing you to analyze data directly in the database in real time. Symptom #2: You can't construct a 360-degree view of your customer — or of anyone or anything What retailer wouldn’t want to have all its customer data, from clickstream to transaction history, in one place? What financial institution wouldn’t want a single view of exposure across asset classes, counterparties, and geographies? A single view, also known as a 360-degree view, can enable customer-service agents to be more helpful more quickly, because they have the data they need. A single view makes it more likely that fraud will be detected while it can still be stopped. And a single view makes it easier to comply with General Data Protection Regulation (GDPR), because you can see all your customer data in one place. Building a single view generally requires the integration of different types of data from different databases that don’t communicate. Finding one schema that will work for all the data types is extremely difficult. When you need to add new data, your old schema may not work. Our solution: Because MongoDB’s application data platform is built on the document model, it’s ideally suited to building 360-degree views. Our database supports rich customer objects, and it can accommodate any kind of data, no matter its format. These objects can be further enriched at any stage just by adding fields to a document — no schema migration necessary. For a complete view of DIRT, read our white paper DIRT and the High Cost of Complexity .