News

Five Things Every Developer Should Know about Software Architecture

Simon Brown wrote on InfoQ the "Five Things Every Developer Should Know about Software Architecture" and argued that understanding the basics of software architecture is more important than ever before, given the distributed nature of the software systems we’re now building, and the distributed nature of the teams building them. A key goal is getting the amount of "up front design" correct - somewhere between too much and none at all - and architects should focus on understanding the significant decisions and trade-offs that influence the shape of a software system.

Brown stated that effective architects are active members of the development team, from collaborating on code to coaching and providing technical leadership. Communicating about software architecture is challenging, and the C4 model can help structure the dialogue, starting with a context diagram, and working down to more technical aspects of the system. Brown concludes the article by stating that contrary to some popular assumptions, putting effort towards good architecture actually enables agility.

Designing "Testable" Microservices

The previous month has seen several excellent discussions on how to design microservice systems to promote testability. Cindy Sridharan, an engineer at imgix, wrote "Testing Microservices, the sane way", and argued that although testing has historically been something that referred to a pre-production or pre-release activity, this needs to change.

The desire to test all components together in unison - typically referred to as an end-to-end testing - can be beneficial for some use cases, but in general will slow development velocity. Martin Fowler also weighed into the discussion, and stated there are clear differences between "narrow integration tests" - exercise only that portion of the code in my service that talks to a separate service - and "broad integration tests" - including live versions of all services and requiring substantial test environment and network access.

Sridharan also stated the emerging techniques like canarying, distributed tracing and chaos engineering can help with testing microservices. In particular, chaos experimentation and testing is garnering a lot of attention for improving resilience within complex distributed systems. Speaking at QCon San Francisco Nora Jones argued that there are ways that we can design services to make us better prepared to participate in these kinds of resilience tests. "In design discussions at Netflix now we've moved from saying 'what happens if this fails' to 'what happens when this fails.'"

Wes Reisz recently spoke to Kolton Andrus, founder of Gremlin Inc - a Software-as-a-Service platform that lets you plan, control and undo chaos engineering experiments - and Andrus was keen to also stress the importance of the human side of chaos engineering, and talked about the need to run Game Days, or what Adrian Cockcroft refers to as "Fire Drills for IT".

Harry Winser also presented "How to be Confident That Your Microservices Can Still Communicate in Production with Pact and Docker", and argued that "if you're not testing the communication between your Microservices before production, you're going to have a bad time". As a potential solution, testing interactions between microservices can be achieved using Consumer Driven Contracts to define the interactions up front. Independently, André Schaffer echoed similar sentiments in "Testing of Microservices", and argued that there is a need to design microservice applications with integration testing in mind.

restQL, a Microservices Query Language, Released on GitHub

Thomas Betts wrote on InfoQ that restQL, a query language for microservices, is now available as an open-source project under an MIT license. The restQL language is intended to simplify common scenarios for client-side access to RESTful microservices, including multiple parallel calls and chained calls. Developed by B2W, the largest e-commerce operation in Latin America, restQL was created to avoid some limitations of the more well-known data querying and management frameworks Falcor and GraphQL.

Architecting a Modern Financial Institution with Vitor Olivier

Wes Reisz recently sat down with Vitor Olivier, a partner at Nubank (a technology-centric bank in Brazil), and created a podcast that discusses Nubank's stack, functional programming, event sourcing, defining service boundaries, recommendations on reasoning about services, and their approach to the second iteration of the initial architecture. The podcast, in combination with recent QCon presentations by the NuBank team, provides a fascinating insight into what it takes to design an effective architecture for a modern financial institution.

This edition of The Software Architects' Newsletter is brought to you by:

The Benefits of Java Memory Monitoring

Garbage collection in Java isn’t a constant activity, but is run only after certain conditions are met. This means that the memory you see the JVM using at any given point in time is likely more than your application requires, unless you measure it immediately after the garbage collector has run.

Therefore, in order to get an accurate picture of your application’s memory usage, you need to measure the average amount of memory used over an extended period of time. Noticing that your application has recently started using a little more memory isn’t cause for concern, but if its memory usage consistently increases while running, then there may be a memory leak somewhere in your code.

Case Studies

Stitch Fix Case Study: Events as First-Class Citizens

Randy Shoup, VP Engineering at Stitch Fix, has stated that "events should be treated as a first class citizen" and argued that events are not used enough within software development even though they help to decouple parts of a system and reason about them independently. In order to build on his arguments for "Managing Data in Microservices [with Events]" - presented previously at the QCon NY conference - Shoup examined the lifecycle of a "fix" (customer sales interaction) at Stitch Fix, and discussed how they use events to model this.

Within a Stitch Fix workflow (such as the "fix" flow) is triggered - for example, a client visits the website and indicates she would like to receive a shipment on a particular day - the backend application produces an associated event within the system. The producer of an event is responsible for publication, and zero or more consumers subscribe to it - "maybe no one is listening; maybe one is; maybe many are. The producer does not know or care." This gives the beneficial property that the producer and consumer are completely decoupled from one another.

Once all of the interesting state transitions are represented as events for an entity, the events can be used as a record of what happened to that entity, and when. This is hugely valuable when the Stitch Fix team wants to examine what has happened in the past; it is common for the Stitch Fix client experience team to look up the history of a fix when they are trying to help out a client; it is common for the data science team to use the events around a fix to optimize various aspects of the workflow; and it is common for the engineering team to use this as a debugging and diagnosis tool.

Shoup stated that he often hears that it is challenging for developers to think in terms of events - "it can feel a bit counterintuitive if you're used to building the classic three-tier. We use words like 'eventual consistency' and 'asynchrony' here, and they've earned their reputation for being hard to reason about." However, he suggests that developers have a lot more intuition about events than they think they do - after all, this is how many things in the real world work - and "if you can think about your problem as a workflow", he suggests, "then you are more than halfway there".

To get notifications when InfoQ publishes content on this topic follow Event Driven Architecture on InfoQ.

This is the sixth issue of a monthly newsletter, focusing exclusively on software architecture. We thought it would be valuable for you to get a quick overview of things you might like to keep an eye on. If this is not the case, you can unsubscribe using the link below.

Forwarded email? Subscribe and get your own copy.