One of the most fun aspects of hosting The Cloudcast (.net) podcast is that we take a completely vendor-neutral and technology-neutral stance on what we discuss and who we invite onto the show. Lots of learning and lots of great discussions. And occasionally we ask a few questions and find some interesting needles in the haystack that we didn't expect. [APIs, data analytics and the business models they enable are top of mind for me these days]
This is exactly what happened on this week's show with Mat Ellis (@matellis), CEO of Cloudability. I had learned about his company while doing some research for a blog I'd written about emerging Cloud Management vendors and trends. At first look, I thought Cloudability looked interesting because they seemed to make cost management for public clouds very simple. I thought we'd have an interesting conversation about comparing the costs between different cloud providers, some unknown cost horror stories and maybe dig into some of the analytics
Friday, March 30, 2012
Sunday, March 18, 2012
Thoughts from the Regional Cloud
This past week I had the opportunity to attend the Varrow Madness event, hosted by Varrow, in Charlotte, North Carolina. The event was well attended and Varrow does an outstanding job of bringing together customers and their technology partners. The event primarily draws from a customer base in Charlotte and Raleigh, NC, as well as southern Virginia and parts of South Carolina. I highlight this because those cities are the #19 and #45 cities in the US in population. They are growing areas with expertise in healthcare, high-tech, banking, state/local government and some manufacturing, but they are by no means Silicon Valley or Wall Street.
Sometimes it's easy to forget that there is a massive IT ecosystem that lives outside the shining lights of the technology and financial hubs. Not every IT department is filled with "hackers" that are ready to contribute their next web-scale finding back into the open-source community. They might think Cassandra is a co-worker's niece and could mistake an OpenFlow discuss for a potential flooding issue in the data center. These IT groups don't lack for skills, as many of them have experienced several technology transitions, and in most cases they aren't as silo'd as the IT press makes them out to be. They would love to be using the latest technologies, but budgets, lack of training and legacy integration often become bigger barriers than compelling ROI.
Sometimes it's easy to forget that there is a massive IT ecosystem that lives outside the shining lights of the technology and financial hubs. Not every IT department is filled with "hackers" that are ready to contribute their next web-scale finding back into the open-source community. They might think Cassandra is a co-worker's niece and could mistake an OpenFlow discuss for a potential flooding issue in the data center. These IT groups don't lack for skills, as many of them have experienced several technology transitions, and in most cases they aren't as silo'd as the IT press makes them out to be. They would love to be using the latest technologies, but budgets, lack of training and legacy integration often become bigger barriers than compelling ROI.
Tuesday, March 13, 2012
Shouldn't DevOps really be DesignOps?
There is a lot of buzz these days about DevOps, the movement to blur the lines between application development and IT operations. The thinking goes - if there is direct linkage between the functions (or if they are a single group), then how the applications are operated is always top-of-mind and things like security, automation and scalability can be designed-in from Day 1.
But as we move towards a world that is heavily dominated by touch-screen devices (gestures instead of clicks), apps replacing applications (UI + API + Data) and API integration between various services, I'm starting to wonder if the value of the automation begins to get overshadowed if Design isn't considered as the #1 factor.
By "Design", I'm not talking about the application design or the infrastructure design - none of that technical stuff. Not even just the UI experience. What I'm referring to is the end-to-end design that directly effects the experience of the user.
But as we move towards a world that is heavily dominated by touch-screen devices (gestures instead of clicks), apps replacing applications (UI + API + Data) and API integration between various services, I'm starting to wonder if the value of the automation begins to get overshadowed if Design isn't considered as the #1 factor.
By "Design", I'm not talking about the application design or the infrastructure design - none of that technical stuff. Not even just the UI experience. What I'm referring to is the end-to-end design that directly effects the experience of the user.
- How simple do you make it to get the app?
- How simple do you make it to launch the app, or sign up for the service?
- How many additional services are implicitly linked in intuitive ways to your app?
- Does the design get in the way of using the app/service, or does it create an experience where the user immediately has a positive opinion of your group/company?
The Curious Case of Cloud Management
As springtime rolls around, all sorts of interesting things start popping up that either delight us (green grass), frustrate us (weeds), congest us (pollen) or confuse us (daylight savings time). And a similar phenomenon appears to also be happening with "Cloud Management" start-ups.
In the early days, Cloud Computing either meant using SaaS applications or developer groups ("Shadow IT") that used one of the public IaaS services, such as AWS. SaaS had built-in management and those developer groups either used the basic AWS tools or built some things themselves. Most of these were paid for on a credit-card, so people didn't spend much time "managing" the services, as they were either focused on getting a work-related function done (eg. sales teams using Salesforce.com) or attempting to stay under the radar from IT budgets and controls.
Then Cloud usage started taking off as groups realized they could solve problems faster. But with that came new challenges:
In the early days, Cloud Computing either meant using SaaS applications or developer groups ("Shadow IT") that used one of the public IaaS services, such as AWS. SaaS had built-in management and those developer groups either used the basic AWS tools or built some things themselves. Most of these were paid for on a credit-card, so people didn't spend much time "managing" the services, as they were either focused on getting a work-related function done (eg. sales teams using Salesforce.com) or attempting to stay under the radar from IT budgets and controls.
Then Cloud usage started taking off as groups realized they could solve problems faster. But with that came new challenges:
Subscribe to:
Posts (Atom)