Managing and monitoring of iPaaS applications via the Azure Portal only is often not enough. Yes we do have Azure Monitor. Yes we do have Log Analytics and Application Insights with all the querying possibilities, dashboards and Logic Apps Management Solution. Via the Azure Portal, we can get insights into a single logic app or servicebus, but we will not have an overview of the entire process. Serverless360 (formerly known as Servicebus360) actually fills the gap. It allows monitoring at the application level as well as a consolidated monitoring view instead of all kinds of different tools in and outside the Azure Portal. This post is based on the following YouTube video. Further reference: ServerLess360 .
You can start the Serverless360 login page as follows: https://portal.serverless360.com/sign-in/. Before we begin a few words on the different versions to choose from and their pricing. You have to use a SaaS solution or an IaaS (self-hosted) solution. SaaS is the preferred and most easy option.
When using the SaaS model, security becomes a very important factor. Important to know:
- The Serverless360 servers are hosted on Microsoft Azure in region West Europe. Data will never leave region West Europe.
- Customer data are maintained in Azure SQL Elastic Pool. Each customer has a dedicated database within a private subnet on Microsoft Azure. Access to customer data is not possible from the outside world, only from the private subnet.
- All data is encrypted at rest and in transit. In transit for both the API calls and the UI. At rest for the customer configurations in the customer database.
- The actual messages or logs are not saved, except for repaired and/or resubmitted Service Bus messages.
- User actions audited are saved for 180 days. This allows for robust security monitoring.
Composite Applications are key to Serverless360. To the composite application, you can add resources like API Management services, logic apps, functions, servicebus queues and topics, eventgrid topics and Azure Storage resources. That enables clients to monitor the Azure solution from a business perspective. At the Composite Application Overview screen, you will see a visual chart per application showing you the success and failure rate (application health) at one glance. Every composite application has its own dashboard. This dashboard typically shows the failed and succeeded Logic App runs. You can click the [Manage] button to get to the Dashboard. You can click on the diagram to go to the underlying resources.
Let’s say you clicked on the diagram to go to the underlying resources. You will then see a menu on the left hand side where you can select Service Map to show the underlying resources and their relations.
Another key capability of Serverless360 can be labeled as consolidated monitoring. You want to be able to monitor your solution at one place, but from different perspectives. We distinguish among the following monitors: status monitor, watch monitor, data monitor and treshold monitor. You can schedule the alerts hourly or daily and notify the operators via Teams, a shared mailbox or a webhook (which can basically connect anything). Then you can associate resources: queues, topics, relays, eventhubs, logic apps, functions, storage files or blobs. Per resource you can specify the metrics you want to monitor on. For a servicebus this can be: active message count, deadletter message count or queue size in bytes, optionally with a warning treshold and an error treshold (number of errors) attached to it. The tresholds prevent notification spamming. Example report:
Alert on an extensive list of metrics, depending on the resource at hand. For logic apps this can be the number of runs succeeded, failed, run failure %, run latency, etc. For EventGrid Topic Subscriptions you can think of Delivery Failed Events and DeadLetter Events. Specify frequency between 15 minutes and 1 day. For a queue you can specify message count, throttled events, scheduled messages, etc.
Alert on health status of resources at a specific interval. For example Logic Apps state=Running.
Alert when a certain condition is persisted for a longer period of time. For instance: a logic app is down for two minutes.
Alert in near real-time when a logic app, function or API endpoint fails. For example: Failed Logic App runs per 5 minutes or DeadLetterMessageCount>0. A detailed error message is automatically shown. Don’t know if you need to catch and parse failures in scopes like we do.
Finally, when you configure ServerLess360 you will first have to create an application in Azure AD. This application represents Serverless360 and gives ServerLess360 rights in Azure the specific Azure subscription. The AAD application results in the creation of a service principal.
Serverless360 allows for fine-grained security at the application level.See Settings, User Management. Standard roles are Administrator and Super User. Both have all access, with super users having no access to licensing only. You can also create custom roles and add permissions to access specific applications and resources within those applications. Finally, you invite the Azure AD users. The choice to use Azure AD or basic authentication must be made at signup or installation. Azure AD must be activated. You can also add users from other AAD domains. For instance when outsourcing support.
Evaluation of Serverless360:
- Composite Applications are key to Serverless360, but in fact I’m first and foremost interested in the logic app runs. I wanna see in one glance how many logic apps succeeded and failed. For the failed runs I want to have a quick overview of the specific exceptions. I want to be notified immediately when an important primary system is down. I want to make changes to a reusable function when one of the logic apps shows exceptions. I want to be able to resubmit messages from Azure Service Bus. However, the state of a servicebus topic is less important to me than the state of a logic app. It’s enough to be notified when a servicebus topic is down. For logic apps I need an active form of monitoring.
- It’s easy to make visual diagrams in Serverless360. That makes it evermore important to think about the usefulness of a diagram. Why show the logic app runs over the past 7 days? Why have lines per logic app when most of those lines have a non distint color or are even not visible at all? What’s the use of showing the total number of calls to a primary system? Are these logic app runs or service calls? Do I see both failed and succeeded runs?
- In case of failure, it would be good to have a means of automatic recovery instead of only manual intervention. You can run automated tasks related to servicebus, eventgrid, logic apps, blobs and queues, but you can not periodically run a Powershell script. Think of Automation Runbooks. That’s important, but lacking functionality. It’s schedules for Q3 2020 as I understand.