4 ms·

I disagree with your assessment. I say this as an ops person, actively migrating workload from on premise physical infrastructure to the public cloud. EC2 is n

I disagree with your assessment. I say this as an ops person, actively migrating workload from on premise physical infrastructure to the public cloud. EC2 is not built for ops teams at all. It is built for developers. The VSphere/Xen analogy doesn't hold up. Amazon is explicitly abstracting away the physical and software stack that ops teams would build and mantain onsite. AWS gives you back an API and a reference client. Nothing to install, no physical hosts to buy, no network switches to configure. Simply focus on your compute requirements and go from there.

derefr 10y ago
Maybe "ops" is an imprecise designation for the organizational role AWS is intended to target, but "developer" is definitely incorrect. My position is that AWS is designed for a particular usage pattern: one where a large enterprise organization has a particular department that consumes, configures, and manages AWS's virtual infrastructure (just like an ops team consumes, configures, and manages physical infrastructure), and then, in turn, provide an internal IT-services abstraction to the rest of their organization, using AWS as the "backend" for (some or all of) those services. None of AWS's services are created from the perspective of use by application developers; they don't present application-level interfaces, nor do they expect (unlike PaaS services) that the application can be rewritten to conform to the shape of the infrastructure. The application is taken as a given. IaaS APIs are created such that an internal IT services department can receive a request from an application developer to provision a cluster for their (fixed) application, and can respond to that request by hitting AWS APIs, instead of by paging ops staff. In smaller organizations, these lines blur under "devops" sensibilities, where the developers effectively do their own IT services. But in organizations where this boundary is clear, AWS lives inside it, not anywhere where developers can see or touch it. AWS's 'idiomatic' use is to be a transparent drop-in backend replacement that the application developers in the company won't even be aware that ops has switched over to—except to notice that there are now likely fewer ops people overall.
- dmourati 10y ago
  While what you describe above is certainly one mode of using AWS, that's not the only approach and I don't believe it is the most widely used. My source is attending re:Invent and local meetups. Take Netflix or Airbnb as two examples. These are large cloud-native businesses with huge application developer staffs. These companies do not hogtie those staff by making IT (or ops) the interface to AWS. They create and leverage open source tools like Spinnaker (and Asgard before that) to eliminate IT services all together. Netflix infamously called this approach "Noops." If I take your approach and assert myself as the "gatekeeper" between some 300 software developers and the public cloud, I may enjoy some sense of control. This sense is false and doomed to be short lived. Sooner or later, these same developers will realize all I am is an interface and they will read documentation, find blogs, and internalize that they too can hit AWS APIs. Some folks call this "Shadow IT." One thing we can agree on is fewer ops people overall. A huge chunk of the work I used to do in the ops role included buying gear, racking, stacking, building data centers, provisioning OS, networking, repairing, etc. In the cloud, all that is done for me. Staking out the middleman role doesn't hold any allure for me. I'd prefer to help lead the developers into a self-service model and show them how public cloud changes the rules of the game enabling them to change their perspectives, improve and rewrite their applications, and generally move much faster. This model is working quite well for me today. I dare say the developers are equally happy. They certainly have questions about more traditional ops stuff. Those questions get answered and circulated around the team. Eventually, the questions start moving toward cloud ops stuff. How do we autoscale? What's the right AZ redundancy model? How do we setup Direct Connect? When should we use spot instances? That shows evolution and learning.

derefr 10y ago

Maybe "ops" is an imprecise designation for the organizational role AWS is intended to target, but "developer" is definitely incorrect. My position is that AWS is designed for a particular usage pattern: one where a large enterprise organization has a particular department that consumes, configures, and manages AWS's virtual infrastructure (just like an ops team consumes, configures, and manages physical infrastructure), and then, in turn, provide an internal IT-services abstraction to the rest of their organization, using AWS as the "backend" for (some or all of) those services. None of AWS's services are created from the perspective of use by application developers; they don't present application-level interfaces, nor do they expect (unlike PaaS services) that the application can be rewritten to conform to the shape of the infrastructure. The application is taken as a given. IaaS APIs are created such that an internal IT services department can receive a request from an application developer to provision a cluster for their (fixed) application, and can respond to that request by hitting AWS APIs, instead of by paging ops staff. In smaller organizations, these lines blur under "devops" sensibilities, where the developers effectively do their own IT services. But in organizations where this boundary is clear, AWS lives inside it, not anywhere where developers can see or touch it. AWS's 'idiomatic' use is to be a transparent drop-in backend replacement that the application developers in the company won't even be aware that ops has switched over to—except to notice that there are now likely fewer ops people overall.

dmourati 10y ago
While what you describe above is certainly one mode of using AWS, that's not the only approach and I don't believe it is the most widely used. My source is attending re:Invent and local meetups. Take Netflix or Airbnb as two examples. These are large cloud-native businesses with huge application developer staffs. These companies do not hogtie those staff by making IT (or ops) the interface to AWS. They create and leverage open source tools like Spinnaker (and Asgard before that) to eliminate IT services all together. Netflix infamously called this approach "Noops." If I take your approach and assert myself as the "gatekeeper" between some 300 software developers and the public cloud, I may enjoy some sense of control. This sense is false and doomed to be short lived. Sooner or later, these same developers will realize all I am is an interface and they will read documentation, find blogs, and internalize that they too can hit AWS APIs. Some folks call this "Shadow IT." One thing we can agree on is fewer ops people overall. A huge chunk of the work I used to do in the ops role included buying gear, racking, stacking, building data centers, provisioning OS, networking, repairing, etc. In the cloud, all that is done for me. Staking out the middleman role doesn't hold any allure for me. I'd prefer to help lead the developers into a self-service model and show them how public cloud changes the rules of the game enabling them to change their perspectives, improve and rewrite their applications, and generally move much faster. This model is working quite well for me today. I dare say the developers are equally happy. They certainly have questions about more traditional ops stuff. Those questions get answered and circulated around the team. Eventually, the questions start moving toward cloud ops stuff. How do we autoscale? What's the right AZ redundancy model? How do we setup Direct Connect? When should we use spot instances? That shows evolution and learning.