Snip/Shot by Toddy Mladenov

Do You Have a Plan for Switching Cloud Providers?

Tweet

Last week's announcement from Xeround to discontinue their public database service may have taken some people by surprise.

Xeround's web site claims that they power 32,000 applications and for sure a few of those will have trouble moving out in a short notice. Doesn't matter whether you use small cloud provider like Xeround or larger one like AWS or Azure, having a plan how to move your workloads between providers is important for your business continuity.

Here are a few things you want to think about when you develop such a plan.

Do you have all the login information?

This one is silly but you will be surprised how may companies don't keep track of who has access to their cloud provider accounts. Having a central lock box for such passwords and auditing the access to it has been for long an enterprise practice but startups normally don't have such a rigorous process. When you receive a message from your provider your first question should not be: "Does anyone knows the how to login?"

Is your application provider agnostic?

There are a lot of debates about the so called "provider lock-in" and I am not going to dig deeper into this. If you use provider specific functionality in your application make sure you follow those steps:

1. Be aware what provider services or functionality you use and where are they used
2. While developing or migrating your application to the cloud abstract those services from the main logic of the application
3. Estimate the effort needed to remove the custom functionality
4. Look at few other cloud providers and make a plan what would it take to re-code the application with their services

What is the business impact of the switch?

With the current level of standardization, switching between cloud providers is not a trivial task. In lot of cases you may incur some downtime. Think about the following:

1. Is downtime acceptable for the business?
2. How long will the switch (and the downtime) take?
3. Does it require development efforts and how much?
4. Does it require data migration?
5. What will be the impact on the customers?

How easy it is for you to obtain your code and data?

Assumption is that you own your code and data although it is hosted on the cloud provider's infrastructure. But the problem with the data is that it can be… well, a lot. Getting your data may be one of the problem areas. While your application is running it is most probably collecting some information and storing it either in a cloud database or cloud file system. Over time the amount of data grows and downloading this over Internet may be troublesome.

Work with your cloud provider to have a plan to retrieve your data upon request in the easiest way for you. 

How supportive is your current cloud provider?

A good cloud provider will have an established support channel that is constantly monitored by its employees. Having a phone number that you can call 24/7 should be requirement. You should work with your cloud provider throughout the switch process in order to make sure this goes smooth.

Last but not least your cloud provider should give you enough notice in advance to enable you smooth migration.

 

It is not a bad exercise to replay the scenario at least once in order to see whether you have accounted for all the variables. Here is a challenge for you! If you have only a week to move your app from one cloud provider to another (as it is the case with Xeround) can you make it?

How Do You Choose Your Cloud Provider?

Tweet

If you have been thinking how to choose your public cloud vendor you are not the only one. There are hundreds of offerings that you can choose from and comparing those can be a cumbersome exercise. Hence most of the people just run to the vendor (or technology) they are either most familiar with or gives them the best price. This is all good until they discover that… well, that vendor is not what they have been looking for.

 

Lately I've been few times asked: "Which public cloud provider would you recommend to deploy our application?" Doesn't matter how much I want it to be, the answer is unfortunately not that simple. Here are few questions to ask yourself while doing the research.

Do you plan to migrate existing applications or to develop brand new applications? 

Very few if any legacy applications are designed with cloud patterns in mind. Things like sticky sessions, admin access, usage of local machine resources or direct access to OS are often deeply woven into the application logic, and ripping them off may be equivalent to starting from scratch. In such cases you may be better off keeping those apps in house or be limited to only IaaS providers. Even in the IaaS case you may not be able to use some of the functionality like sticky sessions for example. For enterprises this is the predominant scenario, and if you want to get to the answer easier you need to be very familiar with your internal application portfolio.

 

The answer is much simpler for startups - they don't have the legacy apps baggage of the enterprises. 

What technology do you plan to use?

If you plan to migrate legacy application then you don't have a choice - you are stuck with the technology it is already using. For the past decade Java and .NET made their way into the enterprise world and most of the public cloud providers offer those as a choice. However you need to be careful what each provider understands under Java and .NET support. Very few PaaS providers allow you to move your legacy application to the cloud without any modifications - most of the times the vendor just supports the language on their platform but not the full technology stack.

 

