Category: Architecture

ArchitectureDevelopmentInfrastructure

Happy 7th Birthday Microsoft Azure!

February 1, 2017 marks the 7th anniversary of when Microsoft turned on billing for the new Microsoft Azure service. Happy birthday Azure! Initially the service had a fraction of the features and services it has today. There’s been a tremendous growth on the platform over the years as a result of incredible investment by Microsoft.

Here’s a little timeline information about Microsoft Azure that you may or may not know:

  • October 2008  – At the Microsoft Professional Developers Conference (PDC), Microsoft Chief Software Architect Ray Ozzie announces a new cloud computing platform from Microsoft called Windows Azure. The initial announcement includes the Azure services of: Cloud Services, and Blob Storage.
  • March 2009 – Azure SQL Database service was announced.
  • November 2009 – An updated Windows Azure CTP is released enabling Full Trust, PHP, Java, including a CDN CTP and more
  • January 2010 – Windows Azure become Generally Available, currently free of cost
  • February 1, 2010 – Microsoft turns on billing and includes full SLA support making Windows Azure commercially available.
  • June 2010 – Windows Azure is updated with .NET Framework 4, OS Versioning, CDN, and SQL Azure update
  • October 2010 – At PDC conference Microsoft released platform enhancements, Windows Azure Connect, and an improved Dev / IT Pro experience
  • December 2011 – New services added: Traffic Manager, SQL Azure reporting, HPC scheduler
  • June 2012 – New services added: Azure Websites, Virtual Machines for both Windows and Linux, Python SDK, Locally redundant storage, and a new portal.
  • April 2014 – Microsoft renames Windows Azure to Microsoft Azure
  • 2014 to Present – MANY, MANY features and services are released!

Something not mentioned in the above timeline is the HUGE growth of Microsoft building out the data centers and backbone infrastructure that makes up the Microsoft Azure platform. From the initial launch of Microsoft Azure back in 2010, until now, Microsoft has grown the platform out to 32 regions today. They even have announced an additional 6 regions that are currently being planned or built.

Since 2010, Microsoft Azure has grown to be available in 32 regions around the world.

The overal size of Microsoft Azure has grown to be the biggest cloud platform on the planet. Microsoft may have been late to the game as Amazon got started 4 years earlier, but Microsoft has grown the platform to include more data centers and regions around the globe than both Amazon and Google combined!

azureofficialregionmap

You can view an interactive map of the Azure Regions here: http://map.buildazure.com

The Microsoft Azure platform has more data centers and global regions than both Amazon and Google combined!

The cloud brings with it some tremendous capabilities and capacity that most enterprises or even individuals could have only dreamed of having access to only a few short years ago. Microsoft is right there at the front of the stage rapidly releasing innovation after innovation in the Microsoft Azure cloud platform. Microsoft has been and still is betting the future of their enterprise business on the cloud, and Microsoft Azure is the way they are doing it.

Happy birthday Azure!

Happy birthday Azure! I can’t wait to see how you grow and advance cloud computing over the next 7 years and beyond!

ArchitectureInfrastructure

Microsoft Cloud Platform Roadmap

The Microsoft Cloud Platform roadmap provides a snapshot of what Microsoft is working on in their Cloud Platform business. You can use the roadmap to find out what they’ve recently made generally available, released into public preview, are still developing and testing, or are no longer developing.

azurecloudplatformroadmapsite

The Microsoft Cloud Platform Roadmap really gives you a nice view into the current state of many features and services within Microsoft’s overall Cloud Platform. However, it doesn’t give specific release dates as you might expect a roadmap to do, but it is organized well and easy to navigate. If you’re ever curious about the state of things or what upcoming, then the Microsoft Cloud Platform Roadmap is a nice place to go.

The Microsoft Cloud Platform Roadmap is broken out into the main categories (tabs at the top) of:

  • Recently Available
  • Public Preview
  • In Development
  • Cancelled
  • Archive

Within each category is the ability to filter the list of updates by a few subcategories, as well as the ability to select a filter to narrow down the list by a specific product. The list of subcategories (tabs on the left) are:

  • Cloud infrastructure
  • Enterprise mobility
  • Data management and analytics
  • Application development
  • Internet of Things

You can view the Cloud Platform Roadmap here: https://www.microsoft.com/en-us/cloud-platform/roadmap-in-development

ArchitectureInfrastructure

Azure Region Pairs Explained

Microsoft Azure is generally available in over 30 regions around the world. Each region is home to a vast array of servers hosted within 1 or more datacenters.. This is something that’s very apparent in Azure; especially since you need to choose a specific Azure region to host services in. However, something that’s not quite as apparent is the concept of Azure Region Pairs. Specific Azure regions are paired together. This article explains what Azure Region Pairs are, and the benefits that come within them.

What are Azure Region Pairs?

