Azure efficiencies depend on initial sizing predictions, proper maintenance and architecture to avoid drinking more than you can handle.
Migration from the licensed world of SharePoint to the metered world of Azure or other infrastructure- as-a service (IasS) providers is a lot like drinking beer from a tap. Knowing your limit is important without the physical guide of on-premises bottles.
The Azure meter is always running, but users can finally get the productivity they pay for with a built-out Azure infrastructure ready to embrace common Big Data sources such as Twitter or Facebook feeds directly through their development of APIs.
Productivity, cost and infrastructure management benefits notwithstanding, there are some stipulations customers must consider before making the move that were shared by SharePoint and Azure experts at a recent gathering of the New York City Enterprise Collaboration Meetup Group. Among the caveats and concerns break down to five drinking analogies
:
-
Earning parental trust: Start small. While you'll get more return out of mission-critical applications, this could scare leadership away from the investment altogether, assuming IT can even get their attention.
-
Drinking Age: Identity regulations may keep at least one foot outside the Azure bar much longer than you had hoped.
-
Budgeting: Azure efficiency depends on matching the tokens you order to your actual thirst in that headroom must keep you within a fixed budget level.
-
Happy hours: Careful management from consultants will keep you from paying for head, and slow the outflow of cash during less-productive times, preventing the buying of more tokens.
-
Binges: It's all-too-easy to get drunk with data. Big data is surprisingly accessible with many new Azure tools that (for example) address Twitter and Facebook network APIs. But if you gulp down an ocean of data -- repeatedly processing it and staging it -- you're going to wake up with a very costly hangover.
"Microsoft realized they had no last-mile support for the user, so they let [us partners] sell service tokens," said Carl Mazzanti, founder of eMazzanti Technologies, which offers managed SharePoint hosting in Azure. "You must monitor Azure," said Mazzanti, who uses cloud monitoring tools from SolarWinds. "At the end of the day, this is still a data center. There is still a rack. There is still compute and power. You may not be buying it from HP, Dell or Cisco, but there's still that information is there and you have to monitor it."
Monitoring is not a trivial issue, he emphasized. "Microsoft is not monitoring your Azure environment, he warned. "They're not responding to your Azure outages unless it's a datacenter outage, or a isle outage or a rack outage. And then they're responding to it on their own. They'll let you know about it in the service portal that there's degradation."
But if your own virtual machines are offline, it's up to the customer to discover and remediate that, he explained. Providers such as eMazzanti alert customers when a virtual network connection is offline, is not properly transferring data or if storage is not available, he said. Effectively, Azure is managed just like a customer's datacenter or facility.
"Azure is still a datacenter; it's still compute, storage and backup," he said. "Treat it as such whether it's yours or somebody else's. This is no different than going to Rackspace or to Intermedia."
Customers opting to hire a third party to monitor and manage their SharePoint environments must realize that adds to the cost, said David Barter, practice director for Microsoft Technologies/End User Computing at GreenPages. Also impacting costs of course are the architectural differences between running SharePoint in Azure -- either natively or via a MSP versus other clouds and your own datacenter. "The number one flaw that I see people do is trying to spec, like-for-like," Barter said.
"You say, here's what I've got in Rackspace, so many cores, so much racks and this performance," he continued, "Now, give me that same quote in Azure. You spin that up, and Azure will always be more expensive. You have to design for it."
That's the important consideration when going from a private cloud to a public cloud infrastructure, Barter added. "If you're dedicating resources, you are sizing for your peak usage," he said. "With Azure, you are almost 100 percent opposite: You want to size your infrastructure for your lowest common usage, and then architect it to burst infinitely, because if you size it the way you did in rack space you will overbuy. And, per unit, they're probably more expensive. You can true down, but you still have to predict your motion. You should watch, actually when you do a renewal, where the next bands are in the tier, because if you miss the mark you're in trouble. You always want to have."
Original content by Elliot Luber from RedmondMag.com.
