The concept of maintenance windows contradicts modern software development. Maintenance windows can mean downtime, downtime leads to disappointed customers. Embracing a maintenance-free approach not only respects developers’ time and effort but also paves the way for a more agile, efficient, and innovative future. As we say goodbye to the era of interruptions, let’s welcome a new dawn of uninterrupted, continuous development on serverless platforms.
Developers want a seamless digital experience for their customers. Maintenance windows typically are during “low traffic” times. You can schedule as an engineering team, but what if you have a new game live and you have a set of users online during your “low traffic” hours reporting high latencies? Overall, as a developer, you don’t want downtime, and planning your maintenance windows creates high cost of ownership within your engineering team. The best version of the service you are implementing in your solutions should be running.
Diving deeper into maintenance windows and caching solutions
To create high availability and solve scalability problems for spiky workloads during peak events, caching is often introduced. Now, caching isn’t always the answer, and I highly recommend reading Meera Jindal’s “Think before you cache” blog on how to build your best solution possible. More often than not though, caching services with maintenance windows are implemented such as Amazon ElastiCache and Redis to solve high latencies for peak events. These are household names for developers, but even as these services become incrementally more reliable, the concept of maintenance windows continues to linger. This makes me wonder, do we really need maintenance windows?
If you’re lucky, you may be wondering, what is a maintenance window? A maintenance window refers to a specific period of time when planned maintenance activities or system updates are carried out on a computer system, network, software application, or website. These activities can include software patches, security updates, hardware upgrades, configuration changes, or other maintenance tasks that are essential for the proper functioning, security, and performance of the system. Maintenance windows are scheduled during times when the impact on users or business operations is expected to be minimal. This often means selecting periods when the system experiences the lowest usage or traffic, typically during non-business hours or low-traffic periods, such as late at night or on weekends. During a maintenance window, the system or service may be temporarily unavailable or experience disruptions. Proper communication and coordination with stakeholders, such as users, customers, or employees, are essential to minimize any inconvenience caused by the maintenance activities. You can learn about Amazon ElastiCache’s maintenance window policies here and Redis’ here.
If you’re like me and work for a multi-regional/global company, you are probably already thinking, we don’t have “down times.” For me personally, what may be a low traffic hour in Green Bay is peak in Japan where we have gaming customers at Momento. Global development teams are often collaborating in real-time to ensure round-the-clock productivity. Collaborative development demands a seamless, asynchronous workflow, allowing developers to contribute at their peak productivity, irrespective of time zones or maintenance schedules.
So if I am using a traditional caching service like Elasticache or Redis, not only would the development team be taking time to plan and diverting their attention from solving complex coding issues to the logistics of maintenance planning, we could have down time for our customers. This is a huge hidden expense.
The Way Forward: Maintenance-Window-Free Development
Services like AWS DynamoDB and S3, and でキャッシング・インフラの将来を保証する have abstracted away maintenance windows completely. They deploy just as often, but they completely abstract away these deployments to the point where they are seamless and unobservable. As such, customers don’t even notice when their system gets updated – and they do not need to plan around it. A simple litmus test I like to confront developers with consists of two questions: “What version of ElastiCache Redis are you using” answer is typically 5,6, or 7. And then I immediately follow up with, “And what version of DynamoDB are you on?” Silence ensues – and the point lands: you have no idea what version of DynamoDB you are running on – because you are on the latest version and you did not need a maintenance window to get there.
If you are looking for a caching service that scales without the maintenance window planning overhead, definitely check out Momento Cache!
Happy coding, and may your development journey be as uninterrupted as your creativity!
Share
EN 
JP