Cloud Computing Explained

October 28, 2013

What exactly is a Service?

ServicebuttonWith the advancement in cloud technologies more and more companies are getting on the Anything-as-a-Service train but over the years the term services became so overloaded that people are having hard time understanding what it means. As any other technology term you hear lately some clarification may be required to understand what the person in front of you meant with "I sell services".

According to Wikipedia's definition of service (as a system architecture component) it is a set of related software functionalities that can be reused for different purposes, together with the policies that should control its usage. In today's cloud environment I would add two more things to the services definition:

  • Those functionalities must be exposed either through interoperable APIs or accessible via browser (i.e. must not be bound to a particular implementation platform)
  • And they must be accessible over the network (i.e. can be accessed remotely)
Although those characteristics should be enough to define what a service is, we really complicate the matter by thinking that everything that can be accessed over the network is a service. Well, for decades we've been accessing databases over the network - is it true to say that traditional databases are services? Comparing with the definition above the answer is "yes": it can be used for storing data for different purposes, one can use ODBC to access it from various platforms and languages and it is accessible over the network. Does that mean that by running my single instance DB on my home computer makes me Database-as-a-Service (DBaaS) provider? Not really! Here are few more things that we need to consider when we talk about services:
  • Services are normally exposed to the "external" world. What this means is that you offer the services outside your organization. Whether this is outside your team, your department or your company it is up to you but you should consider services the offering that generates business value for your organization.
  • There are also multi-tenant - this means that the services you offer can be consumed by multiple external entities at the same time without any modifications.
  • They are always up - third party businesses will depend on your services and you cannot afford to fail them hence avoiding single point of failure is crucial for the success of services
  • Last but not least services must be adopted - if you do not drive adoption through evangelizing, partnerships, good documentation, SDKs etc. the services you offer will not add value for your organization

Transitioning from a traditional software product organization to a services organization requires lot of effort and cultural change, and the best way to approach it is to clearly define the basics from the beginning. 

August 07, 2013

How IT Pros Are Destroying Their Own Jobs

Win-Lose-DiceNot surprising to me my yesterday's post Why Shutting Down TechNet is Not a Problem for IT Pros sparked quite passioned comments from IT Pros. I have to admit - I was wrong! Shutting down TechNet is a problem for IT Pros! But not because they will lose the ability to install software for free but because the hater that this event sparked among them hinders their abilities to look beyond this immediate issue and consider the change they need to make.

From the comments 30% contained rage against the cloud, 30% against the developer and 30% described how much IT Pros' job is to install, maintain and troubleshoot servers and environments or plainly said how much they love to hug their machines. The remaining 10% were valid concerns that can be summarized under 1.) cloud environments are hard to configure and 2.) Microsoft is acting rude.

Let me first address the 10%!

Cloud computing as a concept is not new except maybe the name. However the software automation that cloud environments achieve was not available several years ago. Bringing up a full application stack required several hours if not days for the IT Pro in the past while now it is available with the click of a button. Whether the cloud will live to its promise or not only the time will show but one thing is for sure - more and more automation will be added, which will require less and less need to perform the current admin tasks.

Regarding Microsoft and whether they've been acting rude this should not surprise anybody. They (still) have power and they decided to exercise it. I will emphasize once again though - I don't think shutting down TechNet is such a big problem! There are other ways to get Microsoft software for evaluation (note: not production usage) and I truly believe that if Microsoft wants to stay relevant and if they are true to their "devices and services" strategy they need to make their software affordable for evaluation. If not, as one of the comments said - there is always Linux.

The remaining 90% though are the ones that worry me about the IT Pros. For people who will always be on the liabilities side of the balance sheet they should pioneer the cloud and not blindly claim its uselessness. Throughout the comments I noticed that certain professionals do not even clearly understand the basic cloud concepts (like public and private) and what scenarios those can enable. There are numerous examples where IT organizations embrace the cloud and not only keep their jobs but become the Achilles heel of the enterprise.

