This course covers the Design advanced applications part of the 70-534 exam, which is worth 20–25% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam.
Welcome back. In this lesson we're going to talk about how hybrid solutions require some different patterns for accessing and sharing data than purely on-prem or purely cloud-based applications.
Cloud migrations can be slow going. There are a lot of things to consider and a lot of moving parts so hybrid solutions aren't uncommon. That means as companies move to the cloud, they'll need ways to start extending on-prem solutions with cloud-based options.
Suppose you have a WCF service inside of your company and it's behind the firewall. And now you need to invoke it from some cloud-based service, but you don't want to expose it directly to the internet. So, how do you go about doing something like that. This is what Azure Service Bus is for.
Azure Service Bus is a messaging infrastructure that works as a relay. It can allow you to create bidirectional channels for exchanging data. When Service Bus receives a message it will relay the message to the on-prem bidirectional socket that has already been opened by the service.
If you already have a WCF endpoint, you don't need to change anything in the implementation, though, what you need to do is configure the netTCPRelay endpoint. And WCF will do all the work of establishing a two-way socket connection to the service bus.
On the WCF service, you don't need to worry about security because you can securely control access to the services directly from Azure Service Bus. Service Bus is going to allow us to have a relay between our on-prem services and our Azure-based services. This allows us to call existing on-prem services from Azure based things such as a web app.
This is a very easy way to start building out new solutions in Azure that use existing on-prem resources. At a code level if you're using dependency injection to inject our implementation of a given service, we can ensure that there's minimal code refactoring when it comes to porting the on-prem version of the resource to Azure.
Not all applications will connect with WCF services, so it's going to exclude using Service Bus Relay for some cases. That may mean that we need to expose on-prem services or resources in a secure way. Let's say for example, SQL server. In this scenario we can use BizTalk API Apps, which can establish, publish and control hybrid connections to on-prem TCP services.
And we can define and manage those connections from the portal. To use this, you're going to need to install the Hybrid Connection Manager and on-prem software daemon that will allow us to have a bridge between Azure Services and internal services.
You're gonna need to bind some additional ports outside the ports used by the services, it's going to use port 80 for certain validation, it's going to use 443 for HTTPS, it's gonna use 5671 to connect to Azure and 9352 to push and pull data.
This sort of thing is useful for connecting web or mobile apps to on-prem databases. And speaking of web apps, we can configure a web app to access a Virtual Network, which doesn't move the web app inside of the Virtual Network, though it can access resources inside of it.
And if the Virtual Network is connected to our on-prem network through a site-to-site VPN, then that web app can access our on-prem resources as well and the same applies to ExpressRoute connections. Now this is going to be a viable option for some scenarios, however it can also open some security concerns.
This sort of setup should be reviewed by a member of your InfoSec team before setting up. Also, keep in mind that there are some limitations with the VPN. A Virtual Network can establish connections to ten networks. In particular it can connect to six on-prem networks and four other Virtual Networks.
Now if none of these options meet your need for sharing data, you can allow Cloud Services and Virtual Machines to domain-join. This is useful to limit access to users that are already present on the domain controller.
There are two main methods to domain-join Cloud Services. The first is to use PowerShell scripts configured as a startup task or if the domain-joining operations you need aren't available in PowerShell, you can execute them in code inside of the Cloud Service role entry point. A Virtual Machine can domain-join in two ways as well. You can manually do it from the Windows UI, adding a computer to the network.
And the other way is through PowerShell. And this can be executed during the VM creation automatically running after the machine completes its deployment. This is the cloud friendly infrastructure as code way to do it.
Alright, that's gonna wrap up not only this lesson, but the entire course. In the next course, we'll continue the next domain objective, which covers web and mobile applications. So, if you're ready to keep learning, then I'll see you in the next course.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.