The Enterprise is Ready for the Cloud …

Recently, we here at AppDynamics have seen two major transformations in adoption of the public cloud. First is the adoption of the cloud for production workloads, and second is adoption of the cloud by large enterprises.

Transformation 1: From Dev/Test/QA to Production Workloads

Because dev/test cycles for applications have different capacity requirements at different times, the on-demand computing resources available through the cloud are ideally suited to serve these elastic requirements. But recently we’ve seen a significant transition by customers to run production workloads on AWS and other public clouds. Perhaps there was a trust element in the cloud that has taken some time to solidify. I suppose relentless price cuts in cloud don’t hurt either. But it seems clear that enterprises are embracing the cloud for production workloads.

Transformation 2: From Startups to Enterprises

First adopters of the cloud were primarily startups who did not want to (or could not) lay out the capital investment necessary to stand up their own datacenters. The cloud has afforded many startups the computing capacity, storage, and resources of a major datacenter without the upfront investment. This on-demand computing power broke down many barriers and enabled significant innovation. Now, the late majority — enterprises — are catching on and signing up for the cloud en masse. Not only are these enterprises adopting AWS for new development and innovation, but they are migrating existing applications from on-premises data centers to AWS — and using AppDynamics to help gather valuable pre- and post-migration data about their applications.

Expanded AppDynamics Support for AWS.

In support of these transformations, AppDynamics is making additional investments in AWS. First, we have released new capabilities to support additional AWS native services such as Amazon DynamoDB, Amazon SQS, and Amazon S3, adding to our existing support of Amazon EC2, Amazon CloudWatch, and Amazon RDS. AppDynamics now monitors more AWS native services, providing even greater visibility and control for your applications running on the AWS Cloud.

Second, because we want our customers and potential customers to be successful migrating to AWS, we have launched a special 60-day trial to help customers migrate on-premises production workloads to AWS. Using AppDynamics to instrument on-premises workloads as part of a pre-migration assessment, customers are able to draw accurate, real-time topology maps of their applications, and benchmark the performance of the application in its on-premises state prior to fork-lifting it to the cloud. This visibility gives the enterprise a clear picture of what components can and should be migrated, as well as providing demonstrable data about the actual performance of the existing application. With our unique “compare release” function, customers can visualize on a single screen the pre-migration and post-migration application architecture, as well as the performance of key application transactions.

Try AppDynamics for AWS and we are certain you will see that, like Nasdaq, OMX, and other enterprise customers, the visibility provided by AppDynamics is especially valuable when migrating a platform from your internal infrastructure to the AWS Cloud.

The answer for government applications migrating to the cloud: visibility

Recently, I’ve had several conversations with US Federal Government Agencies about monitoring applications moving to FedRAMP (The Federal Risk and Authorization Management Program) data centers. Because of the Government’s Cloud First policy, which mandates that agencies take full advantage of cloud computing benefits, agencies are increasingly forced to move application outside of their own data centers. With less control on the infrastructure, the new focus is now on the performance and availability of their applications running in the cloud. Agencies want an assurance their applications are running at the same level of performance (or better) once they make the move. This is where I believe an APM solution like AppDynamics is a perfect fit to mitigate risk by providing agencies 100% visibility into their application performance.

With cloud environments, I’ve found traditional approaches for monitoring simply don’t work. This is because the agencies have limited access to the underlying IT infrastructure in the cloud. Federal agencies need the help of companies such as AppDynamics to provide them visibility into application performance from the end user down to the infrastructure to truly understand the health of their critical applications.

Before the cloud, when agencies ran applications on premise, they had the physical access to the underlying IT infrastructure. Which meant they could deploy element-monitoring tools and gain access to the network to try to infer the health of the applications. At AppDynamics, we take a modern approach to APM by monitoring performance from the top down through the concept of Business Transactions. The Business Transaction is the mechanism by which AppDynamics orders and aligns load traffic (response time, throughput, and so on) with the business perspective (For example, Login, Search, etc.).

Screen Shot 2014-07-28 at 3.11.44 PM

I’ve found AppDynamics is flexible to help customers monitor applications both on premises and in cloud environments. AppDynamics was designed from the beginning to be cloud portable by working within the constraints of cloud environments. The three main reasons why I believe AppDynamics is perfect for federal agencies to monitor critical cloud applications are:

