Cloud Hosting

So whats a monolithic application anyway? Its 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 onsnowflake 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.

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-consumingand 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.

Amazon EventBridgeis 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:

Here are some examples of event-based triggers:

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 applications 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.

A typical use case for Amazon EventBridge is to run background jobs periodically. This is similar to cron which is familiar to Linux users. Heres a short list of what such jobs could look like:

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 its running on by moving those tasks to Amazon EventBridge, which is a serverless service.

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:

You can then perform pre-programmed actions, such as executing a Lambda functionor posting a message to an SNS topic.

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.

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 smallabout 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 SQSor Amazon MQ. It really depends on your applications 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 therethat 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.

Read the rest here:
Migrating applications to cloud with Amazon EventBridge - Security Boulevard