O’Reilly Software Architecture Conference – NYC
The O’Reilly Software Architecture Conference covered an enormous number of topics. This blog focuses on summarizing three of them because we felt they applied most directly to the work we do here at Enova: AWS continuous delivery pipeline technologies, Incremental architecture, and Event storming.
AWS continuous delivery pipeline technologies
John Chapin focused this talk around a tutorial broken up into six different concepts that are simple to achieve using AWS. Each step involves setting up a new resource with a simple CLI command and a configuration file to specify intricacies of the command.
If you are new to AWS, we suggest playing around with this tutorial. It’s easy to follow and gives a good introduction to the concepts below.
- Setup CodeCommit repository in your AWS account.
- Specify environment so that the application can be built remotely.
- Build on any commit to master.
- Lambda functions deployed on commit to master.
- Store and reuse build dependencies in S3.
- Setup human intervention as part of your deployment pipeline using SNS topic.
Enova is currently focused on using Terraform as our main infrastructure as code solution. We started off using CloudFormation, but have decided to implement new cloud infrastructure configurations in Terraform. Terraform makes it very easy to integrate with git repositories outside of AWS, which we found to be invaluable. We have found that Terraform’s language for configuration is much easier to read and maintain than the lengthy YAML files that we were ending up with when using CloudFormation.
Incremental architecture
Allen Holub was the speaker for the next talk, “Incremental Architecture.” This talk was lively and covered a large number of subjects all on its own. There were three topics that stood out to us.
The first was an idea that was repeated multiple times throughout the conference – “Ubiquitous language” and its role in domain-driven design. The idea here is to have stakeholders, developers and everyone in the company really speak the same language so that there is no confusion when speaking about new and existing functionality. This practice takes an intense amount of discipline to follow. Although there is great difficulty in migrating to a more ubiquitous language years after the original implementation, we have opportunities to create a more universal language across Enova, which is a transition that is underway.
The next part of Allen’s talk that we would like to cover is bounded contexts. This talk brought into focus the fact that one concept could be split between two bounded contexts, and there has already been some talk recently about bounded contexts at Enova.
Bounded contexts are useful in our business. At Enova we work with a number of marketing partners that generate lists of prospective customers. Imagine breaking out the concept of “leads” from our combined database. There is no reason why splitting leads functionality would have to remove the Customer or Lead model entirely from the database. Instead there can be a Customer and Lead record in both places, while only information that is important to functionality inside each application needs to be present in their respective models. Maybe the Lead record in the database could be paired down to only an identifier of some kind. This would allow us to isolate functionality, making future enhancements faster and making it easier to scale. Event storming, which we’ll discuss more in the next section, can be used to define these bounded contexts and identify key business events for Enova.
The last piece of the talk that we’d like to draw attention to is the idea of truly small stories. Allan spoke about there being only one truly valid number of points for a story, and that is “1.” Everything else was either “TFB”, or “NFC” (more details here). We thought this idea was amazing and hilarious. He goes on to provide techniques to help break down larger stories into smaller ones. One way that stories often find themselves broken up is by front end vs back end work. Allan warns against this approach since delivering just one of the stories provides zero value to the business. A healthier way to break down a story is to isolate specific operations within a story. Say, for instance, we are interested in giving one of our applications the ability to alter a customer’s information. Instead of the story stating something like “I can manage my account,” we could isolate specific operations on an account into their own stories; “I can edit my email,” “I can cancel my account,” etc. Another technique that we are already well versed in at Enova is to time-box research tasks into spikes so that we are able to better write actual stories in the future. We are eager to apply these techniques to our teams.
Event storming
The final topic that we’d like to cover is that of Event Storming to achieve domain driven design. This is a workshop format technique used to design systems, develop ubiquitous language, and even break up monoliths!
The group first starts with defining all the domain events (anything that happens that is of interest to a domain expert), followed by commands (triggers that causes these events). “Aggregates” (groups of domain events and commands) are identified and then themselves grouped to make a bounded context. Each of these actions are done on a color coded sticky note and arranged on a timeline. Some of our domain events are: apply for a loan offer, choose a loan offer, and confirm loan. The command or trigger for these events are a prospective customer applying through a “lead provider,” underwriting, and signing the terms of the contract for that offer. This would all be defined the in the context of a customer. During event storming, questions on implementation, test scenarios, and any constraints or rules are identified and become their own color sticky note. While the idea remains interesting, the workshop itself is a facilitated one, ideally by someone adept at Domain Driven Design.
There were a number of other talks that we enjoyed:
- Serverless content delivery (a.k.a. Livin’ on the edge)
- An emerging architecture pattern for Agile integration: Cell-based architecture
- Microservices architecture in the real world
- Leadership skills for architects
- Architecting for news recommendations: The many hidden colors of the Gray Lady
- Distributed event-driven services: From the trenches
- Anatomy of testing in production: A Netflix original case study
- Technical debt: A master class
- Choreographing microservices
- Developing great architects: Creating the right environment for growth
- Chaos engineering and scalability at Audible.com
- An architect’s guiding principles for leadership
- 7 years of DDD: Tackling complexity in large-scale marketing systems
Below is a link to the 2020 conference page for those who are interested in attending next year’s conference — we would definitely recommend it.