Amazon Web Services (AWS) CTO Werner Vogels offers this great piece of cloud advice: “Treat everything as a programmable resource, including data centers, networks, compute, storage and load balancers.”

In other words, automate every aspect of your (cloud-based) infrastructure.

Given AIS’ years of experience with SharePoint, we are always looking for ways to make the underlying infrastructure more cost effective, scalable and robust. Fortunately, the benefits of automation apply equally to a SharePoint 2013 farm hosted in the cloud — whether it’s the ability to dynamically provision a SharePoint 2013 farm on the fly, or the ability to scale up and down based on load, or the ability to make the SharePoint 2013 farm more fault-resilient.

We’ve written about two automated deployment approaches to SharePoint 2013; one for Amazon Web Services and one for Azure. In case you missed them…

Our AWS-based SharePoint 2013 script and source code can be found here.

Our Windows Azure-based SharePoint 2013 script and source code can be found here.

At AIS, we’re committed to delivering transformative solutions and outcomes, and that’s exactly what we’re doing for Healthcare Receivable Specialists, Inc. (HRSI). Everyone knows that data redundancy can be a productivity killer, so we’re utilizing a cloud-based hosting solution via Amazon Web Services (AWS) for their new custom application that will help eliminate that problem. The AWS hosting option will also keep costs down without sacrificing performance and positioning for HIPAA compliance. Additionally, our solution provides a self-service means to access the status of their applications throughout their entire business process.

Keep reading to learn more about this exciting project!

Introduction by Vishwas Lele:

Amazon Web Services (AWS) CTO Werner Vogels offers this great piece of cloud advice: “Treat everything as a programmable resource, including data centers, networks, compute, storage and load balancers.” In other words, automate every aspect of your (cloud-based) infrastructure. There are significant benefits in following Werner Vogels’ advice:

  1. You can build systems that are cost aware by only keeping the parts of the system that are needed and turning off everything else .
  2. Capacity planning is hard. It is much better to dynamically build capacity based on the need.
  3. Failures are not an exception but a rule. Rather than building complex logic to handle exceptions, make your systems fault resilient by provisioning failover resources as needed.
  4. Make your systems more agile – systems that can scale in the direction of business vs. a design time scaling criterion.

Given AIS’ years of experience with SharePoint, we are always looking for ways to make the underlying infrastructure more cost effective, scalable and robust. Fortunately, the aforementioned benefits of automation apply equally to a SharePoint 2013 farm hosted in the cloud — whether it is the ability to dynamically provision a SharePoint 2013 farm on the fly, or the ability to scale up and down based on load, or the ability to make the SharePoint 2013 farm more fault resilient.

But it all begins with developing robust automation scripts to provision and manage a SharePoint 2013 farm. This brings us back to the purpose of this blog post by Abhijit Kumar. Abhijit discusses an automated approach for provisioning a SharePoint 2013 farm using Amazon Web Services. It is noteworthy that the automation approach we describe below is based solely on PowerShell. This might come as a surprise given that AWS offers services like CloudFormation, which enables creation of AWS resources, combined with open source tools such as Opcode Chef and AWS Puppet, which enable the installation and configuration of applications. We chose to rely solely on PowerShell for the following reasons:

  1. PowerShell is Microsoft’s canonical task automation framework, consisting of a command-line shell and a scripting language that has full access to COM and WMI, giving Windows administrators control over every aspect of Windows OS-based machines.
  2. PowerShell scripting language is based on the .NET framework. This means a PowerShell script can take advantage of .NET framework enhancements such as Workflow Foundation (WF). We use WF extensively to manage long-running automation scripts.
  3. AWS Cloud Formation is not available on AWS Gov Cloud. AWS Gov Cloud is an isolated AWS region designed to allow U.S. government agencies and customers with sensitive workloads to address their specific regulatory and compliance requirements. Given that AIS services a large number of customers with stringent regulatory and compliance requirements, we needed an automation approach that worked on AWS Gov Cloud.
  4. If you read our earlier blog post about SharePoint 2013 automation on Windows Azure, you will notice that we have been able to achieve a high level of reuse between Windows Azure and AWS scripts for SharePoint 2013 scripts. While the WF-based provisioning logic is largely the same, Azure Service Management SDK calls are replaced with AWS Tools for Windows PowerShell. This reuse allows us the flexibility to offer our customers a choice between the industry leading IaaS platforms – AWS and Windows Azure.

