What Are Logic Apps -- For IT Pros
In this post, aimed at IT pros, I’ll explain how Azure’s Logic Apps service can be used to orchestrate activities in the platform-as-a-service (PaaS) side of Azure.
Once upon a time, Logic Apps would have been something for the developers. But times, and Azure, are changing. More and more organizations are embracing the work methodologies of DevOps, where IT pros and developers work as a coordinated team, instead of the traditional one-versus-the-other. In the DevOps world, the traditional IT pro (the operator) needs to understand the architectures being used by developers so that they can function as an integrated team.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Recently, Logic Apps popped over into the infrastructure side of Azure by appearing as “Playbooks” in Azure Security Center. Playbooks, which are a use of Logic Apps, allow you to define automated actions to security alerts: when an alert occurs, do one or more things automatically.
So knowing that Logic Apps are creeping into our world, it makes sense to know what they are for and what they can potentially do.
In the developer side of Azure, each of the resource types that you deploy can be very role-specific. For example, one might have an app service plan that hosts a scalable website. Behind that, there might be a blob storage account that stores customer uploads. Whenever a customer uploads a file, a series of parallel actions might need to be triggered. Notifications might need to be sent to internal sales/marketing staff of customer actions, confirmations might need to be sent to customers, and actions might need to be coordinated to consume/process the data. In the real world, errors might occur, so there must be some sort of error handling.
What I’ve given you is a brief overview of is a workflow: something happens and then a set of follow-up steps, optionally with conditions, will be triggered. This is the role of a Logic App in Azure; it is a coordinator of actions. One could think of Logic Apps as a supervisor or traffic coordinator, making sure that the otherwise separate resources of Azure that carry out tasks in a service function together, applying the desired logic of the architecture.
Microsoft’s documentation refers to Logic Apps as being iPaaS or integration Platform-as-a-Service. The “i” in iPaaS indicates the strength of Logic Apps; not only are Azure systems integrated but external and third-party systems can be included in your Logic Apps, including Twitter, Slack, Office 365, and many others. This integration is done using a set of Microsoft-provided connectors. However, if a connector does not exist, then you can still integrate your logic app to external systems via their APIs.
Logic Apps might sound familiar; Some plans of Office 365 includes a feature called Flow, which is the end-user version of Logic Apps.
One of the nice things about Logic Apps is that you can derive a lot of value from this service in Azure without writing a single line of code. Logic Apps are created in the Azure Portal using a GUI tool called the Logic Apps Designer.
You can use an existing template, modify a template, or start from scratch. You can sign into external services, configure data, connect tasks together, set condition criteria, and so on, all in this GUI tool. I suspect that many IT pros will find easy solutions for their customers/employers in the templates that will solve long-standing problems … or make complicated scripts redundant!