AwareOps introduces a new way to monitor services, regardless of whether that service is an internal microservices or external third party service. Most modern companies have complex dependencies that either support a software product or internal business operations. One of these services might actually depend on several services, and if one of those services incurs an outage it would cause the whole service to become inoperable. So how do you manage this complexity? This is why we introduced Service Facade Monitoring.
What's a Service
Whether you're managing a SaaS software product or internal IT business operations, you likely are supporting users with a variety of services. For example, let's say your SaaS app relies on Cloudflare for DNS, Heroku for application and database hosting, and Twilio/SendGrid for SMS notifications. You might also have a reporting engine for users that relies on AWS Redshift and Tableau. Your main application won't go down if Redshift is inoperable and your reporting engine may still be available even if your main application is inoperable because Heroku has an outage. This is a concept called "separation of concerns" and is a modern way to managing the reliability of complex systems.
Support for Microservices
You may even have some microservices in your overall landscape. Let's say you created an API endpoint that your core application calls when it wants to generate a PDF. You call this Service Facade "PDF Writer" and it can watch this API endpoint for any outages.
The Old Way
Depending on your use case, you might be monitoring these services in a variety of different ways. You may simply just wait to hear from the service provider or your users when one of these systems incurs an outage, or you might subscribe to each of the service providers. In the example above this might require monitoring five different services! Also, your monitoring isn't context aware - meaning if you incur a Redshift outage, there isn't any ability to discern what type of users need to be notified and what part of the application might be affected. Why alert all of your core users when you can simply alert those are just analysts that use the reporting engine? Thus, the introduction of a Service Facade.
Service Facade
A Service Facade is simply a collection of services. These services can either be comprised of either third party services or internal ones. As you can imagine this can have a very complex nested set of dependencies. Service Facades can even rely on other Service Facades! The point here is that you can encapsulate a collection of services so that there is some type of technical or business contextual awareness when you are monitoring the overall solution.
Service Facades in Practice
So what are the practical uses of a Service Facade? In our example above, you might create two Service Facades, one called 'Core Application' and one called 'Reporting Engine`. Now you can monitor these two Service Facades independently and notify any constituents.
For Monitoring & Debugging
You've setup the 'Core Application' Service Facade so that anytime Heroku's DB service has an outage, your 'Core Application' also has an outage. Once you've configured this, you have a complete log of when the outage occurred and why the outage occurred. This means less time having your support team digging into opaque 500 server errors, and more time putting into fail over plans.
For Notifications
AwareOps introduces complex notification capabilities. So whether you want your Service Facade to notify individuals via SMS, a Slack group, an email distribution, your own Service Status page, or a variety of other notifications, these notifications are now context aware to what the facade represents. No more telling the Core Application users that the Reporting Engine users