Saturday, April 08, 2017

Flow vs Logic Apps vs Functions vs Webjobs

Azure Functions or WebJobs
All these services are useful when "gluing" together disparate systems. They can all define
  • input
  • actions
  • conditions
  • output
You can run each of them on a schedule or trigger. However, each service has unique advantages, and comparing them is not a question of "Which service is the best?" but one of "Which service is best suited for this situation?" Often, a combination of these services is the best way to rapidly build a scalable, full-featured integration solution.

Flow vs. Logic Apps
Microsoft Flow and Azure Logic Apps are both configuration-first integration services. They make it easy to build processes and workflows and integrate with various SaaS and enterprise applications.
  • Flow is built on top of Logic Apps
  • They have the same workflow designer
  • Connectors that work in one can also work in the other
  • Flow empowers any office worker to perform simple integrations (for example, get SMS for important emails) without going through developers or IT. Flow is for Office workers and business users  as a self service tool.
On the other hand, Logic Apps can enable advanced or mission-critical integrations (for example, B2B processes) where enterprise-level DevOps and security practices are required. It is typical for a business workflow to grow in complexity over time. Accordingly, you can start with a flow at first, then convert it to a logic app as needed. Logic apps are for IT pros and developers used for mission critical operations.

Functions vs. WebJobs
Azure Functions and Azure App Service WebJobs are both code-first integration services and designed for developers. They enable you to run a script or a piece of code in response to various events, such as new Storage Blobs or a WebHook request. Here are their similarities:

  • Both are built on Azure App Service and enjoy features such as source control, authentication, and monitoring.
  • Both are developer-focused services.
  • Both support standard scripting and programming languages.
  • Both have NuGet and NPM support.

Functions is the natural evolution of WebJobs in that it takes the best things about WebJobs and improves upon them.

The improvements include:
  • Streamlined dev, test, and run of code, directly in the browser.
  • Built-in integration with more Azure services and 3rd-party services like GitHub WebHooks.
  • Pay-per-use, no need to pay for an App Service plan.
  • Automatic, dynamic scaling.
  • For existing customers of App Service, running on App Service plan still possible (to take advantage of under-utilized resources).
  • Integration with Logic Apps.
Functions support in-browser editing where as web jobs doesn't support in browser editing.

Both can be invoked by Event Triggers and Timer based Scheduling. We can make web jobs as continuous.
Functions support more event triggers than Webjobs , Functions support
  • Timer
  • Azure Cosmos DB
  • Azure Event Hubs
  • HTTP/WebHook (GitHub, Slack)
  • Azure App Service Mobile Apps
  • Azure Notification Hubs
  • Azure Service Bus
  • Azure Storage
Webjobs support
  • Azure Storage
  • Azure Service Bus
Flow vs. Logic Apps vs. Functions
Which service is best suited to you depends on your situation. For simple business optimization, use Flow.If your integration scenario is too advanced for Flow, or you need DevOps capabilities and security compliances, then use Logic Apps.
If a step in your integration scenario requires highly custom transformation or specialized code, then write a function and trigger the function as an action in your logic app.

You can call a logic app in a flow. You can also call a function in a logic app, and a logic app in a function. The integration between Flow, Logic Apps, and Functions continues to improve over time. You can build something in one service and use it in the other services. Therefore, any investment you make in these three technologies is worthwhile.

Saturday, April 01, 2017

DirSync vs Azure AD Sync vs Azure AD Connect

DirSync, Azure AD Sync and Azure AD Connect are used to sync on-premises Active Directory to cloud based directory service like Azure AD instance, Office 365, Dynamics Online and other Microsoft Cloud Services

All are used for Single Sign-On (SSO) and user can use the a single user account and password to access there cloud based application on Office 365, Dynamics Online and Azure AD, we can synchronize user account and there passwords

Single sign-on (SSO)
Single sign-on (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. The service authenticates the end user for all the applications the user has been given rights to and eliminates further prompts when the user switches applications during the same session. On the back end, SSO is helpful for logging user activities as well as monitoring user accounts.
Example : Microsoft, Google (if you sign into email, you can also access other applications with out entering username and password.) . To make it more secure , service providers are using Multifactor authentication where required.

DirSync
DirSync to sync your local on-premises Active Directory with cloud based services. dirsync doesn’t support multi-forest environments.


Azure AD Sync
Azure AD Sync is advance version of DirSync, it support most of the functions of traditional DirSync, and adds extra functionality such as mutli-forest support and password write back. It’s more flexible then Dir Sync

Azure AD Connect
Azure AD Connect will integrate your on-premises directories with Azure Active Directory. This allows you to provide a common identity for your users for Office 365, Azure, and SaaS applications integrated with Azure AD.
Azure AD Connect has many of the same features as DirSync and Azure AD Sync, its going to replace DirSync and Azure AD Sync and it has plans for many other features such as non-AD LDAP support.
Azure Connect is recommended for larger organizations that have greater flexibility requirements, it provides consistent experience in hybrid environments that may or may not entirely utilize Microsoft on premise solutions


Why use Azure AD Connect?
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. This is a great time to upgrade to Azure AD Connect from Windows Azure Active Directory Sync (DirSync) or Azure AD Sync as these tools are now deprecated and will reach end of support on April 13, 2017.
Integrating on-premises directory service with Azure AD makes your users more productive by providing a common identity for accessing both cloud based and on-premises service and application.


Advantages:
  • Companies can provide users with a common hybrid identity across on-premises or cloud-based services with Windows Active Directory and then connecting to Azure Active Directory.
  • Administrators can use multi-factor authentication to provide conditional access based on application, device and user identity, network location and many more.
  • Users can use their user accounts in Azure AD to access Office 365, Microsoft Intune, SaaS apps and any other third-party applications.
  • Application can be developed with common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure Active Directory Connect Sync
The Azure Active Directory Connect synchronization services (Azure AD Connect sync) is a main component of Azure AD Connect. It takes care of all the operations that are related to synchronize identity data between your on-premises environment and Azure AD. Azure AD Connect sync is the successor of DirSync, Azure AD Sync, and Forefront Identity Manager with the Azure Active Directory Connector configured.

Azure AD Connect and federation
Azure Active Directory (Azure AD) Connect lets you configure federation with on-premises Active Directory Federation Services (AD FS) and Azure AD. With federation sign-in, you can enable users to sign in to Azure AD-based services with their on-premises passwords--and, while on the corporate network, without having to enter their passwords again. By using the federation option with AD FS, you can deploy a new installation of AD FS, or you can specify an existing installation in a Windows Server 2012 R2 farm.