Firstly, AppDynamics is an all software agent-based solution that doesn’t require a high network bandwidth connection. The agents can report across the Internet using a one-way HTTP(s) connection back to the controller software. This means agency applications that span multiple FedRAMP clouds can be can be monitored with a single AppDynamics controller. The controller has the intelligence to stitch the transactions that flow between clouds into one view (think – highly layered Service Oriented Architectures). The self-discovering flow map and single pane of glass view is vital to obtain the necessary visibility of your application.Screen Shot 2014-07-17 at 3.50.39 PM (2)

Secondly, AppDynamics doesn’t require privileged network access to components such as a SPAN port or a network TAP. The traditional approach for End User Monitoring was to receive a copy of the traffic to and from the application and decrypt the packets to make sense of the end user experience. This approach fails in cloud environments since the cloud providers typically will not provide access to the underlying physical infrastructure. AppDynamics captures end user experience in a cloud-friendly way through JavaScript on the browser. Through this approach, AppDynamics not only captures and correlates all end user activity with the application code execution, but also measures the page render time in the end user’s browser.

EUM-Analyze (1)

By not requiring privileged network access and high bandwidth management network, AppDynamics can follow the workload as applications are migrated to the cloud. Agencies will have visibility into the before and after state of their applications performance.

Thirdly, AppDynamics can help Agencies with scaling their applications automatically by utilizing our cloud auto-scaling capabilities. Cloud auto-scaling decisions are typically made based on infrastructure metrics such as CPU Utilization. However, I believe the better and more accurate way to auto-scale in Cloud environments is to make decisions based on application metrics such as requests per minute. For more information about cloud auto-scaling please read:

Other reasons why AppDynamics is a perfect solution for modern applications moving to the cloud are:

  1. It’s easy to deploy
  2. It requires minimal configurations (Instrumentation works out of the box)
  3. It requires minimal care and feeding on an ongoing basis (Supports rapid change with Agile development)
  4. It has a built-in Dynamic Baselining Engine to proactively alert teams of performance issues

For agencies to be successful running applications in the cloud they need end-to-end visibility into their application performance. With AppDynamics, federal agencies can finally migrate to the cloud without impacting or worrying about their applications. As all critical software applications become more complex, the visibility AppDynamics provides isn’t just a luxury feature, it’s a necessity.

Take five minutes to get complete visibility into the performance of your cloud applications with AppDynamics today.

Cloud Auto Scaling using AppDynamics

Are your applications moving to an elastic cloud infrastructure? The question is no longer if, but when – whether that is a public cloud, a private cloud, or a hybrid cloud.

Classic computing capacity models clearly indicate that over-provisioning is essential to keep up with peak loads of traffic while the over-provisioned capacity is largely left under-utilized during non-peak periods. Such over-provisioning and under-utilization can be avoided by moving to an elastic cloud-computing capacity model where just-in-time provisioning and deprovisioning can be achieved by automatically scaling up and down on-demand.


Cloud auto-scaling decisions are often made based on infrastructure metrics such as CPU Utilization. However, in a cloud or virtualized environment, infrastructure metrics may not be reliable enough for making auto-scaling decisions. Auto-scaling decisions based on application metrics, such as request-queue depth or requests per minute, are much more useful since the application is intimately familiar with conditions such as:

  • When the existing number of compute instances cannot handle the incoming arrival rate of traffic and must elastically scale up additional instances based on a high-watermark threshold on a given application metric

  • When it’s time to scale back down based on a low-watermark threshold on the same application metric.

Every application service can be expressed as a statistical model of traffic, queues and resources as shown in the diagram below.

  • For a given arrival rate λ, we need to maximize the service rate μ with an optimum value of n resources. Monitoring either the arrival rate  λ itself for synchronous requests or q depth for asynchronous requests will help us tune the application system to see if we need additional service compute instances to meet the demands of the current arrival rate.

  • Having visibility into this data allows us not only to find bottlenecks in the code but also possibly flaws in design and architecture. AppDynamics provides visibility into these application metrics.

The basic flow for auto-scaling using AppDynamics is shown in the diagram below:

Let’s take an example to illustrate how this actually works in AppDynamics. ACME Corporation has a multi-tier distributed online bookstore application running on AWS EC2:

The front-end E-Commerce tier is experiencing a very heavy volume of requests resulting in the tier going into a Warning (Yellow) state.

Now we will walk through the 6 simple steps that the ACME Corporation will use to exploit the Cloud Auto Scaling features of AppDynamics.


Step 1: Enable display of Cloud Auto Scaling features

 To do this, they first select “Setup-> My Preferences” and check the box to “Show Cloud Auto Scaling features” under “Advanced Features”:

Step 2: Define a Compute Cloud and an Image

Then they click on the Cloud Auto Scaling option at the bottom left of the screen:

 Next, they click on Compute Clouds and register a new Compute Cloud:

and fill in their AWS EC2 account info and credentials:

Next, they register a new image from which new instances of the E-Commerce tier nodes can be spawned:


and provide the details of that machine image:

By using the Launch Instance button, they can manually test whether it was successfully launched.

Step 3: Define a scale-up and a scale-down workflow

 Then, they define a scale-up workflow for the E-Commerce tier with a step to create a new compute instance from the AMI defined earlier:

Next, they define a scale-down workflow for the E-Commerce tier with a step to terminate a running compute instance from the same AMI:

Now, you may be wondering why these workflows are so simplistic and why there are no additional steps to rebalance the load-balancer after every new compute instance gets added or terminated. Well, the magic for that lies in the Ubuntu AMI that bootstraps the Tomcat JVM for the E-Commerce tier. It has the startup logic to automatically join the cluster and also has a shutdown-hook to automatically leave the cluster, by communicating directly with Apache load-balancer mod_proxy.

Step 4: Define an auto-scaling health rule

 Now, they define an auto-scaling health rule for the E-Commerce tier:and select the E-Commerce Server tier as the scope for the health rule:


and specify a Critical Condition as “Calls per Minute > 3500”, which in this case, represents the arrival rate  λ:

and a Warning Condition of “Calls per Minute > 3000”:

 Note: It is very important to choose the threshold values for Calls Per Minute in the Critical and Warning conditions very carefully, because failing to do so may result in scaling thrash.

Step 5: Define a scale-up policy

Now, they define a Scale Up Policy which will bind their newly defined Health Rule with  a Cloud Auto-scaling action:

Step 6: Define a scale-down policy

Finally, they define another policy that will invoke the Scale-down workflow when the Health rule violation is resolved.

And they’re done!

After a period of time when the Calls per Minute exceeds the configured threshold, they actually witness that the Auto-scaling Health rule was violated, as it shows up under the Events list:


When they drill down into the event, they can see the details of the Health Rule violation:


And when they click on the Actions Executed for the Cloud Auto-Scaling Workflows, they see:


Also, under Workflow executions, they see:

and when they drill-down into it, they see:


Finally, under the Machines  item under Cloud Auto Scaling, they can see the actual compute instance that was started as a result of Auto Scaling:

Thus, without any manual intervention, whenever the E-Commerce tier needs additional capacity indicated by the threshold of Calls Per Minute in the Auto-Scaling Health rule, it is automatically provisioned. Also, these additional instances are automatically released when the Calls Per Minute goes below that threshold.


AppDynamics has cloud connectors for all the major cloud providers:



If you have your own cloud platform, you can always develop your own Cloud Connector using the AppDynamics Cloud Connector API and SDKs that are available via the AppDynamics Community. Find out more in the AppDynamics Connector Development Guide. Our cloud connector code is all open-source and can be found on GitHub.

Take five minutes to get complete visibility into the performance of your production applications with AppDynamics Pro today.

Cloud Migration Tips Part 4: Failure Breeds Success

Welcome back to my series on migration to the cloud. In my last post we discussed all of the effort you need to put into the planning phase of your migration. In this post we are going to focus on what should happen directly after the migration has been completed.

Regardless of how well you planned or if you just decided to dive right in without any forethought, there are steps that need to be taken after your migration to ensure your application is working properly and performing up to snuff. These steps need to be performed whether you chose to use a public, private or hybrid cloud implementation.

Step 1: Take Your New Cloud Based Application for a Test Drive