Which brings me to the second point - the hate against developers and in this capacity the Lines of Business (LOBs). Everybody who works in a company that has at least one IT guy is aware of the tensions between IT and the "others". And being realistic if the IT Pro needs to serve several masters (developers, users and maybe customers) and if it takes weeks if not months to gets servers provisioned neither him nor the "others" will be happy. The solution for the IT Pro guy is to become more nimble, more agile. Partnering up with the business groups and development teams instead complaining will bring them more success and fame.

For the remaining 30%, the people who want to hug their servers my only advice is to let it go. Unless you feel weird satisfaction by installing the same software again and again you need to move on and start bringing value to the table in the form of fast and flexible solutions.

As I mentioned in my previous article - it is time for IT Pros to change unless they want to become extinct.

July 08, 2013

Is the Cloud the Right Solution for Your App?

Image51It is surprising to see how every new technology suddenly becomes the thing that will solve every problem. The cloud is no different. Everybody rushes to migrate their applications to the cloud because they think this will magically make them faster, cheaper, agile, competitive and… add any other buzzword that comes to mind. Well, not so fast! You don't need to move every single application to the cloud! Or at lest not in its current state.

 

There are thousands of articles on Internet that discuss what applications are applicable for the cloud (including several that I have written) and what are not. There are also thousands of articles discussing the different cloud technologies and how they can be used. Unfortunately what I have seen in the last four years is that people don't pay attention to those writings and choose applications that are not applicable for the cloud or severely misuse the technology. 

 

Take for example the following scenario. The IT team at a very large enterprise creates virtual machines on AWS for each analyst, installs desktop software that uses local database (file based) and let them use those at their discretion. This is certainly enough to have a checkbox next to "Migrated application to the cloud" on your performance review but is this the solution? First, let's look at what the problems with this "migration" are:

  • Because the VM is used by a single user it's utilization will be no more than 8h a day or 30%. And this is only if this analyst doesn't take any breaks, which means that the utilization of the VM will be much lower. The goal of the cloud is to maximize the utilization of your infrastructure and improve the efficiency and I am not talking from cloud vendor point of view.
  • If you make a simple calculation you will find out that throughout the year they will pay Amazon amount that equals to pretty decent notebook. But wait, the analyst already has a notebook! And she or he uses this notebook to connect to the VM. Hence they are paying double for something that they already have - why don't use the analysts notebook to install the software there. (I know there are certain reasons why you don't want to do that but just bare with me).
  • The user experience will be suboptimal when Amazon decides to move your VM from one node to another. This will result in interruptions, possible loss of data and low satisfaction from the analysts.
  • Although they can create VM template managing all those VMs is a tedious task. You need to go patch them, update the template, troubleshoot them etc. that will increase their management costs.
  • The part that mostly bothered me in this scenario was that the technology for solving this problem has been available for long time - it is called Terminal Services and there are few established vendors that made business of that long before the cloud term was even conceived.

 

Now, if you really want to make an impact in your organization you should approach the problem differently. The  questions that you need to ask are: 

  • How can I increase utilization?
  • How can I decrease spending?
  • How can I allow centralized management?

 

Implementing Terminal Services in your organization may be the simplest answer. As mentioned the technology is available for long time, it is proven and it is easy to implement. If you want to show that you are up to date with the latest developments and mention cloud on your resume look at VDI (or Virtual Desktop Infrastructure). Last but not least if you want to prepare your application for the future consider reworking it into a modern web application that uses central database, services and multi-tenant UI.

 

As it seems the cloud can be solution for your app but you will need to put the effort to find the right way.

June 24, 2013

Is Your Cloud Ready For The Enterprise?

Ready-set-goReading my newsfeed this morning I noticed several articles talking about the cloud and the enterprise. There is no doubt that the area is heating up with more and more acquisitions (IBM buys Softlayer), investments (GE invests $105M in Pivotal) and fights over big deals (IBM vs. AWS for the CIA cloud) but the question that comes up is: "Are the cloud platforms ready for the enterprise?"

 

Being involved with numerous cloud projects I see five areas that enterprises emphasize when they evaluate their options. Those are not too different from the criteria they use for any other software offering but here is the cloud run-down.

Migration