PHP and Ruby seems to be the choices for startups and lot of vendors offer those as choices. 

What is your developers expertise?

If your staff spent most of their lives developing in Java or .NET and you want to use PHP or Ruby in cloud you obviously are not making the right choice. The migration to the cloud should be smooth. Think about the ramp-up time they will need to just learn this new paradigm. Although very promising and exciting it will require from them to change lot of the development and design processes they have been using for years. It will be easier for them if they don't need to learn yet another language.

 

Ruby is the choice for startups because it is easy for prototyping but may not be well suited for large scale apps. If your startup gets traction you may need to migrate from one cloud vendor to another.

What is your budget?

The question about price is always pressuring. It is mistake though to make decisions only based on price. There are two things going on right now that impact the prices of cloud computing. One is big players like Amazon and Microsoft who are almost in a price war, and two is the numerous new players who try to enter the market by offering more competitive prices. While the first one is good for you the second is, in my opinion, not so desirable.

 

The reason is that some of those smaller players may not survive the pressure of the lower prices and may end up out of business in a year or two. If you are one of their unlucky customers you may need to migrate your applications even before you complete your first migration. This doesn't mean that you should not choose any of the smaller providers. What it means though is that you should always have a back up plan and this is true also for AWS and Azure.

How long the vendor have been on the market?

Last but not least you should think about how stable and experienced the provider is. There are lot of players in the area and this is good for bringing the price down but they lack the experience that older ones have. And once again the question here is not about size - think about HP that released they cloud just recently vs Joyent that has been hosting wordpress.com for years.

 

Making the choice of cloud provider should be approached in a thoughtful way with consideration of all the above factors and maybe few more. Building a solid plan and evaluating as many choices as possible is you best bet to migrate your apps successfully.

 

Business Strategy for Enterprise Cloud Startups

Tweet

With cloud computing becoming the center of almost every new enterprise IT project, more and more startups decide to compete in the area. This raises the question: "Are they ready to fulfill the enterprise needs?" Forget the need to have one big customer. This can open few doors but if your startup's business strategy is wrong those will be shut down soon. It is true that one prominent customer can boost your sales but in my opinion there are two more important things that can help your startup get customers fast.

First question you need to ask yourself is: "Do I target the right audience?" If you want to play in the cloud space you need to look at two different points of view - the developer one and the IT one, and make sure that you understand both. And trust me, John Engates, CTO of Rackspace, is right by saying "the traditional datacenter admin, even the CIO, don't necessary understand a developer's standpoint" (see Cloud Operability and the Battle for the Open Cloud at forbes.com). 

If your product is targeted to a developers audience the capabilities you should outline are speed and agility (aka faster time-to-market), integration with existing development tools and abstraction from the underlying infrastructure. Think whether your product offers services that developers can use to stitch together and deliver their application faster. Or whether it makes the build and deployment process smooth and faster. Or whether your product allows them to run their application uninterrupted without the need to deploy and configure new instances every time something fails.

If you target IT admins on the other side you need to think more about cost savings, standards and security, and integration with the underlying infrastructure. A customer once told me: "IT will always be on the expense side of the balance sheet. The more we are able to save costs the longer we will keep our jobs". Does your product help IT teams reduce operating expenses or reduces capital expenditures? Does it follow established standards and allows easy integration with existing infrastructure and applications? Does it require extensive training and ramp-up time?

The other question you need to ask yourself is: "What is my pricing strategy?" Subscription models are nice because they guarantee you regular payments but they not always work. Some enterprises may have rules to finance their IT through credit instruments like bonds, and such can only be issued for capital expenditures. On the other side if you only offer perpetual licenses then the customer may not be willing to upgrade at the pace you ant them to. Getting the right balance between pricing and needs can only be achieved if you know your audience. If you target developer organizations OpEx may be fine because they are revenue driven. On the other side IT teams are  expense driven and they may need more time to prove that your product saves money than your subscription license allows them.

The more traction the cloud industry gains the harder will be for new startups to enter the area. Hence, defining your audience and pricing strategy early on will be crucial for the  success of your venture.