I recently started a new team at Jamf dedicated to building out our internal and external developer platform. Something my team has had to do with our formation is document the decisions we were making to not only have a record of them, but to understand why we made them at the time (look up Architectural Decision Records some time). These decisions cover things like specific technologies, methods, or standards we adopt.
When Emily Freeman (@editingemily) pitched a replacement to the SDLC, the Revolution Model, I was immediately captivated by the idea. Much of my time spent building cloud native services and applications at Jamf has never followed a linear path. It’s far more fluid in direction, and it has been hard to reconcile that kind of chaotic workflow with other parts of my org. Revolution provides a compelling means of doing this.
My first two days here at AWS re:Invent leading up to the latest version of her presentation (it changes a little every time) has given me time to muse on the application of Revolution to my work. I started to relate the model to the ongoing decision documenting process my team has been engaged in, on and off, the past couple of months.
Emily’s first pass at the Revolution Model is actually really good (despite her claims that if it doesn’t change she considers it a failure). Architecture exists at the outer most level with operating the very thing we are building the ultimate goal at the center. In her talks, she has walked through examples of mapping incident responses, or the path developing a new feature has taken from ideation to operation. I am looking now at how the model may be used for the initial phases of a team or a project where the foundational questions need to be asked and answered.
I’m writing this post with no plan. I’m going to have a copy of the model open next to me, and I’m going to explore the process free form.
The Model
The Revolution Model consists of six layers: Architecting, Developing, Automating, Deploying (I might actually reverse those last two), and Operating. Each layer has six considerations to evaluate in order: Testability, Securability, Reliability, Observability, Flexibility, and Scalability.
Taking Revolution in, the ideal happy path appears as a spiral. We start at Architecting, make our way around each consideration, and then we move in one level to Developing. Each layer requires a complete revolution through all considerations before moving further in. Ideas happen in the central segment, and those ideas are implemented according to the considerations as we progress.
Architecting
Ideation: I’m going to build a new API. It will be RESTful, follow a CRUDL model, and be built using AWS’s serverless stack: API Gateway HTTP API, Lambda Functions, and DynamoDB.
Testability: Unit tests are (should?) be a given, but I need to know how I will test my active service. CloudWatch Synthetics seem like a good choice as the interface is an HTTP API.
Securability: Now here’s an interesting development. Depending on how my API is going to be used - internally, or by third parties - I could go two different ways. Internal use I might want to stick with IAM authentication. Third party I would go with Cognito. If I want to use IAM I need to go back to Ideation because HTTP APIs don’t support it! If I did, I would now reevaluate the Testability of my technology choice. Tthe decision to use CloudWatch Sythetics thankfully remains unchanged as I’m swapping out one API Gateway for another.
Reliability: I have a high degree of confidence in the availability and operational consistency of the services of choice here. Writes will be durable, and reads should return the most up to date version of my data.
Observability: CloudWatch Alarms and Metrics can give me actionable data. Adding X-Ray will add even more to my ability to inspect the state of my service, but there’s another wrench thrown: HTTP APIs do not support X-Ray. The trace would initiate from Lambda, and I would not have the context of the request. This is again another point where I might reevaluate in favor of using a REST API.
Flexibility: Adding new endpoints, new Lambda functions, and changing how I write items to DynamoDB are all very simple here. Versioning API routes and tying those versions to independent functions is a pattern that makes changes manageable. Migrating old items to new items is an active consideration. I need to determine how I will handle item version migrations for when I move on to development. Do I handle this at runtime, or asynchronously after an update? The former means there’s no additional action needed on my part during deployments as long as everything is handled on a per-request basis, but it has the threat of old versioned data stagnating within the table.
Scalability: Within the default quotas provided by AWS for my account I know that my service will scale pretty far for usage. Separating Lambda functions out by endpoint and API version solved for flexibility, but there is overhead for managing the shared code between all of them. An internal Lambda Layer looks to be a good fit to solve for this.
Taking It In
This was just my first revolution around the model. At two points I identified issues with one of my technology choices: the HTTP API. I’m going to drop it and switch to a REST API so I can use IAM authentication for security and initiate X-Ray traces for better overall observation. There was a lot to consider (ha) here, and I haven’t even touched on getting into the Development layer. But, this has given me a clear and defined path to navigate as I move into that level.
My decisions during Development should implement and reinforce what I decided during Architecting, but if I hit a wall I will need to drop back down to Architecting and reevaluate again. I can imagine that by the time I get to Deploying I may encounter issues that stem from decisions during Development that might require another loop back to address to ensure a better overall design.
This may have to become a series if I continue this exercise through the rest of Revolution’s levels. But I have to say, even better than having Revolution as my guide to designing, building, and then implementing my project is that I can visualize the path it took to achieve release. The end result is something that can be used to inform projects that follow.
There’s so much more to do.
Top comments (1)
Very interesting use of this new revolution model. Thanks for sharing.