If you want to skip reading the text that follows and simply want to download Visual Studio Code Snippets for Azure API Management policies, click here.
Azure API Management gives you a framework for publishing your APIs in a consistent manner with built-in benefits like developer engagement, business insights, analytics, security, and protection. However, the most powerful capability it offers is the ability to customize behavior of the API itself. Think of the customization as a short program that gets executed just before or after your API is invoked. The short program is simply a collection of statements (called policies in Azure API Management). Examples of policies that come out of the box include format conversion from XML to JSON, applying rate and quota limits and enforcing IP filtering. In addition, you have control flow policies such as choose that is similar to if-then-else, or a switch construct and set-variable that allows you declare a context variable. Finally, you have the ability to write C# (6.0) expressions. Each expression has access to the context variable, as well as, allowed to leverage a subset of .NET Framework types. As you can see, Azure API Management policies offer constructs equivalent to a programming language.
This begs the question, how do you author Azure API Management policies?
Lift & Shift is an approach to migrating a legacy business application hosted in an on-premises data center environment to one hosted in the cloud. The goal is to move the application “as-is,” with little to no changes to the business functions performed by the application. One common lift and shift scenario is the migration of applications that were not originally developed for distributed cloud environments, but once moved, can take advantage of some of the benefits of cloud computing, such as increased availability and/or reduced total cost of operations (TCO).
This blog details some important considerations and challenges associated with the lift and shift method, based on our real-world experiences moving both custom and packaged (commercial) legacy applications to Microsoft Azure. Read More…
Visual Studio Team Services (VSTS) – formerly known as Visual Studio Online – is a SaaS offering of Visual Studio on Microsoft’s Azure platform. At its heart, the service is the cloud implementation of Team Foundation Services. Two of the service’s features, Continuous Integration and Release Management, were leveraged by AIS for a large federal client as part of a broader push for more streamlined DevOps practices.
Continuous Integration (CI) is a development practice where developers can integrate their changes into a shared code repository, which in turn triggers an automated build. This allows the development team to be quickly notified of any problems or errors caused by the checked-in change. VSTS’s Release Management Service allows developers to automate their deployment pipelines across any environment and platform – more than just .NET applications. For our federal client, the goal was to automate the entire continuous integration and release process for an ASP.NET Web API hosted in an Azure Web App. Since the client already had a subscription to VSTS, it was very straightforward for us to implement the entire solution within that one service. Read More…
MTConnect is the communication standard of choice for manufacturing. It allows organized retrieval of data from shop floor equipment in a structured XML.
The adjacent diagram depicts the key components of MTConnect. Let us start with the shop floor equipment shown at the bottom of the diagram – a CNC lathe. Above that, we have an optional adapter component that converts machine-specific data into a MTConnect defined format. The adapter component is optional as most manufacturers are building this capability directly into their machines. On the top is the agent component responsible for converting MTConnect data into XML. Additionally the agent also exposes a RESTful service that can be used to retrieve data. Read More…
Transient exception handling and retry logic are considered an important defensive programming practice, especially in the public cloud. But how good is your exception handling? Unfortunately, it’s not always easy to simulate transient exceptions.
It’s 2017 and it’s official: Government agencies want to move to the cloud. But they are often unprepared for the transition, or stuck in the middle of a confusing process. So this week, AIS and Microsoft kicked off the new year with a terrific AzureGov Meetup full of valuable information, training resources and demos on exactly where and how to start a successful government cloud journey.
Companies are adopting Docker containers at a remarkable pace and for a good reason – Docker containers are turning out to be key enablers for a micro-services based architecture.
As a quick recap, Docker containers are:
Encapsulated, deployable components that can run as isolated instances
Small in size with a fast boot-up time
Include tools that enable containerized application images to be easily moved across the public cloud and on-premises
Capable of applying limits on physical resources consumed by any given application
Given the popularity of Docker containers, it should come as no surprise that the Azure platform already provides first-class support for a container hosting solution, in the form of Azure Container Service (ACS). ACS makes it simple to create a cluster of Virtual Machines that can run containerized applications. ACS relies on popular open-source tools – with Docker as the container format, and a choice of Marathon, DC/OS, Docker Swarm and Kubernetes for orchestration and scheduling, etc. All this makes it possible to easily run containerized workloads on Azure in a portable manner.
But the Docker containerization story on Azure does not stop here.
It is also being weaved more and more into existing PaaS offerings, including Azure Batch, Azure App Service and Azure Service Fabric. Let’s briefly review the latest developments to see how Docker integrates with Azure PaaS: Read More…
This is an overview of a solution built by AIS with Microsoft for a federal client in the DC area. The client’s goal was to be able to automate the setup and takedown of virtual machine sandboxes on the fly. These sandboxes are used by the client’s developers to do security testing of their applications.
The first step of this project was to help the federal client provision their own Azure Government subscription, with some assistance from Microsoft. We then wanted to document the client’s on-premises environment so that it could be accurately replicated within Azure. The next step was to actually build and deploy the Azure services and scripts in the cloud environment. Lastly, we wanted to be able to define and implement automation use cases, such as the provisioning of an entire sandbox, or just specific machines within that sandbox. Read More…