An enterprise application portfolio consist of a mix of applications, some of which are decade or more old. An enterprise ready cloud platform will offer support for legacy applications as well as new, cloud-architected ones and should provide smooth migration path for those. It is not surprising that IaaS, although not the ultimate solution for the enterprises, gained such traction recently - it is the stepping stone to the more advanced solutions like PaaS and SaaS but offers less disruptive migration path than the other ones. 

Integration

Similar to the application portfolio the list of internal systems within the enterprise can be quite long. Driving the business is the highest priority and integration with existing business systems like CRM, ERP, HR etc. and applications for those can break or seal the deal with a cloud provider.

IT teams look for easy integration with their existing infrastructure automation and monitoring tools while on the development side the cloud platform should provide easy integration with IDEs, build, test and deployment tools that are utilized in the enterprise.

Security

This one is the one that is most discussed in the media. Privacy and security concerns are widespread and single mistake can cost lot of money for a cloud provider. Integration with existing user management systems for authentication and/or authorization, single-sign-on (SSO), encryption and data protection are must haves for the enterprises. Especially for the ones in the Financial, Insurance and Healthcare verticals.

Licensing

You may have heard about this before but not all enterprises are thrilled to hear that with the cloud they remove their CapEx and convert it to OpEx. My favorite example here is the utilities companies and you can read more in my post Business Strategy for Enterprise Cloud Startups

An additional consideration is Enterprise License Agreements (ELAs) used for long time to do bulk licenses for packaged software. A cloud provider that offers easy roll-up of their services in the existing ELAs or the so-called Bring Your Own License (BYOL) will have certain advantage over ones that do not have such options.

Business Advantage

Last but not least enterprises are looking for platforms that will allow them to build for the next 10 or more years. If a cloud vendor is not able to prove its value for longer period of time its place in the enterprise will be taken by one that can. The value of the cloud is not satisfying the needs of one of the internal teams (Business, IT or Development) but of all three together.

 

Independent of which side of the table you sit (the vendor or the enterprise buyer) you should consider all five areas in your cloud strategy and make sure that these are well covered when the contract is signed. 

June 17, 2013

Open Source in the Cloud - How Much Should You Care?

Open-Ended-Funds-vs-Closed-Ended-Funds-300x300In his opening keynote for Red Hat Summit, Jim Whitehurst, the CEO of Red Hat asked the audience: "Name an innovation that isn't happening in Open Source - other than Azure!" I can certainly add iPhone and AWS to the mix but let me stick to the cloud topic with the following question: "How much Open Source matters in the cloud?"

 

Let's first elaborate on a two misconceptions about Open Source.

 

Open Source is Free

Not really! In the cloud doesn't matter whether you are running on an Open Source platform or not - it is NOT free because you pay for the service. And for long Open Source project have been funded through the services premiums that you pay. I would argue that Open Source vendors have mastered the way they can take profit from Open Source services and are far ahead than the proprietary vendors. The whole catch here is that you pay nothing for the software and incur no capital expenditures (CapEx) but you pay for the services (i.e. Operational Expenditures or OpEx) - remember, this is also the cloud model. Bottom line is that you may be better off with a propriatery vendor than an open source one, because the former need to yet master that business model.

 

Open Source Means No-Lock-In

Not sure about that too! Do you remember J2EE? It wasn't long time ago when Sun created the specification and said that there will be portability between vendors. Those of you who have tried to migrate J2EE application from JBoss to Weblogic to WebSphere will agree that the migration costs weren't negligible. It is the same with Open Source clouds - doesn't matter that HP and RackSpace both use the Open Source OpenStack - you still need to plan your migration costs.

 

I am far from saying that Open Source is not important. Quite opposite - I am big Open Source fan and the biggest example I can give is… well, Azure. They also understand that the source is not important anymore hence they open-sourced their SDKs (and continue to add more). It is time to forget those technology wars and really start thinking about the goals we have and the experience we provide for our customers. When you choose your cloud providers you should not ask the question: "Are they Open Source or proprietary?" Better questions to ask are:

  • Does the vendor provide functionality that will save me money?
  • Can they support my business for the next 5 or 10 years?
  • Do they provide the services and support that I need?
  • Are they agile enough to add the features that I need?
  • Do they have the feedback channel to the core development team that I can use to submit requests?
  • Do they have the vision to predict the future in the cloud?

