2013 is the year of NoOps for the Cloud (infographic)(gigaom.com)
gigaom.com
2013 is the year of NoOps for the Cloud (infographic)
http://gigaom.com/cloud/why-2013-is-the-year-of-noops-for-programmers-infographic/
7 comments
I have clarified a lot of the great questions that have come out of the infographic we created here: http://blog.appfog.com/what-is-noops-anyhow/
An infographic that outlines "Cloud 1.0" and "Cloud 2.0". In some ways, the opposite of Pinboard's recent down-to-earth view of hosting. (1)
1. http://blog.pinboard.in/2012/01/the_five_stages_of_hosting/
1. http://blog.pinboard.in/2012/01/the_five_stages_of_hosting/
I think Pinboard's piece is great - but only talks about the past. This piece talks about the future and a "NoOps" option that doesn't exist in Pinboard's piece.
No, this article is talking about the first stage in Pinboard's piece, 'The Monastery':
"You run your site on an 'application platform' like Heroku, Azure, or Google App Engine. You design your application around whatever metaphors and APIs the service lays out, and in return you are veiled from all the mysteries of implementation. You never interact with the computer directly, but upload your code to the platform with the proper incantations and it runs. The orders vary in strictness, with GAE requiring that you purify yourself of all worldly design habits before writing your app, Azure insisting you renounce the demon Unix, and Heroku somewhat more welcoming to the fallen. On all three platforms, when your application needs more resources, you press the 'more resources' button. A lot of fancy sandboxing, monitoring and administration tools come standard, and it's very easy to deploy and test different versions of your app."
"You run your site on an 'application platform' like Heroku, Azure, or Google App Engine. You design your application around whatever metaphors and APIs the service lays out, and in return you are veiled from all the mysteries of implementation. You never interact with the computer directly, but upload your code to the platform with the proper incantations and it runs. The orders vary in strictness, with GAE requiring that you purify yourself of all worldly design habits before writing your app, Azure insisting you renounce the demon Unix, and Heroku somewhat more welcoming to the fallen. On all three platforms, when your application needs more resources, you press the 'more resources' button. A lot of fancy sandboxing, monitoring and administration tools come standard, and it's very easy to deploy and test different versions of your app."
NoOps is the very first item in Pinboard's piece: "You don't have to spend any time worrying about backups, load balancing, configuration, hardware, or anything except your app."
Pinboard's point of view is vertical within a single organisation, whereas Gigaom's is horizontal across an industry.
Pinboard's point of view is vertical within a single organisation, whereas Gigaom's is horizontal across an industry.
Any sysadmins care to chime in with their view on this? Jobwise are you planning to switch to development in the near future ?
As a sysadmin, let me reassure you that this is purely marketing nonsense. Careful listening to CEOs living inside their own bubble, far from reality...
Sysadmin here, 11+ years now, grokker of Perl/Python/Ruby/Shell/PHP, manager of physical and virtual servers.
I think the whole point is the developer no longer have to be concerned about the day to day management of the server (e.g. tuning disk I/O, manually deploying applications and services, setting affinity on processes, managing logs), as that will be shifted completely to the infrastructure managers. And that is fine. Infrastructure should be devolved completely back to the administrators and developers should just write code that runs automatically with no modification in the cloud.*
I am not sure what the last question supposed to be, but I assumed it implies that systems administration will be obsolete. It is possible that it will change,but consider this: in the past, most sysadmins worth their salt should at some point be able to write code. It is only recently (it seems around the late 90s) that there was a generation of admins that didn't have the technical chops to write code or even simple scripts. With the advent of cloud and the management tools that comes with it that requires a significant programming background to manage (e.g. writing Puppet or Chef code), this is a welcome return to the past.
*In theory. :)
I think the whole point is the developer no longer have to be concerned about the day to day management of the server (e.g. tuning disk I/O, manually deploying applications and services, setting affinity on processes, managing logs), as that will be shifted completely to the infrastructure managers. And that is fine. Infrastructure should be devolved completely back to the administrators and developers should just write code that runs automatically with no modification in the cloud.*
I am not sure what the last question supposed to be, but I assumed it implies that systems administration will be obsolete. It is possible that it will change,but consider this: in the past, most sysadmins worth their salt should at some point be able to write code. It is only recently (it seems around the late 90s) that there was a generation of admins that didn't have the technical chops to write code or even simple scripts. With the advent of cloud and the management tools that comes with it that requires a significant programming background to manage (e.g. writing Puppet or Chef code), this is a welcome return to the past.
*In theory. :)
The underlying systems don't magically build and support themselves. Basically you're just offloading the sysadmin responsibility to someone else and paying for that privilege.
Coming from a background of having to deal with the highest level of PCI-DSS scrutiny, this makes total sense. It would have been soooooo much easier to just point the auditors to the managed hosting service and say, "ask them, they're the experts." Leaving myself and the other devs to just worry about software security.
What happens if/when an issue comes up that the managed service can't/won't resolve? If you can move to another provider that will, you'll have some leverage. But there's always headaches associated with any move/migration and a possibility of lock-in to the provider's platform.
Yes, I certainly agree. One of the major problems with taking an application implemented on a PaaS solution to production scale is that you essentially join at the hip the continued success of your core product to the eventual fate of an outside vendor's platform. What's worse is that by the time you realise you've grown too big for the PaaS you may have to expend a huge amount of engineering effort and customer good will to move off, if you even can. Indeed, PaaS providers will try to make it /easy/ for you to make engineering decisions which lock you into their platforms -- and they will present those choices as helpful at the time, which makes them quite insidious partners.
This is a very valid concern. We are in the early stages of this transformation and naturally winners and losers will emerge as the market becomes more mature and the big guys begin to purchase and consolidate PaaS.
Rewind N years and you can replace PaaS with some other technology that eventually matured and is now considered ubiquitous.
Rewind N years and you can replace PaaS with some other technology that eventually matured and is now considered ubiquitous.
Good point. Two companies I know of (Expensify.com and Trap.it) get around this to a certain degree by hosting on multiple vendors. With that they are better able to account for sudden changes to the market if one goes down or drastically raises their prices.
Above just showing a certification, hosting providers never give access to their data centers.
So basically, you've re-branded PaaS as NoOps. I'm all for it.
Actually I think Gartner did that first.
[deleted]
NoOps means "No Operations" in the same way that NoSQL means "No SQL". As in, it doesn't.
Makes me wonder if that's the best name for it. What I immediately thought of was: http://en.wikipedia.org/wiki/NOP