On this post, we’re going to be getting into some talk about PaaS with Azure Stack, but before we get into that, let’s see where we’ve been thus far!
Our Microsoft Azure Stack Series So Far
- An Introduction to the Microsoft Hybrid Cloud Concept and Azure Stack
- How to Install the Azure Stack Development Toolkit (ASDK)
- The Ultimate Azure Stack Post-Installation Checklist
- How to Provide IaaS Images with Azure Stack
What is PaaS (Platform as a Service)
Now that we’re diving deeper into cloud technologies, we can easily recognize that Infrastructure as a Service is not the best use-case for getting the most out of Azure Stack. With what we’ve covered so far, Azure Stack can really be seen as just more VM technology behind Virtual Machine Manager (VMM). But Platform as a Service can really bring a more dynamic and elasticity capabilities to services running in your cloud. There is no need to manage the underlying infrastructure and is highly available by default in general.
Azure Stack PaaS is a special flavor because as of today the currently existing resource providers rely upon linking to an existing environment that could either be part of Azure Stack (if we talk about virtual machines that are responsible for the PaaS service itself) or a physical environment that sits outside of Azure Stack.
If you create a database “as a service” in Azure Stack, it will be deployed on this environment and you should take care to manage and back up the PaaS associated VMs themselves. They are not auto-deployed and self-managed like in Azure Public. So while they ARE providing PaaS services to those people and workloads connecting to them, you still need to manage them.
Another thing to keep in mind is that the PaaS solutions are not part of the default Azure Stack setup that is being deployed from the Hardware vendor (Remember that a true Azure Stack deployment will be handled by the hardware vendor), it is optional and needs to be ordered via separate SKUs.
PaaS Solutions in Azure Stack
Azure Stack as of today comes with the following PaaS solutions:
- Microsoft SQL Server
- MySQL Server
- App Services
If you deploy them using the Script from Matt McSpirit, they are part of the deployment by default. Please have in mind that the MS SQL and the MySQL resource providers have completely different APIs than the Azure ones. This means that your automation scripts behave completely different and consistency may be an issue currently.
Microsoft SQL Server on Azure Stack
As you can see, the underlying SQL Server infrastructure is a set of SQL Servers (up to release 2017) on Windows Server or even on Linux (if you’d like) for placement of you PaaS databases.
The deployment itself is being done using the DeploySqlProvider.ps1 script (from the resource provider link above), that performs the following tasks:
- Certificate and artifact upload to the Azure Stack storage account
- Publishing gallery items to be able to deploy SQL using the gallery
- Deploying the SQL resource provider VM which is a Windows Server 2016 core based one
- Registers a local DNS record that maps to your resource provider VM.
- Registers your resource provider with the local Azure Resource Manager for the operator account.
NOTE: Please keep in mind, that the registration of the SQL Server resource provider may take up to 75 min on the Azure Stack environment.
To double check if the deployment finished properly you should check this in the .system.
Finally, we will need to connect to the existing SQL Server environment (so-called hosting servers) to define the location for the created databases via this resource provider. Basically, we’ll be telling Azure Stack where to put new Databases when Azure Stack users request a new one!
You will find the entry for the SQL Hosting Servers under administrative resources and add new server environments:
Fill out the form as shown above.
After having created the corresponding SKUs, it may take up to 30 min to recognize and be able to use them in a proper manner in the environment.
You should now be able to create a first PaaS database using the wizard in the Azure Stack!
MySQL on Azure Stack
If you have a look into the deployment guide, you will shortly recognize that the deployment steps are quite like what we went through above for the Microsoft SQL Server resource provider. The name of the script meanwhile changed a little bit to DeployMySqlProvider.ps1 and even the deployment steps are the same.
Most of you know MySQL as a database environment sitting on a Linux operating system. This is where the resource provider is somehow different as it relies on Windows Server-based MySQL resources.
After having deployed the resource provider you could simply add the MySQL hosting server, define the SKUs and deploy the first databases on your MySQL server environment just like we showed for Microsoft SQL above.
App Services on Azure Stack
The App Services resource provider is one which should be quite familiar with what you may already know from public Azure.
The options with the App Services resource provider are:
- Web Apps
- Mobile Apps
- Function Apps
Therefore, the use-cases are a bit broader compared to the SQL options mention thus far.
Looking into the deployment guide, the setup is more GUI based and quite simple. You can run the deployment using the appservice.exe installer that collects all requirements and lets you define the required parameters before starting the installation itself.
The requirements besides a few basic parameters are:
- Microsoft SQL Database (e.g. via the MS SQL resource provider)
- Windows File Server
After the installation has finished, the appropriate resources will show up in the portal.
Having this done, the resource provider for App Services is up and running and can be used in your environment.
PaaS Use Cases on Azure Stack
After having installed all available resource providers for Azure Stack, you will be able to provide these services to your tenants using Plans and Offers. They are now able to deploy e.g. a WebApp as their services frontend with a SQL server-based backend.
Looking into hybrid cloud environments using Azure and Azure Stack, one part of the solution architecture may reside on Azure Stack (e.g. database) and the frontend on public Azure to be nearer to the customer itself or vice versa depending on the solution requirements. The only requirement would be again to have networking connectivity between both environments.
One other thing to note, regarding the Azure Stack Update cycles, you should have in mind that Azure Stack updates do not include updates for PaaS solutions. These need to be done manually and based on their availability. As the last months showed, the updates always included new features. So, I would say it is mandatory to follow the cycle. Regarding the update tasks, see the corresponding resource provider download as mentioned in this article. They should include a description and will show you how the update has to take place.
How are you liking Azure Stack so far? Have you found it easy to use? Difficult? Have you run into anything not covered yet in this series? We’d love to know in the comments section below.
Thanks for reading!
Go to Original Article
Author: Markus Klein