So what’s a monolithic application anyway? It’s essentially an application where almost every single piece of functionality has been written in the code by its developers and is typically built to run as a single unit on a single server. A typical example is WordPress, by far the main model in the past, and many applications are still developed this way today.
Monolithic applications can come with a number of issues. For instance, they typically run on snowflake servers, fragile servers that keep system administrators awake at night in the fear that they might experience some sort of problem.
What is most likely considered the main issue with monolithic apps is that additional features and bug fixes take a long time due to the tight coupling and side effects between its various components.
Developers and managers are used to dealing with such applications, which are usually good enough to fulfill all of their requirements. But there are steps you can take to make a monolithic application enter the world of the cloud, rendering it more robust and increasing its availability. It is also a great relief to no longer have to rely on a snowflake server.
Amazon EventBridge is a very useful tool in this endeavor.
Changing the Context, Not the Content
In most cases, businesses will want to keep their code base, which usually works reasonably well after having been refined over many years. Performing a profound refactoring of an existing monolithic application to follow a cloud-first strategy can be very costly and time-consuming—and would probably fail any cost-benefit analysis.
The good news is that you can still benefit from the cloud without too much refactoring by changing the operational context. As we will see, a monolithic application can transparently benefit from certain cloud services to increase its reliability and availability as well as enable it to scale per demand, all with little or no refactoring of the application code itself.
A typical case in point is WordPress. WordPress is a publishing and content management software that was written long before the notion of “the cloud” even existed. Now, you have solutions that let you integrate many cloud services with WordPress, allowing multiple instances to run in parallel and making WordPress much more reliable and available. AWS offers various reference architectures to achieve this, such as this one.
The Role of Amazon EventBridge
Amazon EventBridge is a glue service offered by AWS that triggers a given action either periodically or based on events originating from other services. EventBridge offers different options for periodic triggers:
- A “rate” scheduler, which simply triggers an event every 30 minutes, every five hours, or once a week
- “Cron” expressions to allow fine-grained scheduling of jobs
Here are some examples of event-based triggers:
- An autoscaling action taken by an autoscaling group
- A file retrieved from S3
- A file saved to S3
- A failover performed by an RDS database to a hot standby instance
- Almost all AWS API calls that can be logged to CloudTrail
The list is very, very long.
Should you decide to move your monolithic application to the AWS Cloud, Amazon EventBridge can definitely help you. The easy and obvious win is the refactoring of the context of your application, where Amazon EventBridge will typically be used for administrative or background tasks. Essentially, with little effort, you will get a lot of bang for your buck.
You can also use Amazon EventBridge as part of the application’s architecture itself —although this is rarely possible without some significant refactoring. One exception would be if your app uses an event-driven architecture. It would then be possible (at least in theory) to move the management of events to Amazon EventBridge, and you would benefit from a reliable, highly available service backed via the might of AWS. However, businesses will rightly question the benefit of such a move, and you should conduct a pertinent cost-benefit analysis before pursuing such a course of action.
Running Periodic Jobs
A typical use case for Amazon EventBridge is to run background jobs periodically. This is similar to “cron” which is familiar to Linux users. Here’s a short list of what such jobs could look like:
- Cleaning up temporary files
- Performing backups
- Moving some files to S3
- Performing security audits
- Generating reports and saving them to S3
Amazon EventBridge can trigger jobs based on either “cron” expressions or the rate of repetition. In the case of a snowflake server, administrators usually create several cron jobs to perform administrative tasks. When migrating to the cloud, it might be beneficial to move such jobs to Amazon EventBridge. This would decouple the application itself from the administrative tasks of the server it’s running on by moving those tasks to Amazon EventBridge, which is a serverless service.
Responding to AWS Events
The other main use case for Amazon EventBridge is to perform a given action when a certain event takes place inside your AWS account. Examples of such events are:
- An autoscaling group started or terminated an EC2 instance.
- Somebody signed in to your AWS account.
- A CloudWatch alarm changed state.
- A commit has been made on a certain CodeCommit branch and you need to automatically trigger CodeBuild.
- A CodeBuild stage has finished and you need to automatically trigger CodeDeploy to deploy your app.
- You need to take an automated action in response to AWS operational issues.
- RDS switched to the hot standby instance because the main instance had issues.
- Someone deleted a file in S3.
For a traditional monolithic application, there are often a number of scripts and “mini-services” that perform administrative tasks or background jobs. When migrating to AWS to modernize such a setup, refactoring those admin scripts to use AWS serverless services, such as Amazon EventBridge, usually makes sense from a cost-benefit perspective. Generally speaking, moving to a serverless service means a lot less work and worry for you and your system administrators, as this is all done by AWS.
Amazon EventBridge can also capture events generated by third-party vendors, such as Thundra.
Generating Your Own Events
The final main use case for Amazon EventBridge is to generate your own events using event buses. EventBridge actually allows you to create your own event buses and post your own custom events. Then, you can respond to those events in exactly the same way.
This can be useful to manage admin or background tasks, but this feature is typically used as part of an application architecture. If your monolithic application is event-based, you might consider using Amazon EventBridge as the event bus. Then, the required refactoring should be pretty minimal, provided you encapsulated all interactions with this event bus in a separate library.
It should be noted that Amazon EventBridge is not meant to be real-time, although its latency is quite small—about half a second between posting an event and responding to it on average. Still, other options might be better suited to your needs, such as Amazon SQS or Amazon MQ. It really depends on your application’s architecture, and such a discussion would be outside the scope of this article.
In conclusion, Amazon EventBridge is a very versatile event bus that can handle periodic events, events from other AWS services, and events from third-parties (such as Thundra). When migrating a monolithic application to AWS, it can definitely be useful as part of a serverless strategy to implement all the administrative tasks required for your application.
Amazon EventBridge even allows you to implement your own custom events on dedicated event buses, which can help you with refactoring both admin tasks and the application itself. As a serverless service, it also has the tremendous advantage of freeing you from all menial tasks related to server maintenance. Finally, although not real-time, Amazon EventBridge is reasonably fast with an average latency of half a second; plus, it offers an SLA of 99.99%.
There are some concerns around observability with events coming in and out of EventBridge. Tracing the events over Eventbridge is still required to achieve the required visibility when you need to debug the issues. Thundra is the only vendor out there that provides tracing EventBridge calls that trigger Lambda functions, ECS and Fargate tasks.
At the end of the day, this is definitely a tool you want to consider when migrating a monolithic application to AWS.