All those are much more important questions for your technology strategy and your business than whether their cloud is Open Source or not.

June 10, 2013

10 Dos and Don'ts for Running Proof-of-Concept Projects in the Cloud

DosdontsWith cloud computing increasing its popularity, more and more enterprise IT and development teams are looking to run proof-of-concept projects. Very often though such projects do not deliver results as expected and project managers come back to the leadership teams with either: "We are not ready for the cloud!" or "It will be too expensive to move our applications to the cloud!" However the problem doesn't necessary lie in the cloud or the application portfolio. Most of the times it is in the way the project is scoped and managed. 

 

Here are few DOs and DON'Ts for managing proof-of-concept projects in the cloud.

 

DOs

  • Make a decision what type of cloud options you will evaluate - from a service model point of view and from deployment point of view. If you are going to evaluate private PaaS options try to compare those only to private PaaS providers. Using the well known cliche compare only apples to apples.
  • Clearly define the terminology for the whole project team. For example something that one company calls PaaS may be considered IaaS or just a stack automation by another vendor. You need to have your own definition of PaaS, IaaS, stack automation tools and any other terminology that you will use.
  • Choose only vendors that fit your definition. After you clearly define and socialize what you will be evaluating you need to choose vendors that offer solutions that fit you your definition. 
  • Select application that will be easily migrated to the cloud. Quite often teams select their most complex application but the problem with this is that such applications are very often implemented with legacy technologies and most of the time gets spend on re-architecting the application instead learning what the cloud has to offer.
  • Set clear goals and timeframe for the PoC. You need to be clear what problems you want the cloud to solve for you. Whether it is agility and time-to-market, or efficiency and ease of infrastructure management you need to get the whole project team to agree upon. Next, make sure the project is time-boxed and properly managed to come up with meaningful results.

 

DON'Ts

  • Don not rule out particular technology because you are not familiar with it or it is too new. One of the goals of the PoC should be to become familiar with the technology. In addition new technology may solve more problems for you than you have initially anticipated.
  • Do not select too many vendors. Choose only the best 2 or 3 vendors in the category you want to evaluate else you may fall into analysis-paralysis and not be able to choose among the variety of options you have. In addition the PoC will run longer the more vendors you have.
  • Do not migrate multiple applications as part of the PoC. Migrating one application should be enough for you to learn what the effort is and become familiar with the technology or the vendor. Migrating more than one application is investment that you may not stick with after the PoC.
  • Do not extend the length of the PoC. Even if you think that you will be able to migrate your complex application to the cloud if you extend the PoC with another month it is better to cut the scope instead. The reasons are that 1. you have already learned that you will need more time to migrate your applications to the cloud and 2. extending the PoC postpones the decision and moves you further away from the ultimate goal to get everybody on-board.
  • Last but not least do not make decision that is heavily tailored to the needs of one team. If the PoC is a cross-team effort (IT, DEV, Business) then all three teams should have equal saying on the technology. If one of the teams targets additional goals they can evaluate technology that easily integrates with the chosen one and offers complementary benefits.

 

Making a technology decision has always been tough choice hence having a structured approach to the problem can help you make the decisions faster and last longer.

June 03, 2013

Multi-Tenancy Options in Cloud Environments

Condominium-design-ideasOne of the biggest benefits the cloud offers is the ability to colocate customers and applications on the same hardware in order to improve the efficiency through resource utilization. This type of colocation is referred as multi-tenancy however the term becomes overloaded and it is crucial to understand the different types of multi-tenancy out there. This is especially important when you are building your private cloud because your goals may differ from those of the public cloud providers who try to satisfy the requirements of a much broader audience.

 

Now, let's look at the different options that are available.


Multi-Tenancy at Infrastructure Level