Go easy at first and just roll through the functionality as a user would. If it doesn’t work well for you then you know it wont work well when there are a bunch of users hitting it.

Assuming things went well with your functional test it’s time to go bigger. Lay down a load test and see step 2 below.

Step 2: Monitoring is Not the Job of Your Users

If you’re relying on the users of your application to let you know if there are performance or stability issues you are already a major step behind your competition. If you planned properly then you have a monitoring system in place. If you’re just winging it, put in a monitoring system now!!!

Here are the things your monitoring tool should help you understand:

  • Architecture and Flow: You design an application architecture to support the type of application you are building. How do you really know if you have deployed the architecture you designed in the first place? How do you know if your application flow changes over time and causes problems? Cloud computing environments are dynamic and can shift at any given time. You need to have a tool in place that let’s you know exactly what happened, when and if it caused any impact.

E-Commerce Website Architecture

What happens if you don’t have a flow map? Simple, when there’s a problem you waste a bunch of time trying to figure out what components were involved in the problematic transaction so that you can isolate the problem to the right component.

  • Response Times: Slow sucks! You moved to the cloud for many potential reasons but one thing is certain, your users don’t want your application(s) to run slowly. It seems obvious to monitor the response time of your applications but I’m constantly amazed by how many organizations still don’t have this type of monitoring in place for their applications. There are really only 2 options in this category; let your users tell you when (notice I didn’t say if) your application is slow or have a monitoring tool alert you right away.

Screen Shot 2012-08-14 at 1.59.33 PM

  • Resources: You need to keep an eye on the resources you are consuming in the cloud. New instances of your application can quickly add up to a large expense if your code is inefficient. You need to understand how well your application scales under load and fix the resource hogs so that you can drive better value out of your application as usage increases.


Step 3: Elasticity

Elasticity is a key benefit of migrating your application to the cloud. Traditional application architectures accounted for periodic spikes in workload by permanently over-allocating resources. Put simply, we used to buy a bunch of servers so that we could handle the monthly or yearly spikes in activity. Most of these servers sat nearly idle the rest of the year and generated heat.

If you’re going to take advantage of the inherent elasticity within your cloud environment you need to understand exactly how your application will respond to being overloaded and how your infrastructure adapts to this condition. Cloud providers have tools to execute the dynamic shift in resources but ultimately you need a tool to detect the trigger conditions and then interface with the dynamic provisioning features of your cloud.

The combination of slow transactions AND resource exhaustion would be a great trigger to spin up new application instances. Each condition on its own does not justify adding a new resource.

Screen Shot 2013-04-25 at 3.16.38 PM

Screen Shot 2013-04-25 at 3.20.05 PM

The point here is that migrating to the cloud is not a magic bullet. You need to know how to use the features that are available and you need the right tools to help you understand exactly when to use those features. You need to stress your new cloud application to the point of failure and understand how to respond BEFORE you set users free on your application. Your users will certainly break your application and during an event is not the proper time to figure out how to manage your application in the cloud.

Let failure be your guide to success. Fail when it doesn’t matter so that you can success when the pressure is on. The cloud auto-scaling features shown in this post are part of AppDynamics Pro 3.7. Click here to start your free trial today.

Cloud Migration Tips #3: Plan to Fail

Planning to deploy or migrate an application to a cloud environment is a big deal. In my last post we discussed the value of using real business and IT requirements to drive the justification of using a cloud architecture. We also explored the importance of using monitoring information to understand your before and after picture of application performance and overall success.

In this post I am going to dive deeper into the planning phase. You can’t expect to throw a half assed plan in place and just deal with problems as they pop up during an application migration. That will almost certainly result in frustration for the end users, IT staff, and the business who relies upon the application.

