Summary

There is a dirty little secret lurking in this otherwise charming world of modern cloud based software: PaaS based solutions are not immune from poor software architecture. In the 2nd post in this series, we outline strategies to help you avoid inappropriate monolith architecture creeping into your PaaS solutions.

In our last post we outlined how we had observed an increase in the presence of PaaS codebases containing monolith architecture and why that can be unhealthy. If you missed it, we recommend you hop back and review that first. In this post we explore approaches that can help you avoid this.

Remember our focus in this series is PaaS code services like Azure Functions and AWS Lamda. These services tend to perform best when kept relatively small and discrete. If you really need to keep a ton of code that cannot be broken into smaller pieces then consider if containers or some other approach may not be a better tool fit. In truth avoiding the monolith trap with your PaaS solutions is as much art as it is science but here are some recommendations:

1. Pause & Plan

First, stop digging larger holes! Enforce deliberate time & space into your projects so that your team can gather enough relevant information. Some design information could come from hands-on design work like prototypes. Regardless it is critical that you don’t let these outcomes runaway to an accidental monolith conclusions.

2. Design with intent

Now you’ve put that space in your project, use it to apply some focused design time. It is all too easy to rush in and build. At some point building will be important, but skip any deliberate design effort up front and you will pay the price later. The more code and the further into production you get, the higher that price will be.

3. Decompose

You should seek out appropriate boundaries and partitions within your software design. Break out layers of logic and data into separate appropriately sized modules and provide appropriate gates/interfaces (API) both inside and outside your solution. Leverage design guidance that pertains to your domain. If you are seeking guidance on ‘how’ to do this, we recommend leveraging practices & processes like those described by Roger Sessions in his book Simple Architectures for Complex Enterprises, or search articles/books on Domain Driven Design. The strategies outlined in these can help you break the system into more appropriately sized constituent pieces.

4. PASS-ME Analysis

You can leverage this age old anagram to quickly analyze where your team’s software design is currently at. Critique your design across the headings of Performance, Availability, Scalability, Security, Maintainability, Extensibility. Does the design adequately enable your targets? If not, revisit, you still have work to do.

5. Size Appropriate

Whatever you do, keep it size appropriate. Don’t start to design for the Golden Gate bridge if a simple little culvert is ample for your solution requirements. Also don’t let perfection become the enemy of good enough. You can loose a lot of time iterating design but most of us eventually have to produce something. At risk of upsetting the frameworks and standards police we will share our opinion that, the art of understanding when more design work becomes a diminishing return is just that, art. Don’t be scared to be the judge if no one else will. If needed see point (7) below.

6. Tool Appropriate

Challenge yourself on whether existing eco-system tools are being used appropriately. E.g. Does this solution really need more custom code to enable? For example Microsoft Azure provides excellent low code/no code services like LogicApps and API Manager. Examples we’ve seen include: developer teams writing custom file pickup, parsing and mapping code, implementing custom queuing, custom workflow and custom front ends. This is not an exhaustive list but point is: most of these could have been addressed by out of the box tooling provided by the PaaS platform. Remember, your code only gets tested by you. By unnecessarily avoiding these tools it is not just the cost of writing more code that is being incurred but also the additional testing and maintenance overheads.

7. Leverage experience

Finally seek out the expertise in your team and beyond from those who have delivered software before.

The above list are common techniques and strategies that DMS Group use. By sharing we hope they can help keep your own PaaS projects on the path to optimum success. If you’re seeking further help either remediating or better still planning your PaaS projects, by all means reach out to DMS Group. You can contact us here.