One of the most common approaches of multi-tenancy is the one implemented at the infrastructure level. This is the widely popular IaaS (Infrastructure-as-a-Service) approach, where you can host multiple customers and/or applications on the same hardware by using separate virtual machine for each. The benefits of this approach are:

  • Maturity - virtualization has been used for a while already and the technology and the tooling available is pretty advanced
  • Easy to implement - there are many out of the box products available on the market that can get you up and running pretty fast
  • Legacy app support - you will be able to run legacy apps that are not cloud-enabled with little migration effort

However there are quite some disadvantages of this approach that you need to take into account:

  • Decreased infrastructure efficiency - in order to run multiple VMs on the hardware you need to 1. use a hypervisor to run those and 2. install separate kernel on the guest VM; both of those use part of the resources on the machine for their own needs leaving less for your application
  • Increased license costs - the hypervisor and the guest operating systems may require additional licenses, which increases your capital expenditures
  • Higher maintenance costs - with the sprawl of VMs that you have you will need more time to update, patch and troubleshoot your environment
  • Developer unfriendly - although it solves the machine provisioning problem it may not solve the application deployment and maintenance problems and it will continue to impact your time-to-market. One note here is that there are quite a few tools available on the market that you can use for application provisioning automation however their integration with the underlying VM management software is still not mature enough

Multi-Tenancy at OS Level 

The next option you can choose from is to use application containers for multi-tenancy. This is more advanced approach where you use containers that run on the same operating system and ensure access only to resources allowed for the application. There are several benefits to this approach compared to the IaaS one:

  • Higher density - because you don't need to run a hypervisor and separate kernels for your application you can deploy more useful workloads on the machine compared to the IaaS approach; the overhead for running the container is much smaller
  • Lower licensing and maintenance costs - there isn't anymore the need to pay for hypervisor and guest OS licenses; the license cost for the container management software is comparable to the license cost for IaaS management software that does not include hypervisor and guest OS licenses
  • Developer friendly - because the containers are specialized pieces of software that target specific types of applications they already come with a complete application stack (like J2EE, IIS/.NET etc.) and application deployment support
  • Application Standardization - because the platform itself takes care of the application stack build-up you can achieve high level of standardization between applications; in addition the platform may offer standard services that can be used by each application

Some of the disadvantages of the containers approach are:

  • Limited legacy app support - containers are well-suited for deployment of applications that are developed with service-oriented approach in mind (SOA); legacy applications that assume certain machine or OS dependencies may require significant efforts to migrate
  • Maturity - the containers approach is new compared to the virtualization one however it is picking up speed fast and you can expect to see more in the coming months and years; the tools support and the integration with the underlying infrastructure can also be limited

Multi-Tenancy at Application Level

Last but not least is the approach where you implement multi-tenancy in the application itself. Although this is the approach where you will achieve the highest density of your infrastructure there are certain disadvantages:

  • Very costly - in addition to the actual functionality of the application it needs to also be instrumented for resource management, which can become a significant work item
  • No standardization - each multi-tenant application ends up implemented differently because there are no standard infrastructure services that can be used
  • High maintenance costs - because each application has a different approach to implement the resource management the maintenance costs grow with each new application

Having good understanding of the multi-tenancy options is crucial when you make a decision for your private implementation. Weighting out the options and getting feedback from various stakeholders in your enterprise - developers, operations, business - will help you make the best choice for your cloud strategy.

May 29, 2013

Why Application Modernization is Necessary When You Move to the Cloud?

FutureFor decades we have been developing applications that are tightly coupled and bound to the underlying infrastructure. With the introduction of the cloud though this legacy architectures prove not only to be inefficient but also a major obstacle for you to compete successfully in the new competitive landscape.

 

Let's look at couple of reasons why application modernization is a requirement if you want to leverage cloud technologies, independent of whether those are home grown, private or public.

 

The Problem With Tightly Coupled Applications

