It’s been about 2 years since the 70-534 Architecting Microsoft Azure Solutions certification exam was first release. Over that time there’s been a couple updates to keep it relevant with the ever changing landscape of the Microsoft Azure platform. The previous update was released in March 2016, which is a very long time when it comes to the cloud. The good news is that another update is on it’s way, and this time it will be including a full update of adding Azure Resource Manager (ARM) to the exam, in addition to many other new features and services. This update looks to be bringing the 70-534 Architecting Microsoft Azure Solutions exam back to relevancy and not so outdated as it’s been for nearly an entire year now. Read More
One of the latest moves by cloud service providers (like Microsoft Azure and Amazon AWS) is the shift to offering “serverless” services. These are Platform as a Service (PaaS) services that take the “fully managed” aspects of the service to the max. Serverless service offerings (such as Microsoft Azure Functions) allow for individual code functions to be deployed and managed without the need to deploy and manage the underlying Virtual Machine (VM), including even the applications that hosts the functions too! Additionally, the billing of Serverless architecture only charges you when your code is running, instead of paying to keep the underlying server resources reserved and available. This article will dig into Serverless Architecture, and help clear up many of the common questions surrounding this “Platform as a Service to the MAX” technology.
Serverless architecture isn’t really to host applications without servers. Of course there still needs to be CPU, RAM, Networking and other components of a computer server in order to host any software. Rather, Serverless really is about taking Platform as a Service (PaaS) to the max!
Serverless is about taking PaaS and turning it up to 11!
Modularity & Flexibility
Platform as a Service (PaaS) abstracts away the underlying hardware and infrastructure so that application code can more easily be hosted, deployed, and managed with much less overhead than traditional hosting. Serverless architecture takes PaaS to the most extreme, by fully abstracting away the server in such a way that a single function of code can be hosted, deployed, run, and managed without even having to maintain a full application.
Each function of code for a back-end systems Web API or Background Processes can be managed individually with Serverless architecture. This helps make systems much more modular, as well as increasing the overall system flexibility. This enabled modularity is ideal for Micro-Services based systems as well.
With the modularity of hosting individual Functions of code comes with it added flexibility. Not flexibility in the Function, but rather flexibility in writing, maintaining, and deploying code. Each Function can be maintained, updated, and deployed individually. This mean that each Function can be updated and deployed in isolation without the risk of taking down other Functions in order to do so.
Functions in Serverless architecture can almost be thought of as “mini-programs” that are maintained by themselves.
Just as a Function of code within an application, in Serverless architecture there needs to be something to trigger the code to run and subsequently return a result. The entry points to execute Functions of code hosted in a Serverless architecture are built around events. This Event Driven (or Event-based) design of Serverless architecture is ideal since Functions of code are hosted as individual items.
Functions of code hosted in Serverless architecture are bound to specific events that fire them off and execute them when necessary. Here’s a few examples of events that can be used to trigger the execution of Functions of code in Serverless architecture:
- HTTP / HTTPS Request
- Message Queue Trigger
- File / Storage Trigger
- Timer / Schedule
An HTTP / HTTPS Request trigger can be used to expose a Function of code as a Web Service / API of some kind. For example, it could be used to expose a REST API endpoint that performs an action and returns a JSON response. This type of usage would allow for a Serverless implementation of a Web API without the need to build a larger application / infrastructure to host it.
Functions of code hosted in Serverless architecture are bound to specific events that fire them off and execute them when necessary.
The possibilities of pricing Serverless architecture differently is possible due to it being based around an Event Driven model. Other more traditional Platform as a Service (PaaS) allow for reductions in hosting and ownership costs by abstracting away many manual tasks necessary for general server maintenance and deployment. In a way traditional PaaS is “serverless”, but not completely.
Full Serverless architecture hosting services allow for an even greater abstraction of the underlying hardware, Virtual Machine (VM), and infrastructure than traditional PaaS offerings. Since these things are abstracted away as much as possible with Serverless architecture, it enables the Functions of code to be hosted in a way that can better utilize the underlying CPU/RAM hardware with multi-tenancy. Due to this, the cost of Serverless services provide even greater cost savings over traditional PaaS services.
Multiple clients Functions of code can be hosted on the same hardware and/or Virtual Machine (VM) with the ability to host Serverless architecture services in a multi-tenant manner. This allows Cloud Service Providers, like Microsoft Azure, to even further utilize their CPU/RAM and other server hardware to their capacity. This is done by pooling Functions of code / applications from multiple clients (tenants) on the same hardware.
Since Serverless architecture is best hosted in a multi-tenant manner (as described above) the majority of service providers bill Serverless services out on a “Pay-per-Use” basis. Without a full VM, CPU/RAM allocation being billed and paid for to be reserved / available, it doesn’t make sense to bill clients for a full VM instance. Instead, Serverless cloud services (like Azure Functions) are billed by keeping track of the total CPU and other resources used solely during Function code Execution.
Pay-per-Use serverless architecture billing is simplified that charges are only incurred if and when the Functions code is actually executing. When an event triggers the Function to execute, the resources consumed by the Function of code are tracked and billed. When the Function of code is NOT executing, then no costs are incurred.
The billing of Serverless architecture only charges you when your code is running, instead of paying to keep the underlying server resources reserved and available.
With the multi-tenant nature of Serverless architecture, it’s possible for the underlying platform to host and run each Function of code for a particular client on completely disparate hardware and Virtual Machines (VMs) completely unbeknownsed to the client. This method of hosting makes if ideal for automatic scalability.
Serverless architecture services are able to utilize their “Platform as a Service (PaaS) to the MAX” nature to better optimize scalability than traditional PaaS services. In addition to potentially hosting each Function of code on different underlying servers, there could also be multiple instances of each Function of code hosted across multiple underlying servers as well. This allows a Serverless platform (like Azure Functions) to automatically scale out to the maximum degree.
Serverless architecture services are able to utilize their “Platform as a Service (PaaS) to the MAX” nature to better optimize scalability than traditional PaaS services.
Serverless in Microsoft Azure
The service offering in the Microsoft Azure cloud platform is the Azure Functions service. Azure Functions allow for Serverless architecture to be built out on the Microsoft Azure platform. It also supports many different platforms and frameworks, like .NET, Java, Python, and Node.js. Azure Functions are extremely flexible where Functions can easily be authored in .NET or Node.js directly within a web browser. Azure Functions can even be built as a console applications or entirely as shell scripts.
The next wave of Platform as a Service (PaaS) is here, and it’s Serverless Architecture!
Every App Service resource in Azure has the ability to have multiple deployment slots configure. These deployments slots are a feature than can greatly help with the implementation of streamlined testing, staging, and deployment process. Along with the ability to configure multiple hosting environments, the use of Deployment Slots enables zero downtime when deploying application changes, or even rolling back a failed deployment.
Creating Deployment Slots
Deployment slots are a feature of Azure App Service Plans. As a result, every App Service resource (Web App, Web API, Mobile App) in Microsoft Azure has the ability to create up to 4 additional deployment slots with the Standard tiers, and up to 20 deployment slots with the Premium tiers.
Each App Service (in Standard tiers) can have up to 4 additional Deployment Slots in addition to the Production slot.
Each Deployment Slot allows for a separate instance of the application to be hosted in isolation from the other deployment slots and production slot of the App Service. The VM behind each Deployment Slot is the same VM Instance that hosts the production deployment slot. This means that the App Service and 4 additional Deployment Slots will all be hosted in and share the same VM Instance and resources.
To create App Service Deployment Slots in the Azure Portal, just navigate to the App Service, select the Deployment slots section and click the Add Slot button to create a new Deployment Slot.
Additionally, in order to use the Deployment Slots feature of Azure App Service, the pricing tier must be either Standard or Premium. The Free, Shared, and Basic pricing tiers do not support deployment slots.
It’s important to keep in mind that all Deployment Slots share the same VM Instance and server resources.
Deployment Slot URL / Endpoint
Azure App Service applications get a unique URL that is made up of the App Service Name as the subdomain of the azurewebsites.net domain. In the above screen shot, the App Service Name is “testapp2063” which means the URL / endpoint for the Production slot of the App Service is located at testapp2063.azurewebsites.net.
When creating Deployment Slots each slot gets it’s own URL / Endpoint. The endpoint for each deployment slot derives from the endpoint for the Production slot by appending the name of the deployment slot with a hyphen.
With an App Service named “testapp2063” the URL / Endpoint for the following deployment slots will have the following values:
- dev => testapp2063-dev.azurewebsites.net
- test => testapp2063-test.azurewebsites.net
- stage => testapp2063-stage.azurewebsites.net
Deployment Slot Swapping
Swapping Deployment Slots is the method of copying the currently deployed application code and settings of one deployment slot and swapping it with another. Swapping allows for the deployment of application code to be done from one environment to another very quickly. It also allows for a couple new deployment techniques that didn’t exist in traditional server hosting.
To swap Deployment Slots from the Azure Portal, just navigate to the list of Deployment Slots for an App Service or navigate to the specific Deployment Slot that needs to be swapped. Then, click the Swap button and specify which Deployment Slot to swap with. See the above screenshots for reference of where the Swap button is located within the Azure Portal.
When an application is deployed using Deployment Slot swapping, there is zero downtime
When an application is deployed using Deployment Slot swapping, there is zero downtime of the application. The way this is implemented is by just rerouting the Deployment Slot Endpoint between the Deployment Slots being swapped. Both deployment slots remain running and actively responding to client requests throughout the swap.
The technique of performing a Staged Deployment allows for application code to be deployed to a non-production deployment slot (such as one named stage) to test or verify functionality is working as expected. Then once everything has been verified, the Stage deployment slot can be swapped with Production making the staged application deployment the new Production instance of the application.
There are times when deploying application changes might require additional changes other than just deploying the latest code. These requirements could be running SQL scripts or some other post deployment step necessary to fully deploy the latest code. Deploying to a Stage deployment slot can allow for these Incremental steps to be performed after the code is deployed in a way that can be tested and verified before deploying to production.
Every once in awhile a deployment fails for some reason. Maybe files end up corrupt, a major bug is found, or some other reason for failure. In these cases, it’s necessary to rollback a deployment. Using Deployment Slots, a deployment can be rolled back easily buy just swapping the Deployment Slots back.
Basically, swap Stage with Production to deploy new changes. When a major bug is found that requires a rollback, then the Production and Stage Deployment Slots can be swapped back. This allows for the old application code to be rolled back into Production in a matter of minutes. This leads to greatly decreased downtime in the event of a deployment failure.
Blog articles and Technical documentation are nice for learning technologies, but there are times when a good book just can’t be replaced. This is especially true when getting information from blogs that may have a snippet of “found code” that might or might not work as expected. At least properly technically reviewed book will have working code snippets and other directions / information.
So, here’s a bunch of eBooks on Azure topics that are available for the Amazon Kindle. After all, what better to read about the Cloud than with a “Virtual” book! Read More
The “Planning and Preparing for Microsoft SharePoint Hybrid” eBook from Microsoft Press has been made freely available for download. This book is written by Jeremy Taylor. This is part of a series of books covering SharePoint Hybrid solutions from SharePoint on-premises to Microsoft’s cloud services. Topics covered include: foundational topics with Office 365 and Microsoft Azure, architecture planning, platform hygiene and preparation, directory synchronization, as well as how to configure a seamless single sign-on (SSO) experience for users. Read More
Curious about how to design applications for the cloud? The Cloud Design Patterns infographic from Microsoft provides a nice reference of cloud architecture design patterns. This infographic depicts the most common problems in designing cloud-hosted applications, and it provides some design patterns to offer guidance to help you design better cloud-hosted applications within Microsoft Azure!
You can download the full infographic PDF at the following URL:
It’s the middle of a war… The cloud war! Ok, not nearly as dramatic as a real war (thankfully!) but still just as intense as the browser wars in the early days of the Internet. One of the difficulties in navigating the features of each cloud provider is the ability (or lack of…) to be able to compare what feature is equivalent from one cloud provider to another. This is especially difficult with new feature announcements and updates coming out weekly! The pace has picked up, and it’s extremely difficult to keep up with!
There are very similar and some almost identical features of each Microsoft Azure and Amazon Web Services. Each company uses different names for each feature set that really are NOT simply Microsoft SQL vs Amazon SQL. Because of the naming and feature differences, this is extremely difficult to navigate when attempting to compare a Microsoft Azure product page to an Amazon Web Services product page. Read More
Microsoft Azure has tons of data centers and region. At the time of writing this, Azure is made up of 24 regions with more, new regions announced coming soon. In fact, Microsoft Azure is bigger than both Amazon’s and Google’s cloud services combined!
Microsoft Azure also has a ton of features, however, not all features are available in every data center. The majority of features are, but some are not. To help determine which Azure features are supported in each region, Microsoft has a “Services by Region” page available. This page allows you to easily see which Azure features are available in which regions, and can really help in planning out what regions and data centers you’re going to deploy to in the Microsoft Azure cloud.
The Azure Services by Region page can be found here:
The Microsoft Azure cloud platform is really big with tons of features, plus Microsoft keeps adding more, and more, and more all the time. The technology industry can generally be difficult to keep up with, and all that is in Microsoft Azure can be just as difficult to keep track of. With the help of Ricardo Niepel and his Interactive Azure Platform Big Picture graphic / website it’s easy to see all the big features that make up Microsoft Azure. The interactive part is where you can click on a feature to see a short description, as well as links to documentation and pricing to dive in further.
The below image is a screenshot, clicking on it will bring you to the website. Enjoy!