As 2017 ends, it’s clear that while the enterprises (public sector and commercial) are increasingly moving to the public cloud, they face significant challenges. Earlier in the year, I wrote about bridging the chasm between the expectations from an enterprise regarding cloud capabilities and the actual out-of-the box features offered by cloud providers. Additional challenges include the foundational culture shift to cloud governance, DevOps and automation, security and compliance, and mapping an enterprise’s application portfolio to a complex array of cloud service options.

Here are five things you can do next year to better assist enterprises adopt the public cloud: Read More…

Microsoft AppSource is a great destination for discovering line-of-business SaaS offerings, ISV apps and services offered by SIs. Today, we are proud to announce that the AIS Service Catalog (ASC) is now available in AppSource.

You can now get started with ASC in just minutes by clicking here – simply login to AppSource and then onboard your Azure subscription to ASC. You can leverage ASC as a SaaS or deploy a dedicated instance of ASC inside your subscription. Please feel free to contact us for more information.

We believe that Service Catalog is an important part of any Enterprise DevOps Toolchain. This is why, after years of guiding enterprises and government agencies through their journey to Enterprise Cloud DevOps, we built ASC as a Service Catalog for Azure.

In a nutshell, ASC allows developers to quickly provision enterprise-approved resources in Azure. ASC’s features and key benefits can be broken into two high-level areas: Read More…

Copyright: <a href='https://www.123rf.com/profile_viktorus'>viktorus / 123RF Stock Photo</a>

I thought Per Werngren made some important observations in his recent article for Redmond Channel Partner Magazine. His main point: System Integrators (SIs) need to evolve their business models or risk disintermediation. As workloads are migrated to AWS and Azure, automation replaces the need for people to perform those tasks. This automation enables governance and compliance to standards, while also setting the stage for better downstream, fully-automated management, monitoring and operations. This, of course, further reduces the need for people performing in those roles,

Meanwhile, the new generation of intelligent PaaS services for predictive analytics, artificial intelligence, machine learning, etc. are also replacing jobs once done by hand. These new tools allow us to build better and more intelligent applications.

Despite all this potential for automation, we still regularly see organizations allowing contractors to move workloads manually. It’s simply in a staffing contractor’s best interest to have people do this, despite it being a time-consuming and error-prone process. But why would an SI recommend automation and reduce their long-term revenue? Read More…

AIS’ principal solutions architect Brent Wodicka stopped by Federal News Radio for a discussion on DevOps with  Federal Tech Talk’s John Gilroy.

They were joined by Nathen Harvey, VP of Community Development at Chef Software, and David Bock, DevOps Services Lead at Excella Consulting. Each offered a unique and practical perspective on the concept of DevOps and how it’s working for federal government IT.

You can listen to the full show over at Federal News Radio!

Previously in another blog post, I laid out a quick summary of Continuous Integration (CI) and Continuous Delivery (CD) in Visual Studio Team Services (VSTS). Today we’re going to expand a bit on those DevOps processes to better suit your (or your clients’!) needs.

With CI and CD, a build agent is required—that is, a place where your code is sent to be compiled and then subsequently deployed. By default, VSTS gives you the option to use a hosted agent. This is an entirely a cloud solution; you can just choose one of the hosted agents to build and deploy your code and you’re all set. But there are a couple of drawbacks with this…

Read More…

Recently we collaborated with Microsoft and Prospect Silicon Valley (ProspectSV) on a project to assess the viability and value of several Azure services. Specifically, we were asked to demonstrate how the cloud-based platform could be used to retrieve, store, visualize and predict trends based on data from multiple sources. In order to demonstrate these capabilities, we built an ASP.NET MVC application leveraging the following Azure components:

  • Azure App Services
  • Azure Machine Learning
  • Azure Power BI Embedded
  • Azure Storage

Figure 1: ProspectSV Application Architecture depicts how the system uses these four Azure components. This diagram also describes which external data sources are used and where that data is stored.
Read More…

Containers are, for good reason, getting a lot of attention.  For the cost of having to manage some complexity, they provide a unique level of flexibility, ability to scale, run software across cloud and on-premises environment…the list of benefits can go on and on.  And usually when you hear about containers in the technical press, they’re included in an overarching story about an organization that moved to some highly scalable, microservices-based architecture to meet their ridiculous capacity demands (Netflix, Google, etc.).

At the most basic level, however, containers are about being able to streamline the process of installing and running software. In fact, the fundamental concepts behind containers map almost one-to-one with what’s been traditionally required to install a piece of software on your laptop: Read More…

Azure Role-Based Access Control (RBAC) offers the powerful ability to accord permissions based on the principle of “least privilege.” In this short video, we extend the idea of Azure RBAC to implement a JIT (just in time) permission control. We think a JIT model can be useful for the following reasons:

1) Ability to balance the desire for “least privilege” with the cost of managing an exploding number of fine-grained permission rules (hundreds of permission types, combined with hundreds of resources).

2) Allow coarse-grained access (typically DevOps teams need access to multiple services) that is “context aware” (permission is granted during the context of a task).

Of course JIT can only be successful if its accompanied with smart automation (so users have instant access to permissions that they need and when they need them).

Interested? Watch this 15-minute video that goes over the concepts and a short demonstration of JIT with Azure RBAC.

(Part One of this series can be found here.)

Deploying Azure ARM Templates with PowerShell

After you’ve created your template, you can use PowerShell to kick off the deployment process. PowerShell is a great tool with a ton of features to help automate Azure processes. In order to deploy Azure ARM Templates with PowerShell, you will need to install the Azure PowerShell cmdlets. You can do this by simply running the command Install-Module AzureRM inside a PowerShell session.

Check out this link for more information on installing Azure PowerShell cmdlets. PowerShell works best on a Windows platform, although there is a version now out for Mac that you can check out here. You can also use Azure CLI to do the same thing. PowerShell and Azure CLI are quick and easy ways to create resources without using the Portal. I still stick with PowerShell, even though I primarily use a Mac computer for development work. (I’ll talk more about this in the next section.) Read More…

In this video blog, I’ll walk you through building a continuous integration and continuous delivery (CI/CD) pipeline using the latest tools from Microsoft, including Visual Studio Team Services (VSTS) and Azure. The pipeline is built to support a .NET core application, and the walkthrough includes the following steps:

  1. Configuring Continuous Integration (CI) with VSTS Build services
  2. Adding unit testing and validation to the CI process
  3. Adding Continuous Deployment (CD) with VSTS Release Management & Azure PaaS
  4. Adding automated performance testing to the pipeline
  5. Promotion of the deployment to production once validated
  6. Sending feedback on completion of the process to Slack