Majority of the applications are developed with some user interaction layer, business logic and backend storage. When those are tightly coupled together your only option to scale the application is to add more hardware to the machine that currently runs this application, approach also known as vertical scaling. However there are few problems that arise:

  • Adding more CPU power and memory to the machine has certain limits that are imposed by the hardware architecture. You can invest in more advanced hardware but this increases even more your infrastructure costs (high-end hardware costs several times more than the commodity hardware used in cloud data-centers).
  • The performance of your application is determined by the slowest component in it. Thus even if the UI is super fast and is able to handle large amount of users but the business logic is slow and cannot handle the load you will be limited to the load the business logic can handle. Because the UI and the business logic are tied together you will not be able to scale just the business logic in order to handle more users. This leads to inefficient resource utilization and again higher infrastructure costs.
  • Tightly coupled applications do not normally have clearly separated tiers with defined interfaces and changes in one part of the application may have undesired impacts in another. Tasks like fixing, updating and extending it become a maintenance nightmare. The budget for supporting and maintaining such applications grows each year.

 

Here is how those things get solved in a cloud architected applications:

  • Adding CPU power and memory is trivial - it is just a matter of adding a new instance of the application (or just part of it as you can see in the next bullet point). Cloud enabled applications scale out by adding more instances of the application or the application components that work in parallel (also known as horizontal scaling).
  • The performance of the application is not anymore determined by its slowest component. Because the components of the application are clearly separated you can scale out just parts of the application (i.e. the business logic in the previous example) to match the load that the UI can handle. You have much more flexibility and granular control over the way your application scales.
  • Because the components of the application are clearly separated, changes in one component do not impact another as long as the interfaces are kept in tact. Tasks like testing fixes, updating components, improving the performance of particular tier and any other maintenance and support becomes much easier.

 

The Problem With Local Resources

Another common problem with legacy applications are the dependencies on local resources. Few examples are:

  • Dependencies on locally installed software or libraries. Such dependencies can be specialized server software, local queue implementations, client libraries used for special rendering etc. Lot of the times this software comes with additional licensing costs.
  • Reliance on the local file system. Application logging is a typical example but you can also think of other things like loading data from local files, storing data locally etc. Server failure results in data loss, which in some cases may not be acceptable.
  • Sticky sessions and storing session information locally. Every web application relies on user sessions and each web framework offers a way to manage those on the server side. However if the server fails the session is lost, which impacts the user experience.

The biggest problem with local resources is the assumption that those will be available throughout the lifetime of the application. But even the most reliable hardware can fail and when this happens everything that is stored locally will be lost. The price you will pay for lost data will significantly exceed even the most expensive hardware.

 

Cloud enabled applications solve those problems as follows:

  • Workloads that require specialized software can be deployed on a infrastructure pool that has the software preinstalled. Thus adding more customers will not require new licenses for the software.
  • Critical data as well as logs is stored in a central storage local that is regularly backed up and can even be geo-replicated. The chances of data loss in the cloud are significantly lower.
  • Sessions are stored either in a shared storage or in distributed cache and accessible from each instance of the application. Thus failure in one application instance does not impact the user experience because the next request is routed to another instance.

 

The Problem With Configurations

The last one I would like to touch on is the problem with configuration. Near all applications suffer from the  configurations problem but in legacy applications this is particularly amplified. The whole problem starts with the need to have one configuration that mangoes all components or at least the front-end and the business logic. Then over time this configuration grows and grows together with the new functionality added to the application.

 

But this is not the only issue with legacy applications configurations. The bigger issue is the settings that rely on the underlying infrastructure. This was OK when you were in control of the infrastructure and on which server the application is deployed however this approach results in increased configuration sprawl when the application needs to be moved between environments.

 

When you design your application for the cloud though you are forced to abstract the configuration from the underlying infrastructure and things like hard coded local paths, reliance on local environment variables or machine configurations have no place in your configuration files. Thus you make changes in your configuration only when new functionality is added and not when you move your code between environments (as in development, test, production)

 

Even if you are not considering immediate migration of your applications to the cloud is worth evaluating your application portfolio and estimating the effort to make it cloud-ready. It is of benefit not only for your cloud efforts but as a general strategy for the future.

May 08, 2013

Do You Have a Plan for Switching Cloud Providers?

Moving-dayLast 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?

May 01, 2013

How Do You Choose Your Cloud Provider?

Decide-image-blogIf 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.