This post is part of our introduction series for our technology. Learn the background here or forever wonder how baseball cards, the macarena, and a cloud-native AMS are related.
In the intro to this series, we talked about our big ask. Design an AMS that knows you, connects you, and continuously improves. Anytime. Anywhere. Always.
Brilliant! Okay...now how do we do that? We knew that every other requirement would depend on our ability to continuously improve. Always.
Looking at other high-performing technology companies, you can see just how the pace of innovation has changed. I was at the AWS Summit Atlanta in 2018 when AWS put up a chart showing the rate of new features they’ve released over the last decade. In 2009 / 2010 it was 50 to 100 major feature releases. In 2017, that rate had increased to 1,430 major feature releases. In other words, spread evenly throughout the year, that would be 4 major features released every...single...day. And although we haven’t seen 2018 numbers yet, if the trend holds it will be twice that.
As we talked about in the intro to this series, an AMS is big. Like really big. We understand why associations have asked for an AMS to do so much and we don’t think that’s wrong. AWS is big too. Like really, really big. Powering most of the internet big. Big and agile aren’t mutually exclusive. However, big and agile doesn’t just happen. It is an emergent property of very deliberate choices that must be woven into every step of building a new system. To build a new system as big as an AMS, 2010 velocity isn’t good enough. We needed the kind of velocity AWS and other technology teams were achieving in 2018. So we asked, we listened, and we learned. And two of the first design patterns that stood out to us were microservices and serverless.
Big and agile aren't mutually exclusive.
Two summers ago, the A/C unit at my house broke. My wife and I suffered through a couple of sweltering nights before a repairman could come out. He took the compressor and came back with a new one. Just imagine if he told me I would need to wait for them to build me a new house. We live in Atlanta. In a couple of days, we would have just been two angry puddles.
We could not build a system that had to be released all at once and still achieve the type of agility your members demand. An AMS is too big. Instead, we had to build a thousand little systems that could each be tested, improved, replaced, monitored, and scaled out to handle increases in load completely independent from the other nine hundred and ninety-nine.
As is often the case, this is not really a new idea. This is the concept of interchangeable parts applied to software. And the benefits are well understood. Both accelerated delivery and increased reliability. If you don’t have to build a new house, you can fix a whole lot more A/C units instead.
In software, this approach is referred to as a microservices architecture. Over the last several years, microservices architectures have taken the technology world by storm. It has produced a new generation of teams that are far more agile and productive.
Knowing we were going to have a fleet of little microservices all working together, next we needed somewhere for them to live. When technology teams were first faced with this challenge, the solution they came up with became known as containers.
A container is like an apartment complex where each little microservice lives in its own space within the building. This was a big step forward. But constructing and managing an apartment complex takes effort. In fact, it’s a full-time job. Within the last year or two, public cloud providers have stepped in to shoulder this load. With new serverless architectures like the one used by Rhythm, AWS builds the apartment complex and keeps it running smoothly. It’s like a pet sitter for our army of helpful little Tamagotchi. And with those little guys well taken care of, we get to stay focused on what actually matters. Building the features you and your members deserve.
