Building evolving software systems is a strategy, not a religion. And revisiting your architectures with an open mind is a must.
Software architectures are not like bridge and house architectures. After a bridge is built, it is difficult, if not impossible, to change the way it was built. Software is completely different, once we run our software we can get information about our workload that we didn’t have when it was designed. And if we realized this early on and chose an evolving architecture, we could change components without affecting the customer experience. My rule of thumb was that with each order of magnitude of growth, you should revisit your architecture to determine if it can still support the next level of growth.
A great example can be found in two insightful blog posts written by the Prime Video engineering teams. The first describes how Thursday Night Football Live is built on a distributed workflow architecture. The second is a recent post that dives into the architecture of their stream monitoring tool and how their experience and analysis has led them to implement it as a monolithic architecture. There is no universal solution. We always push our engineers to find the best solution, and no specific architectural style is required. If you hire the best engineers, you should trust them to make the best decisions.
I always urge builders to consider evolving their systems over time and make sure the foundation is such that you can change and extend it with minimal dependencies. This is where event-driven architectures (EDA) and microservices come in handy. However, if there is a set of services that always contribute to React, have exactly the same scaling and performance requirements, the same security vectors, and most importantly, are managed by a single team, it’s worth trying to figure out whether to combine them. simplify your architecture.
Evolving architectures are something we’ve taken to heart at Amazon from the very beginning. Reassessing and rebuilding our systems to meet the ever-increasing demands of our customers. You can go all the way back to 1998, when a group of veteran engineers wrote the Distributed Computing Manifesto, which set the wheels in motion and moved Amazon from a monolith to a service-oriented architecture. In the following decades, things continued to evolve as we moved to microservices, then microservices on shared infrastructure, and as I talked about in re:Invent, EDA.
The move to separate self-sustaining systems was a natural progression. Microservices are smaller and easier to manage, they can use technology stacks that meet their business requirements, deployment times are shorter, developers can get up and running faster, new components can be deployed without impacting the entire system, and most importantly if the deployment stops. one microservice, the rest of the system continues to work. When the service comes back online, it replays the events it missed and executes them. We call this evolving architecture. It can be easily changed over time. You start with something small and let it grow in complexity to fit your vision.
Amazon S3 is a great example of a service that has grown from a few microservices to over 300 microservices with added storage methodologies, policy mechanisms, and storage classes since its launch in 2006. This was only possible due to the evolving architecture, which is a critical consideration in system design.
But I want to say it again there is no one architectural pattern that rules them all. How you choose to develop, deploy, and manage services will always depend on the product you’re designing, the skills of the team building it, and the experience you want to provide to customers (and of course things like price, speed, and durability). For example, a startup with five engineers might choose a monolithic architecture because it’s easier to deploy and doesn’t require their small team to learn multiple programming languages. Their needs are fundamentally different from those of an enterprise with dozens of engineering teams, each managing a separate sub-service. And that’s okay. It’s about choosing the right tools for the job.
There are few one-way doors. Regularly evaluating your systems is just as important, if not more important, than building them. Because your systems will run much longer than their design takes. So monoliths are not dead (quite the opposite), but evolving architectures play an increasingly important role in the changing technology landscape, and this is made possible by cloud technologies.
Now get building!