1-888-317-7920 info@2ndwatch.com

How to Choose the Right Cloud Partner to Migrate Your Data Center

Ideally, selecting the correct cloud partner should be as simple and straight forward as the cloud itself.  However, any selection requires time to qualify the right partner according to where your company is at in its cloud journey.  Additionally, the term cloud has been over marketed by all companies in the last several years, even by companies who do not have a cloud offering, which adds confusion to the partner selection process.

We know partner selection is a very important process that is vital to your cloud migration success.  Luckily, it does not have to be a long, drawn out, or difficult process if you look toward best practices.  Here are some suggestions based on learnings, analyst discussions, and market drivers.

Step One

First, you need to determine where you are in the cloud journey. Ask yourself some key questions to help you identify where exactly you are, and where may want to go:

  1. Does my company have a clear vision of how we want to use the cloud?
    • Your vision could take several different forms. One example is having all applications move toward being Software as a Service (SaaS) first, Platform as a Service (PaaS) second and Infrastructure as a Service (IaaS) third while maintaining a small data center footprint.  Another could be a “cloud first” approach for all new development while “lifting and shifting” everything old to IaaS.  Either way, your vision and strategy need to be clearly defined. If they are not, you definitely need to select a partner who can help you develop a cloud vision.
  2. Has my company selected a short list of Cloud Service Providers (CSP vendors) and prioritized that list?
    • This would include selecting companies that are identified by the likes of Gartner to have a mature cloud offering. If you are focused on IaaS, the Gartner Magic Quadrant is a useful tool to dispel the FUD and find out what the strengths and weaknesses are for each CSP.  For this blog, we will focus on the CSP of IaaS.

 

Step Two

You now need to evaluate the partner network for those CSPs.  AWS has a useful tool for this on its partner page.  From the highest level, AWS buckets partners in two categories – Independent Software Vendors (ISV) and Consulting Partners (SI).  Further delineation is made only within the SI bucket into three categories – Premier Partners, Advanced Partners and general AWS partners.

  • You then need to ask, are any of my short-listed partners listed as Premier? If not, here is why it matters:
    • Premier Partners are qualified by:
      • Focus on the customer
      • Number of Globally Certified Architects and qualified personnel on staff (AWS proven skill set)
      • Customer imonials
      • Use cases
    • Even within the Premier Partners category there exist differences between partners and their companies’ focus, so it is important to determine what type of partner you need. Ask yourself:
      • Do I need a partner that is more focused on building and managing my data center in the cloud?
      • Do I need a partner that is more focused on application development?
      • Do I need a partner that is a business consultant?
      • Do I want a partner that does everything from strategy to managed services or do I want to handle this myself?

 

At the end of the day, there are limited partners that have highly skilled staff on AWS. As Terry Wise, the AWS Head of Worldwide Partners, pointed out in a recent article, “We don’t have enough partners in the ecosystem who really understand – and can deliver – cloud managed services.”

Step Three

As you identify your short-list of partners we would highly recommend ing at least two of those partners with a cloud Proof of Concept (POC).  The main reason for the requirement of ing out a partner is that many partners sell with their A Team, but deliver with less qualified staff. The leaves you, the customer, frustrated at the outcome.  Some partners may say they have thousands of AWS users today, but keep in mind that these individuals are not working on AWS projects 100% of the time.  On the other hand, there a few Cloud Born partners, like 2nd Watch, that focus 100% on cloud solutions, delivery, and management.

Final Thoughts

We wish you well in 2015 and will leave you with one final recommendation based on 2014 Q3 and Q4 conversations with budget owners.  The amount of demand for qualified partners is coming at such a high rate (2nd Watch has been growing at 600% in bookings YOY) that we’d advise getting your short-list of partners together soon and qualifying them quickly.

If you fail to build strong partnerships now, there may be more customers demanding work than what the partner supply can handle, as Kurt Marko pointed out in his recent Forbes article.

-Jeff Aden, EVP Marketing & Strategic Business Development

Facebooktwittergoogle_pluslinkedinmailrss

How to Shut Down Your Data Center in 2 Months: Part 2

2nd Watch has helped hundreds of companies shut down their data centers and migrate to AWS, taking advantage of the cost savings, elasticity and on-demand benefits of the cloud. Many of those companies required tight timeframes of only 1-3 months!