Microsoft operates Azure Regions all over the world. Each Azure Region is strategically placed within a specific geography, and almost all the Azure Regions are located within the same general geography as at least 1 other Region; it’s pair. The only exception to this is the Brazil South region currently, which is the only Azure Region in Brazil.

azureregionpairgeography

Read More

ArchitectureInfographic

The Polynimbus Cloud Enterprise

Many organizations are finding that they are integrating solutions across multiple cloud providers these days. Many complete systems are contained within a single cloud provider, but many different systems may be spread across  multiple cloud providers. We’re starting to enter a world of the Polynimbus Enterprise; an enterprise that uses 2 or more cloud platform providers.

What is a Polynimbus Enterprise?

Put simply, a Polynimbus Enterprise is an Enterprise that utilizes services from multiple cloud providers. Perhaps some applications are in Microsoft Azure, some in Amazon AWS, and possibly some are even in the Google Cloud. Poly-nimbus means “Many Cloud”.

Poly-nimbus Enterprise: An enterprise that utilizes multiple cloud providers

Many enterprises today are finding they are managing multiple software systems and/or databases hosted in different cloud providers. Maybe they started using Amazon AWS a couple years ago, but today find that certain parts of their business or IT team are hosting some applications in Microsoft Azure as well. This is very similar to the fact that many organizations have both Linux and Windows servers.

Polynimus and using multiple cloud providers is all about using the right tool for the job. Just as a certain programming language or development platform / tool is better for certain scenarios, a specific cloud may also be “just right” in certain cases as well.

Why Polynimbus?

There are many reasons to use multiple Cloud Providers, although in a perfect world you would only need 1 and possibly you can achieve this within your organization. However, many organizations are finding they are utilizing multiple cloud providers for a various of reasons. These reasons span from personal preference, to Manager oversight, to cost, and many others.

Here’s a few reasons why an organization may find themselves in a situation where they have applications spread across multiple cloud providers:

  • Talent Pool – Depending on who you’re able to hire you may find new hires know one cloud provider better than another, and possibly even a different cloud provider than your existing team. To reduce cost of training and get applications shipped to help the business or customer you may need to just accept a change in tooling to get the job done efficiently.
  • Legacy – You may be attempting to utilize a certain cloud provider more than another, but possibly you have Production systems that just can’t be moved from where they are. Many companies found this to be true when first moving to the cloud, and many are finding this true as they further embrace the cloud future.
  • Cost – Depending on your situation, you may find it cheaper to host and run a certain system in one cloud provider over another. This could possibly mean a shift from one preferred cloud provider to another.
  • Diversity / Avoid Cloud Lock-in – Some management teams or even entire organizations are finding it difficult to think about being locked into single cloud provider. As a result they are forcing their systems to be spread across different providers.
  • Contractors / Consultants – Perhaps a consulting firm or team of contractors is building applications and putting them in a different cloud provider. Whether you’re aware from day one, or find out once the product is delivered, you might find yourself at the end of the day supporting systems hosted within multiple cloud providers.

As you can see, these are some very compelling reasons why an enterprise would become Polynimbus. In fact, these are the same reason why organizations and teams choose to end up using and supporting applications using many different technologies over time. It’s just something that’s inevitable in the IT field, and the Cloud is no different as we are finding out.

Polynimbus Considerations

As an enterprise / organization or IT team is finding themselves adopting multiple clouds, there are a number of considerations to think about or at least be aware of. Here’s a short list of some of these considerations:

  • One App, One Cloud – It’s best not to spread different components of the same application across multiple cloud providers. This can lead to increased network latency for API and database calls, as well as incur an increase in Ingress and/or Egress charges when transferring data in and out of the cloud data centers.
  • Global Availability – It’s possible by leverage multiple cloud providers that you could achieve a greater level of global availability of your application for your users. Perhaps by distributing the load across multiple instances in multiple clouds you could better place instance endpoints closer to your end users.
  • Training – By managing systems spread across multiple cloud providers there is most likely going to be an increase in the training costs for your IT team. After all, many of them will need to know enough and be familiar enough with each cloud provider to be able to jump over and help out with updates and maintenance of various enterprise systems that may be running on different cloud providers.
  • Lock-in – By spreading applications and system across cloud providers, you are making it easier to migrate over and away from one cloud provider over another. Likewise, you are also making it much more costly to operate than if you had just chosen and stuck with a single cloud provider as a standard for your organization.
  • Flexibility – By forcing your organization or IT team to support applications across multiple cloud providers you ensuring a greater level of flexibility on your team to be able to update, maintain, or build a green fields application on either of the cloud providers you are currently supporting / using.
  • Hiring – While utilizing multiple cloud providers will likely open up the prospective employee pool, it will also make it tricky to hire talented people who know exactly what your organization needs. It’s difficult to find the perfect candidate in general, but the more technical skills you add to the “helpful” section of the job listings, the more difficult you may find it to hire the right people. You may end up listing multiple job postings for the same job but list one for each cloud provider you are using just to hopefully find a candidate that knows one of the cloud providers you need expertise in.
  • Migration – Just as going all in on a single cloud provider may prevent you from migrating to another, if you have applications spread across multiple cloud providers, you may still find things just as difficult if you find your team in a position that requires an application to me migrated from one cloud provider to another.

