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.
At a recent holiday dinner, a conversation with a friend eventually progressed to the topics of self-driving cars and facial-recognition software – and the overall roles and capabilities of artificial intelligence (AI). My friend’s assertion was that “AI is ultimately about pattern matching.” In essence, you equip the AI with a library of “patterns” and their corresponding associated actions. Based on the input it receives from the real world, the AI software program will then make an attempt to match the input to a stored pattern and execute the corresponding associated action.
Of course any program, regardless of whether it is designed to steer a car or detect a face in an image, relies on pattern-matching at the lowest level. That said, as we will see shortly, a deep learning-based approach is a fundamentally different way to solve the problem. And it’s an approach that is poised to reinvent computing. Read More…
With the explosion of new sensors and service offerings producing geospatial telemetry, there’s an ever-increasing need for tools to gain business insights from this data. One of the premier tools for this in the geospatial domain is GeoServer.
Fully open-source and free to use, GeoServer provides Open Geospatial Consortium (OGC) web service interfaces to rendering images or complete metadata in most common geospatial interchange formats. In a consulting capacity, Applied Information Sciences has leveraged Geoserver with great success, allowing us to deploy a complete software stack in minutes instead days or weeks. In this post I’ll give an overview of the DevOps practices we’ve applied to enable this capability, as well as a brief overview of the supporting technologies. Read More…
AIS recently worked with the General Services Administration (GSA) Technology Transformation Services Division, better known as 18F. The engagement involved working with 18F to digitize the Division of Labor’s Section 14(c) certification application process (part of the Fair Labor Standards Act). This is currently a paper-based process that 18F hoped to modernize as an intuitive, online application…and to do it using agile methodologies.
AIS was tasked with building the first version of the digital form within a 60-day period of performance – much shorter than typical federal contracts. AIS pulled together a multi-disciplinary team comprised of user researchers, designers, and front- and back-end web developers to work closely with 18F and the Division of Labor (DOL) Product Owner. The team built the entire form with complex validation along with a registration and login and an administrative section to process the form applications. They performed multiple usability tests with actual end users, and followed 18F’s principles of working in the open using a public GitHub repository. All User Stories and discussion threads were thoroughly documented in that repository’s issues list.
AIS was able to work together with many divisions inside DOL to make this happen. We addressed security concerns by the Chief Information Security Officer (CISO) and worked with the CIO office to coordinate delivery of the application and a testing and staging environment for deployment. We also set up a Continuous Integration/Continuous Deployment process so that multiple DOL stakeholders could stay abreast of what was happening and exercise the existing application state. We were even able to address legal concerns with testing by external citizens by getting signed consent forms for testing and recording the sessions.
The collaboration was so successful that our client wrote their own blog post on the project, detailing exactly “how government and private industry can work together using agile methodologies to produce great results.” You can read it here.
These types of successful, agile engagements break down the myths that software development for the government needs to take months (or even years). Government can and will move faster, and after every small win like this project, the traditional methods of building software and procuring software development are changing across the industry. This bodes well not just for the citizens who need to interact with these digital services… but also for saving our tax dollars.