Killing your monolith with the strangler fig

If you oppose killing anything (and I understand), simply change the word/s in your mind to happier ones (such as “sleeping” or “napping”). But the strangler fig is being talked about here because it is one of the most prominent methods in the digital transformation and/or modernization of applications. You may have heard the term digital transformation and immediately dismissed it as some buzzword, which, fair enough, most of the time when people use that word, it is. But open your eyes and ears for a moment and treat the term for what it actually is: it is changing old things into new things. It is basically changing your system from within while either maintaining the same functionality or increasing functionality. It is the breaking of the monolith into a loosely coupled architecture.

For starters, let’s look at the potential structure of a monolithic application:

Figure 8.3 – A basic monolith

It’s quite crude, but that is basically how most monolithic applications are structured. They have a user interface, which interacts with two different types of operations: operations on the database and generic data operations (Misc in the diagram). Even this monolith is rather more divided than regular monoliths since we have given it a separate database. The database can also be directly within the monolith sometimes.

Breaking down this monolith is not just about making it disassociated; it is about making sure that each component can act as an individual entity in case it becomes of use in some other project or in a different way in the same project. But to continue with the breaking down of this monolith, we can keep that going by first removing the miscellaneous functions that require no interaction with the users or the database from the monolith.

Figure 8.4 – Removing miscellaneous APIs from the monolith

So, this diagram indicates that the separation between the monolith and the miscellaneous functions divides those functions into individual components. This is the foundation of serverless architecture. It is all about exclusively having individual functions as individual endpoints to call only for certain use cases. This stage helps get the easy stuff out of the way and also helps make it so that the people performing the transformation can practically start grasping the concept behind it. It’s a lot easier to manage random functions if they are just endpoints somewhere that you can call randomly and modify to suit certain needs.

Now, the next step toward breaking down this monolith is the division of the user interface and the backend portion that performs the data operations. This involves placing an API or a backend for the frontend in between them.

Figure 8.5 – A fully decoupled architecture

The final structure after breaking down the monolith looks like Figure 8.5. It’s a bit like my consequences diagram but not as foolish. There are a lot of moving parts here, but then again, there are a lot of moving parts in cars too; it’s what makes them work. More importantly, let’s look at this from the lens of the two things emphasized in this chapter, availability and failure:

• If the user interface for some reason stops loading, it will fall back to a different region. This region will have the same capabilities; if it’s further from the user, it might be slower, but it will do the job.
• The API or backend for the frontend can receive calls from multiple user interfaces and can access multiple servers that have access to the database.
• The backend can then simply be there to connect to the database for operations. There is no need for anything there except for queries.
• The database itself becomes more secure due to the layers present and it becomes easier to increase its availability.
• The miscellaneous functions are simply endpoints that can be put in or taken out as it suits the development team.

Well, that is quite the process, isn’t it? But it is one that gives results and helps make your application or workload more sustainable and futureproof. It doesn’t work for every workload, but it is fantastic in helping older systems use modern technology better.

Summary

In this chapter, you learned about the event-driven architecture that comprises a lot of modern application development. You also, hopefully, learned about actions and their consequences and how important positive actions are to development and your life in general. Lastly, you learned about a way to modernize older applications toward this new philosophy through the use of the strangler fig.

In the next chapter, you will get even more hands-on with Python and learn about the role that Python can play in CI/CD (short for continuous integration/continuous delivery). It’s a fun topic and will help you implement the Python skills and concepts you’ve been studying in this chapter.