Learn how you can shut down your data center and migrate to AWS in only 2 months. Chris Nolan, Director of Engineering at 2nd Watch, discusses the type of technologies enterprises are using today to help make migrations go faster and what an enterprise should have ready prior to engaging in a migration to ensure it goes quickly and smoothly.

Check back here on our blog or on our YouTube channel for the next video in this 5-part series.

Facebooktwittergoogle_pluslinkedinmailrss

How to Shut Down Your Data Center in 2 Months: Part 1

2nd Watch has helped hundreds of companies shut down their data centers and migrate to AWS, taking advantage of the cost savings, elasticity and on-demand benefits of the cloud. Many of those companies required tight timeframes of only 1-3 months!

Learn how you can shut down your data center and migrate to AWS in only 2 months. Jason Foster, Practice Director South Region at 2nd Watch, discusses the obstacles and challenges associated with planning for application dependencies and techniques for managing logistics and the cadence of your project timline.

Check back here on our blog or on our YouTube channel for the next video in this 5-part series.

Facebooktwittergoogle_pluslinkedinmailrss

A Refresher Course on Disaster Recovery with AWS

IT infrastructure is the hardware, network, services and software required for enterprise IT. It is the foundation that enables organizations to deliver IT services to their users. Disaster recovery (DR) is preparing for and recovering from natural and people-related disasters that impact IT infrastructure for critical business functions. Natural disasters include earthquakes, fires, etc. People-related disasters include human error, terrorism, etc. Business continuity differs from DR as it involves keeping all aspects of the organization functioning, not just IT infrastructure.

When planning for DR, companies must establish a recovery time objective (RTO) and recovery point objective (RPO) for each critical IT service. RTO is the acceptable amount of time in which an IT service must be restored. RPO is the acceptable amount of data loss measured in time. Companies establish both RTOs and RPOs to mitigate financial and other types of loss to the business. Companies then design and implement DR plans to effectively and efficiently recover the IT infrastructure necessary to run critical business functions.

For companies with corporate datacenters, the traditional approach to DR involves duplicating IT infrastructure at a secondary location to ensure available capacity in a disaster. The key downside is IT infrastructure must be bought, installed and maintained in advance to address anticipated capacity requirements. This often causes IT infrastructure in the secondary location to be over-procured and under-utilized. In contrast, Amazon Web Services (AWS) provides companies with access to enterprise-grade IT infrastructure that can be scaled up or down for DR as needed.

The four most common DR architectures on AWS are:

  • Backup and Restore ($) – Companies can use their current backup software to replicate data into AWS. Companies use Amazon S3 for short-term archiving and Amazon Glacier for long-term archiving. In the event of a      disaster, data can be made available on AWS infrastructure or restored from the cloud back onto an on-premise server.
  • Pilot Light ($$) – While backup and restore are focused on data, pilot light includes applications. Companies only provision core infrastructure needed for critical applications. When disaster strikes, Amazon Machine Images (AMIs) and other automation services are used to quickly provision the remaining environment for production.
  • Warm Standby ($$$) – Taking the Pilot Light model one step further, warm standby creates an active/passive cluster. The minimum amount of capacity is provisioned in AWS. When needed, the environment rapidly scales up to meet full production demands. Companies receive (near) 100% uptime and (near) no downtime.
  • Hot Standby ($$$$) – Hot standby is an active/active cluster with both cloud and on-premise components to it. Using weighted DNS load-balancing, IT determines how much application traffic to process in-house and on AWS.      If a disaster or spike in load occurs, more or all of it can be routed to AWS with auto-scaling.

In a non-disaster environment, warm standby DR is not scaled for full production, but is fully functional. To help adsorb/justify cost, companies can use the DR site for non-production work, such as quality assurance, ing, etc. For hot standby DR, cost is determined by how much production traffic is handled by AWS in normal operation. In the recovery phase, companies only pay for what they use in addition and for the duration the DR site is at full scale. In hot standby, companies can further reduce the costs of their “always on” AWS servers with Reserved Instances (RIs).

Smart companies know disaster is not a matter of if, but when. According to a study done by the University of Oregon, every dollar spent on hazard mitigation, including DR, saves companies four dollars in recovery and response costs. In addition to cost savings, smart companies also view DR as critical to their survival. For example, 51% of companies that experienced a major data loss closed within two years (Source: Gartner), and 44% of companies that experienced a major fire never re-opened (Source: EBM). Again, disaster is not a ready of if, but when. Be ready.

-Josh Lowry, General Manager – West

Facebooktwittergoogle_pluslinkedinmailrss