TAG | cloud computing
It seems like every article, tweet, blog post I read someone has a different definition of the same buzzwords – especially in technology. Mentioning cloud or big data on a tech blog is like bringing sand to the beach. That’s one of the reasons why we made The Real DevOps of Silicon Valley - to make fun of the hype. I got to thinking… has anyone taken the time to shed some light on these ambiguous terms? I investigated on Urban Dictionary and this is what I found…
IT According to UrbanDictionary.com
(Not kidding, look it up…)
1. CLOUD COMPUTING
cloud com·put·ing, noun.
“Utilizing the resonance of water molecules in clouds when disturbed by
wireless signals to transmit data around the globe from cloud to cloud.
‘I use cloud computing so I don’t have to worry about viruses, I
only have to worry about birds flying through my cloud.’”
“Agile is a generalized term for a group of anti-social behaviors used by office workers to avoid doing any work while simultaneously giving the appearance of being insanely busy. Agile methods include visual distraction, subterfuge, camouflage, psycho-babble, buzzwords, deception, disinformation, and ritual humiliation. It has nothing to do with the art and practice of software engineering.”
3. BIG DATA
big da·ta, noun.
“Modern day version of Big Brother. Online searches, store purchases, Facebook posts, Tweets or Foursquare check-ins, cell phone usage, etc. is creating a flood of data that, when organized and categorized and analyzed, reveals trends and habits about ourselves and society at large.”
“When developers and operations get together to drink beer and color on whiteboards to avoid drama in the War Room. Also a buzzword for recruiters to use to promote overpaid dev or ops jobs.”
Watch episode HERE.
“The parts of a computer that can’t be kicked, but ironically
deserve it most.
“The word the Knights of Ni cannot hear or say.”
(Monty Python & the Holy Grail reference)
Link to this post:
If you haven’t already, many IT organizations are migrating some of their applications to the cloud to become more agile, alleviate operational complexity and spend less time managing infrastructure and servers. The next question you may ask yourself is, “How will we monitor these applications and where should we even begin with so many monitoring tools on the market?”
I’m glad you asked. Here is a list of gotchas you should look out for. If you have your own list, feel free to comment below and share with us.
1. Lack of End User or Business Context - With apps running in the cloud, monitoring infrastructure metrics indicates very little about your end-user experience,or the performance of your apps or business running in the cloud. End users experience business transactions so make sure your monitoring gives you this visibility.
2. Node Churn - How well does your application monitoring solution deal with node churn – the provisioning and de-provisioning of servers and application nodes? The monitoring solution has to work in dynamic, virtual and elastic environment where change is constant, otherwise you’ll end up with blind spots in your application and monitoring. Many of the current monitoring solutions today are unable to monitor and adapt to dynamic cloud infrastructure changes, requiring manual intervention by operations so new nodes can be registered and monitored.
3. Agent-less is Tough in the Cloud - You may not have any major issues with installing a packet sniffer or network-monitoring appliance in your own private cloud or data-center, but you won’t be able to place these kinds of devices in PaaS or IaaS environments to monitor your application performance. Monitoring agents in comparison can easily be embedded or piggy-backed as part of an application deployment in the cloud. Agent-less may not be a option when trying to monitor many cloud applications.
4. High Network Bandwidth Costs - Cloud providers typically charge per gigabyte of inbound and outbound traffic. If your cloud application has 100 nodes and your collecting megabytes of performance data every minute, all of that data has to be communicated outside of the cloud to your monitoring solution’s management server, which can be on-premise or in another cloud. Monitoring what’s relevant in your application versus monitoring everything means you’ll avoid exorbitant cloud usage bandwidth costs for transferring monitoring data.
5. Inflexible Licensing - If you want to monitor specific nodes, will your application monitoring vendor lock each license down to a physical server, hostname or IP, OR can your licenses float to monitor any server/node? This can be a severe limitation as now your agents are locked down to a specific node indefinitely. Even if you weren’t monitoring your applications running in the cloud, it’s still a nuisance to have a monitoring agent handcuffed to a physical server without being given the licensing flexibility to move agents around to monitor different server or nodes. As stated above, with node churn occurring frequently in cloud environments, you need a monitoring solution to be as flexible as possible so you can deploy agents anywhere, at anytime.
Link to this post:
We’re pretty lucky these days to work and play with lots of cool stuff. In a consumer world of HD TVs, Mac books, iPhones, Droids, Angry Birds, Face books and tweets, life is rarely boring. Working in IT is the same. We’ve got clouds, NoSQL, agile, SOA, ria, pythons, scalas, rubies, and lots of ideas and technologies to play with every week. If only our friends and relatives outside of IT could figure out what the hell we’re all excited about, and the simple fact that most of us aren’t millionaires.