Abhijth’s post below walks you through the script to deploy SharePoint 2013 Farm on AWS in an automated manner. I am confident that you will it useful. Please give the scripts a try and let us know.

Because of our broad knowledge in building web applications, AIS decided to develop a prototype that highlights the features and capabilities of open standards for geospatial processing and data sharing through web applications.

We chose the Visible Infrared Imaging Radiometer Suite (VIIRS) as our data source for the demonstration. VIIRS collects visible and infrared imagery and radiometric data for civil and military Earth monitoring. (The Day/Night Band (DNB) datasets available from NOAA’s Comprehensive Large Array-Data Stewardship System are not quite in the format we need for our application, since they are sensor data records stored within an HDF5 container.)

Read More…

Amazon Web Services (AWS) provides an extremely flexible set of services for hosting web applications in the cloud with a web-based console for selecting options to quickly provision a set of IT resources. This post will explore the various aspects of hosting a custom .NET web application in AWS, focusing on high-availability options and disaster recovery scenarios and how to do so under cost constraints.

When building a solution in AWS you have to understand the difference between affinity and availability, and the terminology that Amazon uses. We will define affinity as the physical location of resources within a data center and availability as the isolation of resources for disaster recovery scenarios.

The AIS solution I’ll reference throughout this post uses a Virtual Private Cloud (VPC) to enable our engineers to develop a multi-tiered application within a private sub-netted network split across two availability zones. The VPC as defined by Amazon allows for “… you to create a virtual network topology—including subnets and route tables—for your Amazon Elastic Compute Cloud (Amazon EC2) resources.” The use of a VPC ensures you have high affinity for your EC2 resources. Availability zones refer to the geographically separated data centers Amazon uses for hosting EC2 resources.  Therefore, your disaster recovery architecture must account for placement of EC2 resources in different Availability Zones.

High Availability vs. Disaster Recovery in AWS

To muddy the terminology waters further, we have the concept of high availability, where the effects of hardware or software failure are essentially masked and downtime for end users reduced, such as in Microsoft’s SQL Server. Our solution had to address the issue of high availability and allow for a swift recovery in the event of a disaster or failure of EC2 resources in one availability zone. A high-level picture of what we needed to achieve is shown below.

Read More…

Most cloud services require you to create a CNAME record for your custom domain in order to direct traffic to the cloud-hosted site. Your example.com site may actually be hosted at example.cloudapp.net. For on-premises hosting you would know the IP address of your server (or the load balancer) and can use an A record, but that is not the case on Azure or AWS: these require that pesky CNAME.

CNAME records don’t support naked domains. Your site has to be at www.example.com, it can’t be at simply example.com, the root, or apex, record of your domain. On the other hand, A records can only support IP addresses.

There are a number of solutions to this problem, so I’ll list some here:

Read More…

In addition to contributing to AIS’ brand-new corporate blog, many members of our team have their own personal blogs. We may be biased, but we certainly think they’re worth a spot in your bookmarks or reader feed. Here’s what some of them have been writing about lately:

Beyond the Agile Programmer: Innovative Teams: Ryan Cromwell attended illustrator Brad Colbow’s session on Building a Design Culture at Midwest UX (where AIS was a sponsor). It got him thinking about how Scrum can enable a culture of innovation. (cromwellhaus.com)

Using Windows Azure IaaS to host SharePoint 2010: Harin Sandhoo shares the time-saving PowerShell script he uses to set up the infrastructure for SharePoint farms in Azure’s IaaS offering. (sandhoo.wordpress.com)

Update Azure DB Firewall Rules with PowerShell: Here’s another handy PowerShell from Tom McKearney for work-from-home Azure developers who are tired of constantly updating their SQL Azure Firewall settings.  (Codemares)

Setting Up SharePoint 2010 in Amazon Web Services (AWS)
: Chris Hettinger has absolutely everything you need to know about migrating a SharePoint environment to Amazon’s great big datacenter in the cloud. (messor.com)