In reality, at least 90% of your total project time should be dedicated to planning and at most 10% to the actual implementation. The big question is “What are the most important aspects of the planning phase?”. Here’s my cloud migration planning top 10 list:

  1.  Application Portfolio Rationalization  – Let’s face reality for a moment… If you’re in a large enterprise you have multiple apps that perform a very similar business function at some level. Application Portfolio Rationalization is a method of discovering the overlap between your application and consolidating where it makes sense. It’s like spring cleaning for your IT department. You need to get your house in order before you decide to start moving applications or you will just waste a lot of time and money moving duplicate business functionality across your portfolio.
  2. Business Justification and Goal Identification – If there is one thing I try to make clear in every blog post it is the fact that you need to justify your activities using business logic. If there is no business driver for a change then why make the change? Even very techie-like activities can be related back to business drivers.
    Example… Techie Activity: Quarterly server patching Business Driver: Failure to patch exposes the business to risk of being hacked which could cause brand damage and loss of revenue.
    I included goal identification with business justification because your goals should align with the business drivers responsible for the change.
  3. Current State Architecture Assessment (App and Infra) – This task sounds simple but is really difficult for most companies. Current State Architecture Assessment is all about documenting the actual deployed application components, infrastructure components, and application dependencies. Why is this so difficult? Most enterprises have implemented a CMDB to try and document this information but the CMDB is typically manually populated and updated. What happens in reality is that over time the CMDB is neglected when application and infrastructure changes occur. In order to solve this problem some companies have turned to Automated discovery and dependency mapping tools. These tools are usually agentless so they login to each server and scan for processes, network connections, etc… at pre-defined intervals and create a very detailed mapping that includes all persistent connections to and from each host regardless of whether or not they are application related. The periodic scans also miss the short lived services calls between applications unless the scan happens to be at approximately the same time of the transient application call. An agent based APM tool covers all the gaps associated with these other methods.


    How well do you know the current architecture and dependencies of your application?

  4. Current State Performance Assessment – Traditional monitoring metrics (CPU, Memory, Disk I/O, Network I/O, etc…) will help you size your cloud environment but tell you nothing about the actual application performance. The important performance metrics encompass end user response time, business transaction response time, external service response time, error and exception rates, transaction throughput, with baselines for each. This is also a good time to make sure there are no glaring performance issues that you are going to promote into your cloud environment. It’s better to fix any known issues before you migrate as the extra complexity of the cloud can amplify your application problems.

    Screen Shot 2012-08-14 at 1.59.33 PM

    You don’t want to carry application problems into your new environment.

  5. Architectural Change Impact Assessment – Now that you know what your real application and infrastructure components are, you need to assess the impact of the difference between traditional and cloud architectures. Are there components that wont work well (or at all) in a cloud architecture? Are code changes required to take advantage of the dynamic features available in your cloud of choice? You need to have a very good understanding of how your application works today and how you want it to work after migration and plan accordingly.
  6. Problem Resolution Planning – Problem resolution planning is about making a commitment to your monitoring tools and strategy as a core layer of your overall application architecture. The number of potential points of failure increases dramatically from traditional to cloud environments due to increased virtualization and dynamic scaling. In highly distributed applications you need monitoring tools that will tell you exactly where problems are occurring or you will spend too much time isolating the problem location. Make monitoring a part of your application deployment and support culture!!!
  7. Process re-alignment – Just hearing the word “process” makes me cringe and have flashbacks to the giant, bloated , slow moving enterprise environments that I used to call my workplace. The unfortunate truth is that we really do need solid processes if we want to maintain order and have any chance of managing a large environment in a sustainable fashion. Many of the traditional IT development and operations processes need to be modified when we migrate to the cloud so you can’t overlook this task.
  8. Application re-development – The fruits of your Architectural Change Impact Assessment work will probably precipitate some level of development work within your application. Maybe only minor tweaks are required, maybe significant portions of your code need to change, maybe this application should never have been selected as a cloud migration candidate. If you need to change the application code you need to test it all over again and measure the performance.
  9. Application Functional and Performance Testing – No surprises here, after the code has been modified to function as intended with your cloud deployment it needs to be tested. APM tools really speed up the testing process since they show you the root of your performance problems down to the line of code level. If you rely only upon the output of your application testing suite your developers will spend hours trying to figure out what code to change instead of minutes fixing the problematic code.

    Call Graph

    Know exactly where the problem is whether it is in your code or an external service.

  10. Training (New Processes and Technology) – With all of those new and/or modified processes and new software required to support your cloud application training is imperative. Never forget the “people” part of “people, process, technology”.

There’s a lot more that really goes into planning a cloud migration but these major tasks are the big ones in my book. Give these 10 tasks the attention they deserve and the odds will shift in your favor for a successful cloud migration. Next week we’ll talk about important work that should happen after your application gets migrated.

