“Don’t put all your eggs in one basket” - while legacy architecture designs have helped us serve award-winning apps for our clients back in the day, change was slow and deployments and maintenance tasks were always a headache requiring too much planning, effort and overhead. So, how did we improve on this?

At Concentrix Tigerspike, our inquisitive nature brings insight and innovation. And migrating our hosting services over from the local datacentre to AWS back in 2013-2014 made it even easier and better to innovate and keep up with the latest best practices. With AWS, you’re always presented with new services, solutions and opportunities for improvement.

Shared dependencies between applications bring shared risks; i.e. each application introduces its own risks to a bigger pool of risks shared by all applications.

So, without further ado, here are some of the approaches we’ve taken to decouple and de-risk the applications we build and manage wherever and whenever possible:

Decouple your multiple applications on a shared infrastructure.

Decouple the Frontend and Backend of your Full Stack applications.

Categorise and decouple your Infrastructure as Code resources.

Like many early adopters of IaC, our very early templates were either written per AWS service, which makes them too many, or for everything that makes up an application, which makes them too complicated. Imagine managing a template for VPCs, a template for Subnets, a template for RDS, a template for Load Balancers, etc. Too many. On the other hand, imagine managing one ~3000 lines template that includes everything for that application such as VPC, Subnets, RDS instances, Load Balancers, EC2 instances, IAM Roles, etc. Too complicated.

A few solid projects later, we found the sweet spot. We now group resources based on their logical service within the system we’re building. For example:

Finally, refactor and decouple your monolithic applications.

Perhaps, this is the first thing people think of when you start talking about decoupling; and this is where they give up. Decoupling monolithic apps could be overwhelming, time consuming and expensive when you look at it altogether! But, in reality, it doesn’t have to be. As you read so far, we have gone through different examples of decoupling and de-risking different things around the app. “Take the small wins to achieve the bigger goals”, and when you get to this stage, here are a few pointers to help you:

That’s all folks! I know I highlighted a lot of decoupling practices and mentioned a dozen of AWS services and examples, in a 5 minutes read so I will leave you with that. The aim is to inspire anyone out there looking for ideas and to show how easy it is to get started.

AWS CodeBuild, AWS, Engineer, manager, ambassador

Moha Alsouli

Senior Platform Engineer,Sydney

AWS CodeBuild, AWS, Engineer, manager, ambassador

Moha Alsouli

Senior Platform Engineer,Sydney