Solutions Architect Tips — How To Design Applications for Growth | by Allen Helton | Jul, 2022

When designing an software, it’s worthwhile to plan for 3 steps sooner or later

Electrical bulb vector created by macrovector

A couple of years in the past, I used to be requested to design a standalone software. It had a singular goal and was meant for use independently of every other software we had at my firm.

So I took the necessities and designed an software that was simply that. It had every part self-contained and, sadly, was tightly coupled with the items that made it up.

We acquired about seven months into improvement earlier than I heard a scary rumor. This software wanted to be part of one thing bigger. A participant in a bigger ecosystem of functions. Nevertheless it was only a rumor, so we continued on.

Three months handed; it wasn’t a rumor anymore. We had formally determined to pivot within the course of the applying virtually a yr into improvement. Design choices had been made with assumptions that had been now fully fallacious. Main elements of the applying that ought to be shared with this “bigger ecosystem” had been tightly coupled to extremely centered use circumstances.

For sure, we had been in a bind. Our information mannequin wanted altering. We wanted completely different isolation ranges for our microservices. And we would have liked to loosen up a number of the coupling between our companies.

Years later, we’re nonetheless unwinding a few of the tight coupling. Regardless of being informed the preliminary course, we might have designed the applying somewhat otherwise up entrance to keep away from a state of affairs like this.

Had we adopted these tips for architecting for development, we might have minimized the quantity of rework and had a stronger answer total.

In a earlier weblog publish, I wrote about designing applications for scale. In that publish, I’m going over the way to design an software for an rising quantity of customers in your system. Over time your consumer base will develop, and extra site visitors will likely be incoming to your app. That is scale.

On the opposite aspect, we’ve development, which is the natural enhance within the measurement, scope, and complexity of your software. As you iterate in your app’s function set, you might be serving to it develop. The app’s footprint will get bigger and bigger, making a naturally extra advanced and tough to take care of a bit of software program.

To consider the 2 on the identical spectrum, dealing with extra site visitors (scale) can be scaling up, whereas constructing a bigger set of options (development) can be scaling out.

There’s nothing fallacious with development; it’s a great downside to have. However you do want to think about it when arising along with your design. How will you account for brand spanking new main options? Is there any chance of your software increasing into one thing greater?

Incorporate some intentional development factors into your design so issues will be added, iterated, and presumably eliminated sooner or later.

When designing an software for development, assume there are various unknown unknowns. There are going to be new options that come within the product pipeline, however you don’t know what they’re. The product house owners don’t even know what they’re. However it’s worthwhile to take into account them when arising along with your design. How do you try this?

Unfastened coupling

A manufacturing software of any measurement goes to have many transferring components. Your aim because the options architect is to make it so every a kind of transferring components is as fully unbiased as potential. This implies the elements will be iterated and deployed on their very own and never depend on different microservices or elements to be deployed or work correctly. If one part adjustments, you aren’t required to alter the “coupled” part as effectively.

Usually talking, designing a system this manner means your elements have little to no data of one another. After they should talk, achieve this with APIs slightly than straight invoking capabilities or loading from the database. This is called loose coupling.

Unfastened coupling leaves the doorways large open for software development. Since your elements and microservices don’t depend upon one another, you’ll be able to add on and create new elements with out rewriting or slowing all the way down to a crawl.

When displaying free coupling on an architecture diagram, you’ll be able to denote these relationships with a dashed line. Tightly coupled relationships (which you hopefully received’t have lots of) are represented by stable strains connecting completely different elements.

Let’s take an instance. Think about you could have a podcast software composed of a number of companies listed beneath.

Podcast software service diagram
  • The podcast service is tightly coupled with the doc administration service, which shops the audio and video recordsdata for the podcast.
  • The subscriber service is loosely coupled with the podcast service, the place it subscribes to occasions and makes use of the API to load episode info.
  • All companies are tightly coupled with the auth service and shared infrastructure service, which accommodates the customized authentication mechanism and issues like KMS keys.

Occasion-driven workflows

An occasion is an motion that has occurred in your system. Occasions not solely present free coupling, however additionally they provide hooks into enterprise processes.

For instance, in our podcast software, an episode-published occasion is printed when a brand new episode is created. The subscriber service listens for the occasion and sends an e mail to everybody who subscribes to the podcast.

Subscribers of the occasion are unknown to the writer. There will be zero, one, or many subscribers to a selected occasion, which is what makes event-driven workflows good for development.

When the preliminary improvement is accomplished, you’ll be able to publish occasions representing necessary enterprise actions even with out subscribers. Throughout future improvement, companies can subscribe to the prevailing occasion and instantly tie in their very own workflows. That is identified as a webhook.

Webhooks enable for the simplest development over time. So long as companies can subscribe to your occasions, you’ll be able to indefinitely (to a degree) develop your app with new loosely coupled options. Occasion-driven workflows are even explicitly listed as a serverless design principle by AWS.

By utilizing webhooks and occasions in our podcast instance, we’ve successfully left the door large open for development by exposing a hook for future improvement to set off on.

If we determined to routinely push our content material to internet hosting companies like Apple Podcasts and Spotify, the episode-published occasion already exists for us to tie into and add that function shortly and simply.

API heavy

A fancy software may have a number of communications between companies. Your occasions will typically require extra lookups to get the total element of an entity, and multi-service validations are vital for superior workflows. To facilitate this whereas sustaining free coupling, you make calls to APIs.

Design your functions with an emphasis on simply extendable and consumable APIs.

By constructing flexible and consistent APIs, you allow future improvement to get the precise info they want. It additionally creates alternatives for customers to govern information as a part of a brand new function set.

Within the instance beneath, we’ve a sequence of cross-service actions that happen when an episode will get printed in our podcast app.

Cross-service workflow for publishing a podcast episode
  1. The podcast service makes an API name to the doc administration service to save lots of the audio file.
  2. The podcast service fires an occasion subscribed to by the subscriber service.
  3. The subscriber service makes an API name to the podcast service to get the total particulars in regards to the episode earlier than notifying subscribers.

Whereas designing your system to be API-heavy isn’t technically structure, it’s one thing to think about as a options architect. Satisfying the workflow above is barely potential due to entry to a powerful API.

To drive acceptable emphasis on APIs, you might push for API-first development in your group. Placing time and power into API design up entrance will make your functions straightforward to develop.

Within the easy enterprise course of supplied within the instance above, there are two cross-service API calls and an occasion. As your software grows, this sample will likely be repeated over and over.

As a options architect, it’s your job to determine the way to make elements fully separate but work collectively seamlessly. On the floor, that feels like a frightening and borderline unattainable activity. However should you keep in mind these three issues, you’ll set your self up for achievement.

  1. Maintain your elements loosely coupled so you’ll be able to iterate on them independently and deploy them individually.
  2. Publish occasions on main enterprise actions so as to add set off factors for future options and integrators (even should you don’t use them now).
  3. Construct APIs for every part. In the event you can, preserve all of them public going through and construct them below a standard governance mannequin.

With these in thoughts, you allow your self open to rising your software to do virtually something. You don’t tie your self down with the burden of propagating adjustments by a maze of tightly coupled companies. You construct intentional extension factors with occasions that something can tie into at any time. And also you construct easy-to-consume entry factors into your companies by APIs.

You don’t need to know the longer term whenever you construct with this method. You will get thrown curveball after curveball, and your software will be capable of deal with it.

Completely happy coding!

More Posts