Welcome to the next installment in our blog series highlighting the companies in SoftLayer’s new Technology Partners Marketplace. These Partners have built their businesses on the SoftLayer Platform, and we’re excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
- Paul Ford, SoftLayer VP of Community Development

Follow the link below to read the guest blog from AppFirst, a SoftLayer Tech Marketplace Partner specializing in managing servers and applications with a SaaS-based monitoring solution. To learn more about AppFirst, visit AppFirst.com and if you like what you see, sign up for a Free Trial of AppFirst in the Technology Partners Marketplace.

How You Should Approach Monitoring in the Cloud

Monitoring in the cloud may sound like it’s easy, but there’s one important thing you need to know before you get started: traditional monitoring techniques simply don’t work when you’re in the cloud.

“But why?” you may ask. “Why can’t I use Polling and Byte Code Injection in my cloud infrastructure?”

With Polling, you miss incidents between intervals, you only get the data that you requested, and you can only monitor parts of the application but not the whole thing. If you choose to use Polling for your cloud monitoring, you’ll have to deal with missing important data you need.

And with Byte Code Injection, you only get data from within the language run-time, meaning you don’t have the real data of what is happening across your application stack. It is inferred.

Using our own product on our production systems, we have learned three lessons about running in the cloud.

Lesson #1: Visibility = Control
By definition, running in the cloud means you are running in a shared environment. You don’t have the CPU cycles your operating system reports you have, and sometimes, the hypervisor will throttle you. In our experience, some cloud vendors are much better at managing this than others. When running in some clouds, we’ve had huge variations in performance throughout the day, significantly impacting our end-users experience. One of the reasons we chose SoftLayer was because we didn’t see those kinds of variances.

The reality is until you have visibility into what your application truly needs in terms of resources, you don’t have control of your application and your user’s experience. According to an Aberdeen study, 68% of the time IT finds out about application issues from end users. Don’t let this be you!

Lesson #2: It’s Okay to Use Local Storage
The laws of physics reign, so the disk is always the slowest piece. No getting around the fact there are physical elements involved like spindles and disks spinning. And then when you share it, as you do in the cloud, there can be other issues … It all depends on the characteristics of your application. If it’s serving up lots of static data, then cloud-based storage can most likely work for you. However, if you have lots of dynamic, small chunks of data, you are probably best served by using local storage. This is the architecture we had to go with given the nature of our application.

With servers around the world streaming application behavior data to our production system all the time and needing to process it to make it available in a browser, we had to use local storage. In case you are interested in reading more on this and RAM based designs here are some posts:

• High Scalability – Are Cloud Based Memory Architectures the Next Big Thing?
• Thinking Out Cloud – Memory-Based Architectures and the Cloud
• AppFirst – A RAM Based Data Architecture

Lesson #3: Know the Profile of Your Subsystems
Knowing the profile of your subsystems and what they need in terms of resources is imperative to have the best performing application. A cloud-only deployment may not be right for you; hybrid (cloud and dedicated physical servers) might work better.

As we discussed in Lesson #2 you might need to have local, persistent storage. Again, some vendors do this better than others. SoftLayer, in our experience, has a very good, high bandwidth connection between their cloud and physical infrastructure. But you can’t make these decisions in a vacuum. You need the data to tell you what parts of your application are network heavy, CPU intensive, and require a lot of memory in certain circumstances. We have learned a lot from using our own application on our production system. It’s very quick and easy for you to start learning about the profile of your application too.

We are constantly learning more about deploying in the cloud, NoSQL databases, scalable architectures, and more. Check out the AppFirst blog regularly for the latest.

We’d like to give a special shout out thanks to SoftLayer! We’re honored to be one of your launch partners in the new Technology Partners Marketplace.

-AppFirst