I find it very interesting that in-house IT is seen as “the department of ‘no’” and that AWS is considered the easy place to build things. I suspect that this points to a mismatch between what an IT department thinks is important and what its internal customers think is important. I think that AWS is one of the most inflexible IT service providers I have seen. Its services are very rigidly defined. Yet, lots of businesses see AWS as a more responsive alternative to IT departments, which they see as inflexible. I think that with a change in focus, internal IT departments can become far better at providing what the application teams require.
I should start out by showing how AWS is inflexible. A great example is one of AWS’s first-ever products, the Simple Queue Service (SQS). Queueing, along with load balancers, is an important part of the loosely coupled application architecture that AWS promotes. One part of an application places messages into the queue. The messages are requests for another part of the application to act. That other part watches the queue and acts on messages that appear in the queue. For example, an order entry system might place an order in a queue directing the warehouse system to pick parts from the warehouse. The warehouse system watches the queue and pulls each message from the queue to fulfill the order. There is a basic limit to these messages: they can be a maximum of 256 KB in size. This is probably plenty for most orders, but what if a customer places a massive order? Can I send a 320 KB message? The AWS answer would be “No, you are using SQS wrong. You should put the order in a database and just pass a reference to it in the message or serialize one order over multiple messages.” Either way, your application must change to fit the service that AWS provides; the service does not change to fit your application.
AWS is very clear about offering the exact same service to every customer and not varying that service for any customer. This is not the way enterprise IT organizations work. In enterprise IT, we would need to make the queueing system work with the largest message that our developers might want to send. The IT department would not tell the developers to build their applications differently to fit with the infrastructure. The big difference for AWS is that it has a very clear vision of how applications should be developed. AWS delivers the services that are required to build applications. This does seem to be a gap area for many enterprise IT departments.
Enterprise IT infrastructure teams are not generally staffed with developers. They have operations staff and teams of infrastructure engineers. There is a very different way of viewing problems and requirements when you look after infrastructure instead of developing applications. These operations teams end up thinking of the organization’s developers as almost their enemies. The reality is that developers and application support teams are the IT department’s customers. They are the reason for infrastructure. The IT team needs to learn what developers need and to deliver on those needs. If the IT department doesn’t look after its customers, then someone else will. Development teams often have options that allow them to bypass internal IT completely. AWS is the prime example of allowing developers to bypass central IT.
Developers want IT to provide infrastructure and then get out of the way. Provisioning VMs is great for developers: it is much faster than waiting for physical servers. Now developers expect to be able to get VMs fast. Self-service is key; nobody wants to be waiting on help-desk tickets. But bare VMs are not enough: developers need services delivered through a self-service mechanism. A self-service platform for running containers is very helpful, as are self-service databases, storage services, and other prebuilt components for building applications. Self-service through a portal is a good start, but self-service through an API is even better.
I think that the key to keeping on-premises enterprise IT is to enable your in-house developers. Provide the sorts of services that help developers be more productive. Have those services available through programmatic self-service. Value the developers as your internal customers.