The above list is not all inclusive and there are likely a few more considerations to keep in mind. Don’t be afraid to go Polynimbus and use the right tool for the job!

ArchitectureInfrastructurepricing

Static Website Hosting in Azure Storage

Traditional shared hosting providers generally cost anywhere between $8 – $10 USD per month. The reason is you need to reserve some CPU and Memory resources on a VM to host your website. These are very useful for hosting dynamic web sites or applications with small amounts of traffic. However, if you have a static website then you don’t need CPU and Memory on a VM, all you need is storage and bandwidth. Since hosting a static website or static front-end to an API powered web application only requires storage and bandwidth, it makes Azure Storage a perfect service to host such a website. In this article I’ll explain what’s necessary to host static website in Azure Blob Storage, then I’ll show how you can estimate the hosting cost of the site as well. (Hint: It’s really cheap!) Read More

ArchitectureCertificationDevelopmentInfrastructure

Microsoft Azure Certification Exams Get Major ARM Refresh

Over the last 2 years, since the 3 core Microsoft Azure certification exams were originally published there have been a tremendous amount of changes to the Microsoft Azure platform and ecosystem. These 3 core exams targeted towards Architecture, Infrastructure, and Developer roles were originally published before Azure Resource Manager (ARM) existed and fully covered Azure Service Manager (ASM). Not only has ARM been released since then, but also a very large number of new Microsoft Azure services have been released too! Newer services like Azure Functions, Logic Apps, DocumentDB, and others weren’t covered on these original exams.

However, these core Azure certification exams have been updated a couple times over the last 2 years. This has kept them relevant over the years, but the most recent previous update was published in March 2016, and it didn’t even full cover Azure Resource Manager (ARM) as well as a few other features and services. Since that latest update was about 8 months ago, it really is time for another refresh, and hopefully one that add much more than the last.

Luck is in our favor, as Microsoft will be publishing another new update / refresh to these 3 core Microsoft Azure certification exams on November 22, 2016. This update will include major ARM updates, including the removal of the old Azure Service Management (ASM) APIs, as well as the inclusion of Azure Functions, Logic Apps, DocumentDB, and other newer Azure services.

Microsoft will be publishing another new update / refresh to these 3 core Microsoft Azure certification exams on November 22, 2016.

For a full listing of the new exam objectives on these exams, see these links:

In addition to these 3 core Microsoft Azure exams, there have been 2 additional Big Data focused exams released. These 2 exams have been out for about a year now, and are not getting updated right now. I would expect these to be updated sometime in the next few months, perhaps. Here’s links to further information on these 2 Big Data focused exams:

Also, Microsoft recently announced some major changes to the Microsoft Certification program that greatly embeds the Azure exams into the various certification tracks. Along with these announcements was the release of the brand new Microsoft Certified Solutions Expert (MCSE): Cloud Platform and Infrastructure certification,and a few Microsoft Certified Solution Associates (MCSA) certifications it builds on top of.

There’s been lots changing technology-wise, as well as many major certification changes lately!

Happy studying!

ArchitectureCertification

Azure Architecture Exam (70-534) Gets ARM Refresh

Spec_Arch_AzureSol_logo_BWIt’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.

Retired Exam: This exam is being retired December 31, 2017, and is being replaced by Exam 70-535: Architecting Microsoft Azure Solutions. The exam content will be similar but different enough that Microsoft is giving it a new number to differentiate it more clearly. Read More

Architectureserverless

What is Serverless Architecture?

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

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.

Event Driven

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.

serverlessarchitecture_httprequestresponse

Functions of code hosted in Serverless architecture are bound to specific events that fire them off and execute them when necessary.

Pay-per-Use

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.

Scalability

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!

 

ArchitectureInfrastructure

Manage Azure App Service Deployments with Deployment Slots

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.

azureappservice_portal_deploymentslots

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

azureappservice_portal_deploymentsloturl

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.

Staged Deployment

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.

Incremental Deployment

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.

Rollback Deployment

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.

ArchitectureDevelopmentInfrastructure

Fixing Azure Portal Errors

All software has errors. The Microsoft Azure Portal is no different. When this happens you’ll receive one of two different alerts of the error; either an error message or a rain cloud. It’s easy to have a “table flip” moment when this occurs and start grumbling how “the cloud is horrible” or “why Azure sucks”, but there’s generally an explanation for these errors and they normally don’t last long. This post explains a bit of why these errors occur, when they’re more likely, and how to fix / workaround them. Read More