Cloud Migration Tips #2: We Should Use the Cloud Because…

Welcome back to my blog series on deploying applications to the cloud.

What’s the point of deploying an application to the cloud versus just hosting it in your own data center? Is it really a good idea? Will it save you money? Will it work better? Will it cause new deployment and management problems? How do you monitor it?


These are all basic questions you should ask yourself before deciding IF your new or existing application will end up in a cloud environment.

The answers might be different for each application supporting your business. Cloud is really a set of architectural patterns that are available to help you solve business problems using technology. If you’re considering cloud you better have a business problem that you need to solve.

Here are a few business problems that would make me consider a cloud implementation for my application(s):

  • We’re out of space in our data center and most of our applications are used via the internet–should we build another data center or move some applications to public cloud providers?
  • Our new mobile application will need to scale rapidly as it becomes more popular–we have to be able to scale as needed so our customers have a good user experience.
  • We need to accelerate our time to market and make our business more agile–we don’t have time to wait for IT and all of our productivity sapping processes.

No matter what your business reasons are you need to come up with quantifiable and measurable success criteria so that you can prove out the benefits (or failure) of your cloud computing initiative. This implies you are already measuring something BEFORE you move to the cloud so you can compare metrics before and after. Here are some example KPIs that might be applicable:

  • Time to deliver requested environment to developers
  • Number of application impact incidents
  • Infrastructure cost per application
  • Time to scale / Cost to scale Application
  • Transaction throughput
  • SLA (yeah, you really should have one of these)

So You’ve Decided To Go For It

You’ve got your business justification nailed down and decided you really do need a cloud based application. Great! If this is a brand new application you can design it from the ground up and just deploy it, right? No!!! Remember, you need to monitor and manage this application if you stand any chance of providing a good user experience over the long haul.

“My cloud provider has all the monitoring and management tools I need.” – Wrong! Your cloud provider has basic monitoring tools that show you infrastructure metrics (CPU usage, Memory Usage, I/O usage, etc…). These monitoring tools don’t tell you anything about your application. Here’s what you need to know about your cloud application (at a minimum):

  • Which application nodes are in use at any given time. (Dynamic scaling, provisioning, de-provisioning will change this picture at any given time)
  • Application calls to external services with response times and error rates. (External service calls are performance killers for cloud applications and drive up the cost as most provider charge for network traffic leaving their cloud)
  • The response time and errors of all of my users business transactions. (Applies to any application architecture but cloud deployments can experience greater variance due to factors outside of the application owners control (network congestion, regional provider issues, etc…))
  • When a problem occurs – full application call stack for code analysis. (Applies to any application architecture)
  • Host level KPIs correlated with all of the application activity. (Really important in the cloud due to host virtualization, shared resources, and multiple sizing options when you select a host to deploy. Select the wrong size by mistake and you just limited your max application performance)
  • Historic baselines for everything so you know what normal behavior looks like. (Critical to identifying problems regardless of architecture)

If you’re deploying a new application you should have a really good idea of any external application dependencies (like calling a payment gateway to process credit card orders). If you are moving an existing application there is more work that needs to be done up front. In particular you need to really understand your existing application dependencies. Is there a service or backend database that your application relies upon that you’re not planning to move with the application? If so you can really screw up the entire cloud implementation if you make a bunch of calls to a component that lives outside of your chosen cloud environment.


Modern applications have many external dependencies. You absolutely MUST know what they are before moving to the cloud.

If you’re moving an existing application you better deploy a tool that can dynamically detect and show application flow maps. I’m not talking about those agentless tools that scan your hosts everyday looking for network connections (those usually miss all of the short lived services calls). I mean a solution that will give you the entire picture regardless of persistent and transient connection methodologies.

Since you need to monitor your existing environment anyway you might as well collect performance data and save it so that you have a good point of comparison for your “before and after” application environment (We’ll discuss this item more in a future blog post).

There are a ton of considerations when you choose to implement your application using cloud computing architecture patterns. In my next post I’ll go into more detail around the planning phase. Having all your ducks in a row before your begin the migration is critical to success.

Don’t Deploy Your Cloud Application Without Reading This – Part 1

Public cloud, private cloud, hybrid cloud, cloud bursting, cloud storming, elastic compute, IaaS, PaaS, SaaS, the list of terms goes on and on ad-nauseam. Like it or not, cloud computing has taken hold as an important design consideration in companies ranging from small startups to large established enterprises. The concepts and technologies behind cloud computing have been around for quite a long time now so why is it taking so long for so many companies to move their applications and realize the benefits that cloud computing offers?

Getting beyond the ridiculous fear of the unknown, security concerns are a major inhibitor to cloud adoption but between private cloud and a slew of security technologies and methods that should only impact a small portion of applications. The real problem, in my opinion, is that nobody wants to fail and suffer damage to their personal and/or corporate brands. I’ve seen so many companies make a poor transition to cloud computing and it impacts their revenue and customer retention.


Companies like Netflix, Orbitz, and Family Search have been tremendously successful with their cloud computing initiatives. Do they have better technologists than other companies? Are their processes better than others? Do they have special tools that nobody else has? Or have they made a commitment that is okay to fail as long as they fail fast and don’t repeat their mistakes? The answer might be a combination of all of the above depending upon which organizations we are talking about.

There is a wealth of information published on the internet about deploying applications to the cloud; there are companies that exist solely to help you move application to the cloud; there are even companies that exist to help you figure out IF you should move your application(s) to the cloud. I used to work for one of those companies and what we saw over and over again was that our clients really didn’t know how to get started down the path of moving their existing applications to a cloud environment. Even worse were the companies that thought they knew what it took to successfully migrate their application(s) but didn’t. All of these companies were missing crucial bits of information that would make the difference between a smooth and painless migration and a rough, frustrating migration.

toolbox-cloudThe tools, processes, and information you use in the planning, execution, and ongoing management of your cloud applications will make all of the difference between success and failure.

In this blog series I’ll discuss some of the key considerations related to planning and execution of migrating your applications to the cloud. I’ll cover a few important aspects of deciding IF you should move your applications to the cloud and then focus mostly on what happens after you’ve decided to go for it. Everything I discuss will be directly from my experience moving and monitoring cloud applications within an enterprise and as a consultant.

In my opinion it’s much harder to move an existing application than it is to set up a new application in the cloud. The good news is that there are common considerations for each of these scenarios so next week I’ll discuss the following:

Should we move or deploy to the cloud?
What can I monitor to ensure my users are not impacted in a negative way?

In future posts I’ll discuss the planning and migration phases, how to take advantage of cloud elasticity, and good ongoing management practices. I might even preview some awesome new features we’re cooking up to make management of your applications faster and easier (shhhhh, it’ll be our little secret).

Cloud Migration won’t happen overnight

There is a massive difference between migrating some code to the cloud and migrating an entire application to the cloud. Yes, the heart of any application is indeed its codebase, but code can’t execute without data and there lies the biggest challenge of any cloud migration. “No problem,” you say. “We can just move our database to the cloud and our code will be able to access it.” Sounds great, apart from most storage services in the cloud tend to run on cheap disk which is often virtualized and shared across several tenants. It’s no secret that databases store and access data from disk; the problem these days is that disks have got bigger and cheaper, but they haven’t exactly got much faster. The assumption that Cloud will offer your application a better Quality of Service (QoS) at a cheaper price is therefore not always true when you include application tiers that manage data. Your code might run faster with cheaper and elastic computing power, but it can only go as fast as the data which it retrieves and processes.

Applications were failing long before Cloud came along

I’m fed up of reading about Cloud outages, largely because all applications are created and managed by the most dangerous species on the planet – the human being. Failure is inevitable in regards to everything the human being creates or touches, and for this reason alone I see no news in seeing the word “outage” in IT articles with or without Cloud mentioned.

What gets me the most is that applications, infra-structure and data centers were slowing down and blowing up long before “Clouds” became fashionable. They just didn’t make the news every other week when applications resided in “data-centers”–ah, the good old days. Just ask anyone who works in operations or help desk/app support whether they’ve worked a 38 hour week; I guess the vast majority will either laugh or slap you. If everything worked according to plan, IT would be a really dull place to work, help desk would be replaced with OK desk, and we’d have nothing to talk about in the office or pub.